November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Neal D. Becker

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I used this: (setq load-path (append (list (expand-file-name "/usr/local/share/emacs/site-lisp")) load-path)) (require 'mailcrypt) (mc-setversion "gpg") (autoload 'mc-install-write-mode "mailcrypt" nil t) (autoload 'mc-install-read-mode "mailcrypt" nil t) (add-hook 'mail-mode-hook 'mc-install-write-mode) (add-hook 'gnus-summary-mode-hook 'mc-install-read-mode) (add-hook 'message-mode-hook 'mc-install-write-mode) (add-hook 'news-reply-mode-hook 'mc-install-write-mode) -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.4.4 (GNU/Linux) Comment: For info finger gcrypt(a)ftp.guug.de iD8DBQE2WvisrXRgwi1aDtMRAsaWAJ47nEJMefDuBaBdUWN9uYe3kOv3eQCcCHgz xbNi1I2enr42i/YQ+u1y0q4= =7Xeu -----END PGP SIGNATURE-----

2 participants
1 comments

Re: mailcrypt and gpg 26 years

Neal D. Becker

Yes, I'd like to know how to get gpg working.

3 participants
2 comments

Re: New release of toolbar-fancy package 26 years

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Jan> Probably the NT redisplay code tries to be too smart about > Jan> when the toolbar needs to be redrawn. What happens if you call (set-specifier-dirty-flag top-toolbar) after setting the fancy icons? Jan

1 participants
0 comments

Re: [BUG] with non-ascii characters in dir names 26 years

Didier Verna

Jan Vroonhof writes: Jan> Didier Verna <verna(a)inf.enst.fr> writes: Note that the same change as Jan> needed to fix your bug needs to apply to the the NT version as well. Yup. And to the `program' variable too, and ... Jan> well. Note that top that file claims the function has been MULE-ized. I think that some mule related warnings in this file (and probably some others) were hosed when Kirill split the process code. When I wrote the multicast support, I remeber that several functions were explicitely marked to be non mule-ized. More than there is now. >> You're right, this corrects the bug. This brings me a question that might >> be stupid, but isn't it likely that most use of XSTRING_DATA through the >> code will be bogus in the same fashion[1]? Jan> Probably. MULE is totally broken this regard. I looked at a few of them Jan> and most of them indeed look bogus. Jan> bolzano:vroonhof/cvs/xemacs-20/src> grep XSTRING_DATA *.c | wc -l 424 Jan> :-( I know exactly what you mean. I've done this too. Jan> I am wondering. Suppose we were to redefine XSTRING_DATA such that it Jan> always used 'raw-text' or maybe even 'binary' as the coding system would Jan> that help? Dunno. Maybe the scheme used in convert_to_external_format when the coding system is nil would be better. But there's a deeper problem here I think (see below). >> about the coding system ? I mean take the same function, >> unix_create_process, where the environement is massively copied for the >> child to be forked. What should we do about it ? Jan> You mean the arguments etc.. Do we really want Jan> 'process-argument-coding-system' (this can also be a lisp list op coding Jan> systems such that the n-th item is used as a coding sytem for the n-th Jan> argument) en 'environment-variable-coding-system', Jan> domain-or-host-name-coding-system. This smells too much like we're gonna get tons of similar variables each time we encounter a new problematic context. Actually, I think that there's a real problem when we don't know a priori which is the proper coding system to use, or even if there's one. Should default to raw, should we assume ascii and replace bogus chars with tildas, should we try to clever and guess the coding system ... ? Damn, if only the whole world were unicode :-( -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: New release of toolbar-fancy package 26 years

Adrian Aichner

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> Yup. After changing Options-> Toolbar Appearance->Default Locations >> from the selected Top to Bottom the 'next toolbar icons show up >> at the bottom (below the minibuffer). Jan> And when you select it back to top? The 'next icons appear at the top just like they should. >> What gives? Jan> Probably the NT redisplay code tries to be too smart about Jan> when the toolbar needs to be redrawn. Adrian Jan> Jan -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: alpha-linux build failure 26 years

Neal D. Becker

The problem is egcs-1.1. I rebuilt with egcs-1.0.2 (as it comes from RH5.1) and it's working fine.

1 participants
0 comments

Re: New release of toolbar-fancy package 26 years

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Yup. After changing > Options->Toolbar Appearance->Default Locations > from the selected Top to Bottom > the 'next toolbar icons show up at the bottom (below the minibuffer). And when you select it back to top? > What gives? Probably the NT redisplay code tries to be too smart about when the toolbar needs to be redrawn. Jan

1 participants
0 comments

Re: alpha-linux build failure 26 years

Falk Hueffner

<nbecker(a)fred.net> writes: > [...] > Loading site-load... (368) > Finding pointers to doc strings... > Finding pointers to doc strings...done > Dumping under the name xemacs > Purespace usage: 1283232 of 1283232 (100%). > Testing for Lisp shadows ... > > > temacs can only be run in -batch mode. > make[2]: Leaving directory `/usr/local/src/xemacs-20/src' > make[1]: Leaving directory `/usr/local/src/xemacs-20/src' > Building finder database ... > > > temacs can only be run in -batch mode. > > This scary warning may be related: > /usr/bin/ld: Warning: size of symbol `re_syntax_options' changed from 4 to 8 in /lib/libc.so.6.1 I have experienced the same on Alpha Linux (beta 57 i think). I would be very happy if somebody would find the problem. We have tried to debug temacs a bit and it seems everything is set ok but a wrong function is called. I will try a cvs version if I get it checked out. Falk

1 participants
0 comments

mailcrypt and gpg 26 years

Rebecca Ore

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got it working. The additions to the .emacs file if anyone needs them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.4.4 (GNU/Linux) Comment: For info finger gcrypt(a)ftp.guug.de iD8DBQE2WpaSnDcOefj8X+gRAv+dAJ4hCLp00mUfVC5kBil8B7TN4bzPCQCeLNlL 5SbswfqoiuBQ3Mm+pDNx9LE= =ZbrH -----END PGP SIGNATURE-----

1 participants
0 comments

Re: [BUG] with non-ascii characters in dir names 26 years

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: > A student reported here that `M-x compile' fails when the directory > name contains non ascii stuff. I've tried it myself and tracked it down a bit > and it seems that the fuckage occurs when getting the string with > XSTRING_DATA. I seem to get \201 characters just before all non ascii ones so > I guess the process gets a bogus directory. I'm not very familiar with the > coding system stuff. Any ideas how to fix this ? Judging from some grepping through the source. The data should probably be converted into file-name-coding-system, using GET_C_STRING_FILENAME_DATA_ALLOCA (defined in buffer.h [1]) Jan [1] Checkout the brilliant example of XEmacs commentary just above its definition.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 1998