January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Hrvoje Niksic

Yoshiki Hayashi <yoshiki(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > > I don't think we need 1. since XEmacs has multiple help buffer. > > > I just don't know the best way to handle 2, so it describes > > > function part only. Perhaps it should prompt for user to choose > > > function or variable. Or it should do the same with FSF Emacs. > > > > The latter would be quite acceptable. > > You mean showing both function and variable documentation? FSF > Emacs shows them in the same buffer. Yes, that's what I meant. > XEmacs doesn't have handy way to do that. Using separate buffers is > easy but popping up two buffer is annoying to me. I agree. Popping up two buffers is not really an option. > > You might consider implementing a context-sensitive menu that > > enables the user to choose between function and variable > > documentation. Also note that the same symbol can denote a face, > > a charset, etc. More stuff for the context menu. > > There's no function to describe a face, a charset, a keymap. I > think I should implement describe-face, describe-charset, etc. I > think it is useful if C-h v emacs-lisp-mode-map makes link from > #<keymap emacs-lisp-mode-map 4 entries > 0x1449> to an actual keymap. Yup. > > > This patch will make C-h b a bit slower but more useful. > > > > How much slower? > > xemacs -vanilla > > (require 'time-date) > (let ((start (time-to-seconds (current-time))) > (i 10)) > (while (> i 0) > (describe-bindings) > (setq i (1- i))) > (- (time-to-seconds (current-time)) start)) > > With xref > 1.878539085388184 > without xref > 9.501524925231934 You mean the other way around: the slower time is the one _with_ xref, right? Anyway, 9.5 seconds is a long time, especially compared to 1.87. I think this calls for a more intelligent non-regexp-based solution.

2 participants
1 comments

Emergency fix for gnus 24 years, 10 months

Martin Buchholz

I haven't actually tested this with nnmail (which I don't know how to use) but I suspect this is a temporary bandaid for the gnus problem reported here earlier. A better fix may follow. ChangeLog: 2000-01-28 Martin Buchholz <martin(a)xemacs.org> * coding.el (dontusethis-set-value-file-name-coding-system-handler): (dontusethis-set-value-terminal-coding-system-handler): (dontusethis-set-value-keyboard-coding-system-handler): Never undefine coding system aliases. Emergency fix for gnus. Index: coding.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/coding.el,v retrieving revision 1.2.2.3 diff -u -w -r1.2.2.3 coding.el --- coding.el 2000/01/27 04:39:48 1.2.2.3 +++ coding.el 2000/01/28 12:21:29 ＠＠ -199,7 +199,7 ＠＠ ;;; Make certain variables equivalent to coding-system aliases (defun dontusethis-set-value-file-name-coding-system-handler (sym args fun harg handler) - (define-coding-system-alias 'file-name (car args))) + (define-coding-system-alias 'file-name (or (car args) 'binary))) (dontusethis-set-symbol-value-handler 'file-name-coding-system ＠＠ -207,7 +207,7 ＠＠ 'dontusethis-set-value-file-name-coding-system-handler) (defun dontusethis-set-value-terminal-coding-system-handler (sym args fun harg handler) - (define-coding-system-alias 'terminal (car args))) + (define-coding-system-alias 'terminal (or (car args) 'binary))) (dontusethis-set-symbol-value-handler 'terminal-coding-system ＠＠ -215,7 +215,7 ＠＠ 'dontusethis-set-value-terminal-coding-system-handler) (defun dontusethis-set-value-keyboard-coding-system-handler (sym args fun harg handler) - (define-coding-system-alias 'keyboard (car args))) + (define-coding-system-alias 'keyboard (or (car args) 'binary))) (dontusethis-set-symbol-value-handler 'keyboard-coding-system

1 participants
0 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 10 months

Jari Aalto+mail.emacs

* Wed 2000-01-19 Valdis.Kletnieks(a)vt.edu list.xemacs * Message-Id: <200001191028.e0JAScp04514(a)black-ice.cc.vt.edu> | It's not a question of the package system.. The issue is the 'awkward | code bloat' that Adrian mentions. At some point, you have to just | say "screw it, Foobar-1.19 wirls on 21.2.19 and laoter only, you | 21.1 users are stuck with Foobar-1.18", or you have to endure code | that keeps accumulating more and more (if featurep()) code all over | the place. | | For an interesting time, cd to xemacs-packages/lisp, and try this: | | find . -name '*.el' | xargs grep -i lucid | more If I may say opinion on this, having coded for several Emacs releases and supporting both Emacs and XEmacs. To my opinion the right thing to do is to provide compatibility functions (preferrably in separate package, like fsf-compat) And have the code run with the latest functions and parameters. If someone uses older Emacs, he is instructed: Get the compatibility package Or Get older version of the package (and be stuck with it until you upgrade XEmacs) This way the code does not suffer from old lag. Using the latest makes the code also cleaner and easier to maintain. jari

1 participants
0 comments

Re: [PATCH] Last assault on binary-process-output 24 years, 10 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > At 09:01 AM 1/28/00 +0100, Hrvoje Niksic wrote: > >"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > > > >> One correction, I am going to remove this variable by release time, > >> not obsolete it. > > > >Are you sure that's a good idea? Do you think there's code that > >depends on it? > > > >Maybe we could use the dontusethis- stuff to support it during the > >transition period. > > I would like to see it go in its entirety so that we can remove the > C goop that goes with it. That's why I think dontusethis- would come in handy: with it you can (theoretically) convert (setq binary-process-output t) to mean (setq coding-system-for-read 'binary). Then you can get rid of the C goop, and yet have a transitional period of backward compatibility. That's what how dontusethis- was meant to be used.

1 participants
0 comments

Re: help-mode xref 24 years, 10 months

Hrvoje Niksic

Yoshiki Hayashi <yoshiki(a)xemacs.org> writes: > 1. FSF Emacs has nice [back] button when you followd xref. > 2. FSF Emacs shows both function and variable documentation > if symbol is both boundp and fboundp. > > I don't think we need 1. since XEmacs has multiple help buffer. I > just don't know the best way to handle 2, so it describes function > part only. Perhaps it should prompt for user to choose function or > variable. Or it should do the same with FSF Emacs. The latter would be quite acceptable. You might consider implementing a context-sensitive menu that enables the user to choose between function and variable documentation. Also note that the same symbol can denote a face, a charset, etc. More stuff for the context menu. > This patch will make C-h b a bit slower but more useful. How much slower? > 2000-01-25 Yoshiki Hayashi <yoshiki(a)xemacs.org> > > * help.el: Import xref stuff from FSF 20.5. > (with-displaying-help-buffer): Call help-make-xrefs. > Try to make xref for alias and loaded place. > (help-highlight-p): New variable. > (help-highlight-face): Ditto. > (help-xref-symbol-regexp): Ditto. > (help-xref-info-regexp): Ditto. > (help-make-xrefs): New function. > (help-xref-button): Ditto. > (help-follow-mouse): Ditto. > (help-follow): Ditto. > (help-next-ref): Ditto. > (help-previous-ref): Ditto. > > + ;; #### This relies heavily on current output format. > + ;; When it's changed, this won't work. You could fix this by having the help.el functions attach context-sensitive extents to important parts of the text. Then you could add highlighting and stuff by mapping over those extents. This would be less error-prone and would survive gettextization. I've used this technique to handle multi-line messages in log-message and view-lossage, and it worked nicely. > +(defcustom help-highlight-p t > + "*If non-nil, `help-make-xrefs' highlight cross-references. > +Under a window system it highlights them with face defined by > +`help-highlight-face'. On a character terminal highlighted > +references look like cross-references in info mode." > + :group 'help > + :type 'boolean) > + > +(defcustom help-highlight-face 'underline > + "Face used by `help-make-xrefs' to highlight cross-references. > +Must be previously-defined." > + :group 'help > + :type 'face) Umm, no, please don't do this. It's a bit nicer to just define the face you want to use with the right properties, like this: ; assuming that defface now works for dumped code. (defface help-highlight-face '((t (:underline t))) "..." :group ...) If you want compatibility with FSF Emacs, you can create a `help-highlight-face' variable that points to the face. You could also suggest the same change to the FSF developers. The patch is vetoed in its current form, until further discussion.

2 participants
1 comments

Re: [BUG] Coding system changes cause major lossage 24 years, 10 months

Hrvoje Niksic

Katsumi Yamaoka <yamaoka(a)jpl.org> writes: > >>>>> In <87hffyhpnk.fsf(a)inanna.osa.com.au> > >>>>> "Daniel Pittman" <daniel(a)danann.net> wrote: > > > This dies in nnmail-cache-open, signaling `no-such-coding-system > > file-name'. After this *nothing* manages to open, caused by the same > > error. > > I'm not sure of myself, but the following code solves it. > > (unless (fboundp 'si:define-coding-system-alias) > (fset 'si:define-coding-system-alias > (symbol-function 'define-coding-system-alias)) > (defun define-coding-system-alias (alias aliasee) > (si:define-coding-system-alias alias (or aliasee 'binary)))) This workaround makes XEmacs functional again; thanks.

1 participants
0 comments

Windows native version of "makeinfo.exe"? 24 years, 10 months

Damon Lipparelli

Does anyone have a NT native version of "makeinfo.exe"? I'm having trouble building the latest version of "man/xemacs-faq.texi" with XEmacs itself. Thanks, -lipp

2 participants
1 comments

Re: Can't build some texinfo files 24 years, 10 months

Mats Lidell

Hi Martin You wrote: Martin> I care. Thanks! Martin> It would be good if someone did the same for the packages. OK. I can do it at least when it comes to the xrefs to prefs. That is easy. How did you manage do compile the packages in the first place or isn't the packages and the tar-ball generated from the sources in CVS? Martin> It would be further good if all the release engineers Martin> (moiself, Vin, and Andreas) would do this in an automated Martin> fashion for every release. Might be good but is it really necessary to test with all versions. If the main purpose with the CVS archive is to build the packages it would be enough to use one set of tools, the last stable ones. Martin> I cc:ed xemacs-beta. Hope that's OK. It's OK. ;-) Yours -- %% Mats

3 participants
2 comments

Re: [BUG] Coding system changes cause major lossage 24 years, 10 months

Daniel Pittman

On Thu, 27 Jan 2000, Martin Buchholz <martin(a)xemacs.org> wrote: >>>>>> "DP" == Daniel Pittman <daniel(a)danann.net> writes: > > DP> Hrvoje, I think that the failures I am now seeing with my Gnus > DP> installation are caused by the coding system changes you made. > > No, these are _my_ changes that are causing problems. Ooops. Sorry. <hangs head in shame> > You could make sure of that by checking out before the big commit > (untested) > > cvs update -D 2000-01-26 > > but I think it's unnecessary. I confess. > > Is your XEmacs built --with-mule? Yes. Daniel -- Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something. :-) -- Larry Wall in <9695(a)jpl-devvax.JPL.NASA.GOV>

1 participants
0 comments

[BUG] Coding system changes cause major lossage 24 years, 10 months

Daniel Pittman

Hrvoje, I think that the failures I am now seeing with my Gnus installation are caused by the coding system changes you made. I don't have time to investigate for a day or two (sorry) but the details I have are: My normal setup, with the latest CVS as of about an hour before this mail was sent, fires up Gnus. This dies in nnmail-cache-open, signaling `no-such-coding-system file-name'. After this *nothing* manages to open, caused by the same error. A quick grep through Gnus does not show anything that I can see as being bad and all, but I don't really know either Gnus or MULE that well. If you have pGnus handy that might be a good testcase to work out what is going wrong. Reverting to `-r r21-2-latest-beta' fixes the problem, and it worked fine on the latest 21.2 prior to your big commit (plus some other bits. About half a week old or so.) Daniel -- Finishing a book is just like you took a child out in the back yard and shot it. -- Truman Capote

3 participants
2 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 January 2000