September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Does quail still work after the package update? 26 years, 2 months

SL Baur

Marcus Thiessel <thiessel(a)bbn.hp.com> writes in xemacs-beta(a)xemacs.org: > Are you looking for something specific? No. The installed leim/quail subdirectory is gone. I don't see any place where that might make a difference. > I've found anything to work different (quail), but I am not using it > that intensively.

2 participants
1 comments

RE: [PATCH] to improve case management in search routines. 26 years, 2 months

Richard Harris

Thanks. I wasn't too clear on what was new. Sorry for the confusion. > -----Original Message----- > From: Hrvoje Niksic [SMTP:hniksic＠srce.hr] > Sent: Friday, September 25, 1998 1:35 PM > To: XEmacs Beta List > Subject: Re: [PATCH] to improve case management in search routines. > > Richard Harris <RHarris(a)gensym.com> writes: > > > But I wasn't talking about the irrelevant case. I thought this > > would be clear. > > It's not clear at all. Didier didn't introduce anything new -- this > behaviour has existed in isearch for ages. How *does* isearch work in > such buffers? > > > The lisp prints a message with a name in uppercase. The user > > searches for this name (in uppercase) in a buffer. > > The user needs to just search in lowercase. Or, if he really really > wants to use uppercase, set `search-caps-disable-folding' to nil in > that buffer. > > -- > Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia > --------------------------------+-------------------------------- > If anything goes wrong, blame the random-number generator!

1 participants
0 comments

Help-char bogosoties [was Re: delete-key-deletes-forward] 26 years, 2 months

Jan Vroonhof

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > [Glyn's fix to (remprop 'backspace ascii-char)] > > It does seem to work. However as you suggest it may not be the right > fix. Maybe event loop key look-up is slightly bogus when in the > minibuffer. Looking for other fixes I found that the problem lies in event_matches_key_specifier_p which is used to check whether help-char is bound. (To see the problem do a (setq help-form "ouch!") and then you git it even without read-minibuffer. If the key specifier to be matched is a char then the event is forced to char before comparison (using the 'ascii-char property if need be). However if the key specifier is a normal specifier then nothing is done. So we can also fix the problem by setting (setq help-char '(control h)) However for some reason this does not work on TTY's (Backspace is till considered help-char with the ascii-character property set). The in code event_matches_key_specifier_p seems indeed to handle things differently for ttys. Jan P.S. Note with (remprop 'backspace 'ascii-char) 'C-q Backspace' no longer insets a ^H, I am not sure that is a loss.

3 participants
2 comments

CANNOT pui-install-selected-packages over xemacs-SUMO-1998-09-19.tar.gz 26 years, 2 months

Adrian Aichner

First I tried using Options Customize List Packages to install updated packages over my package directory which predates Steven's xemacs-SUMO-1998-09-19.tar.gz. I was left with a hierarchy of /export/home/tmp/packages-21.0: total 726 drwxr-xr-x 7 aichner stdsoft 512 Sep 25 11:25 . drwxr-xr-x 20 aichner stdsoft 2048 Sep 20 10:40 .. drwxr-xr-x 28 aichner stdsoft 1024 Sep 25 11:28 etc drwxr-xr-x 3 aichner stdsoft 3072 Sep 25 11:29 info drwxr-xr-x 77 aichner stdsoft 1536 Sep 25 12:32 lisp drwxr-xr-x 6 aichner stdsoft 512 Sep 25 11:29 man drwxr-xr-x 7 aichner stdsoft 512 Sep 25 12:30 pkginfo /export/home/tmp/packages-21.0/pkginfo: total 66 drwxr-xr-x 7 aichner stdsoft 512 Sep 25 12:30 . drwxr-xr-x 7 aichner stdsoft 512 Sep 25 14:02 .. -rw-r--r-- 1 aichner stdsoft 1234 Sep 20 04:24 MANIFEST.calendar -rw-r--r-- 1 aichner stdsoft 993 Sep 20 01:56 MANIFEST.dired -rw-r--r-- 1 aichner stdsoft 3621 Sep 20 05:45 MANIFEST.edit-utils -rw-r--r-- 1 aichner stdsoft 1840 Sep 20 02:00 MANIFEST.efs -rw-r--r-- 1 aichner stdsoft 793 Sep 20 02:02 MANIFEST.mail-lib -rw-r--r-- 1 aichner stdsoft 637 Sep 20 05:48 MANIFEST.pcl-cvs -rw-r--r-- 1 aichner stdsoft 3352 Sep 20 07:08 MANIFEST.psgml -rw-r--r-- 1 aichner stdsoft 3571 Sep 20 05:38 MANIFEST.vm -rw-r--r-- 1 aichner stdsoft 2314 Sep 20 01:45 MANIFEST.xemacs-base drwxr-xr-x 22 aichner stdsoft 1024 Sep 25 13:22 etc drwxr-xr-x 2 aichner stdsoft 3072 Sep 25 13:57 info drwxr-xr-x 63 aichner stdsoft 1536 Sep 25 13:57 lisp drwxr-xr-x 24 aichner stdsoft 512 Sep 25 12:49 man drwxr-xr-x 2 aichner stdsoft 2048 Sep 25 13:58 pkginfo /export/home/tmp/packages-21.0/pkginfo/pkginfo: total 196 drwxr-xr-x 2 aichner stdsoft 2048 Sep 25 13:58 . drwxr-xr-x 7 aichner stdsoft 512 Sep 25 12:30 .. -rw-r--r-- 1 aichner stdsoft 931 Sep 20 00:55 MANIFEST.Sun <lines deleted by Adrian> -rw-r--r-- 1 aichner stdsoft 2810 Sep 20 05:53 MANIFEST.zenirc So I suspected the introduction of MANIFESTs makes the new installation interface incompatible with my old packages-21.0 directory structure. I replace the contents of packages-21.0 with Steven's ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-SUMO-1998-09-19.tar.gz and installed ftp://ftp.xemacs.org/pub/xemacs/packages/package-get-base.el-1998-09-19 as lisp/package-get-base.el in my XEmacs installation, which is emacs-version "21.0 \"Norwegian\" XEmacs Lucid" on system-configuration "sparc-sun-solaris2.5.1". Again, I got packages installed into the pkginfo directory with manifests stored in pkginfo/pkginfo. /export/home/tmp/packages-21.0: total 39770 drwxr-xr-x 7 aichner stdsoft 512 Sep 20 11:02 . drwxr-xr-x 20 aichner stdsoft 2048 Sep 25 14:30 .. drwxr-xr-x 29 aichner stdsoft 1024 Sep 20 07:08 etc -rw-r--r-- 1 aichner stdsoft 217369 Sep 20 11:02 gunzip-c-tar-xvf.err drwxr-xr-x 2 aichner stdsoft 3072 Sep 20 07:08 info drwxr-xr-x 80 aichner stdsoft 1536 Sep 20 07:08 lisp drwxr-xr-x 32 aichner stdsoft 512 Sep 20 07:08 man drwxr-xr-x 2 aichner stdsoft 2560 Sep 20 07:08 pkginfo -rw-r--r-- 1 aichner stdsoft 20094175 Sep 20 07:13 xemacs-SUMO-1998-09-19.tar.gz /export/home/tmp/packages-21.0/pkginfo: total 280 drwxr-xr-x 7 aichner stdsoft 2560 Sep 25 14:34 . drwxr-xr-x 7 aichner stdsoft 512 Sep 20 11:02 .. -rw-r--r-- 1 aichner stdsoft 931 Sep 20 00:55 MANIFEST.Sun <lines deleted by Adrian> -rw-r--r-- 1 aichner stdsoft 2810 Sep 20 05:53 MANIFEST.zenirc drwxr-xr-x 4 aichner stdsoft 512 Sep 25 14:34 etc drwxr-xr-x 2 aichner stdsoft 512 Sep 25 14:34 info drwxr-xr-x 3 aichner stdsoft 512 Sep 25 14:34 lisp drwxr-xr-x 3 aichner stdsoft 512 Sep 25 14:34 man drwxr-xr-x 2 aichner stdsoft 512 Sep 25 14:34 pkginfo Any clues what's going on here? Thanks, Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

2 participants
1 comments

Re: [PATCH] to improve case management in search routines. 26 years, 2 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > > This is problematic. For all I know, there can be valid user code > > that uses that macro. Adding an argument will make all that code > > fail. I think you should choose a different name, or perhaps a new > > macro (`with-caps-disable-folding-regexp'?) > > I know this is problematic, but I envisioned the other > possibilities, and came up with the conclusion that risking a > user-code breakage (this is not the first time it could happen) is > the best choice. Here's why: The macro _currently assumes a regular > expression_. Hmm. In that case, obsolete that name, and use a totally different name for the new macro, along with the REGEXP flag. > - either we have a regexp-flag, that's the change I proposed, That's perfectly fine, as long as you take care not to hose the users. > We did far worse with the `concat' interface change (which I totally > agree with). Not really. `concat' had this warning for ages: Do not use individual integers as arguments! The behavior of `concat' in that case will be changed later! If your program passes an integer as an argument to `concat', you should change it right away not to do so. Also, the old code using `concat' fails with a clear error message. In this case, the old code saying, for instance: (with-caps-disable-folding STRING FORM1 FORM2 ...) *No* error will be signaled, but FORM1 will be evaluated and used as the REGEXP flag. Subtle and evil. > > The argument that the changes are affordable because the packages > > don't use the macro does not stand because we don't know how much > > user code uses the macros. What we call "packages" is but one > > part of Lisp code written by our users. With your changes, > > otherwise perfectly valid code using documented interface will > > fail in various obscure ways. > > See above. I'm not sure how much user code actually know and use > this macro. Neither am I, and that's the whole point. For all I know, lots of code might use it. I know I liked it, and used it in my internal customizations. > What's more, the change is not /that/ complicated to upgrade. It is very complicated to detect. I really think keeping the old macro and giving the new one another name is the easiest path in this case. It's been done countless times (add-menu -> add-submenu, etc.) and the compatibility effort is in most cases worth it. Breaking backward compatibility is acceptable, but breaking it subtly is not. All IMHO, of course. > > You should write a modification of the `with-caps-disable-folding' > > macro and use it consistently. > > I think I'll write another macro for use in interactive functions > rather. Something like `interactive-with-caps-disable-folding' Yes, that's what I meant by "modification" of it. > Footnotes: [1] One day, I'd like to see a coherent naming convention > appear: either `re-foobar', or `foobar-regexp', but only one. With > the number of symbols we're reaching in XEmacs, I find it very > important to be strict on naming conventions. Stricter than we are > now. I have some other pedantic changes in mind, like renaming all > *-hook variables to *-hooks You mean the other way around: hooks->hook? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Thou Who might be our Father Who perhaps may be in Heaven... -- Roger Zelazny

1 participants
0 comments

Re: delete-key-deletes-forward 26 years, 2 months

Jan Vroonhof

Glynn Clements <glynn(a)sensei.co.uk> writes: > > With this change (which I basically agree with) there is a little > > problem - if you do M-x set-variable RET, then make a typo, there > > is no way to backspace... the delete key tries to delete forward, > > so That makes 3 of us. > > I suggested the following patch: Did you post it to xemacs-patches(a)xemacs.org to get it into the formal review process? > (remprop 'backspace 'ascii-character) > (remprop 'delete 'ascii-character) It does seem to work. However as you suggest it may not be the right fix. Maybe event loop key look-up is slightly bogus when in the minibuffer. Jan

2 participants
1 comments

Re: [PATCH] to improve case management in search routines. 26 years, 2 months

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Richard Harris <RHarris(a)gensym.com> writes: Strange ... it's the second reply of yours to mails from Richard Harris I didn't receive yet. --didier

1 participants
0 comments

Re: [PATCH] to improve case management in search routines. 26 years, 2 months

Hrvoje Niksic

Richard Harris <RHarris(a)gensym.com> writes: > But I wasn't talking about the irrelevant case. I thought this > would be clear. It's not clear at all. Didier didn't introduce anything new -- this behaviour has existed in isearch for ages. How *does* isearch work in such buffers? > The lisp prints a message with a name in uppercase. The user > searches for this name (in uppercase) in a buffer. The user needs to just search in lowercase. Or, if he really really wants to use uppercase, set `search-caps-disable-folding' to nil in that buffer. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

1 participants
0 comments

Re: [PATCH] to improve case management in search routines. 26 years, 2 months

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > * You should make an obsolete isearch- alias so that old compiled code > that uses the `with-caps-disable-folding' macro doesn't fail; OK. > * FSF Emacs has a different version of `isearch-no-upper-case-p', > which perhaps works better. (our has a "fixme" comment.) OK. I'll look at it. > > The other one is one more argument (regexp-flag) to the macro > > with-caps-disable-folding, which is moved away from isearch too. > > > > I think we can afford those changes: they lead to only 2 other > > modifications in the core lisp packages, and none of the packages I > > have installed (almost all of them) use those functions. > > This is problematic. For all I know, there can be valid user code > that uses that macro. Adding an argument will make all that code > fail. I think you should choose a different name, or perhaps a new > macro (`with-caps-disable-folding-regexp'?) I know this is problematic, but I envisioned the other possibilities, and came up with the conclusion that risking a user-code breakage (this is not the first time it could happen) is the best choice. Here's why: The macro _currently assumes a regular expression_. In Emacs, there are currently 2 philosophies co-existing for string/regexp routines: - either we have a regexp-flag, that's the change I proposed, - or we have two functions, one for strings and one for regexps. But there, it's always the string function that has the generic name (like query-replace or search-forward), and the regexp function that has a derived name (like re-search-forward, or query-replace-regexp). If we decide to adopt the second philosophy, user code will be broken all the same because `with-caps-disable-folding' will turn out to deal with strings, and the new one (with the old behavior) will be named `re-with-caps-disable-folding', or `with-caps-disable-folding-regexp'.[1] I don't want to introduce a new convention just for this macro. I don't want to call the new one with-caps-disable-folding-string. That's why I think that risking user-code breakage is the best solution. We did far worse with the `concat' interface change (which I totally agree with). > The argument that the changes are affordable because the packages > don't use the macro does not stand because we don't know how much user > code uses the macros. What we call "packages" is but one part of Lisp > code written by our users. With your changes, otherwise perfectly > valid code using documented interface will fail in various obscure > ways. See above. I'm not sure how much user code actually know and use this macro. What's more, the change is not /that/ complicated to upgrade. Again, changing all occurences of concat was much more of a pain. > You should write a modification of the `with-caps-disable-folding' macro and > use it consistently. I think I'll write another macro for use in interactive functions rather. Something like `interactive-with-caps-disable-folding' Footnotes: [1] One day, I'd like to see a coherent naming convention appear: either `re-foobar', or `foobar-regexp', but only one. With the number of symbols we're reaching in XEmacs, I find it very important to be strict on naming conventions. Stricter than we are now. I have some other pedantic changes in mind, like renaming all *-hook variables to *-hooks -- / / _ _ 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: [PATCH] to improve case management in search routines. 26 years, 2 months

Hrvoje Niksic

Richard Harris <RHarris(a)gensym.com> writes: > Perhaps it doesn't matter, but I'd like to point out that this > feature will need to be turned off for Lisp mode buffers, since in > many Lisp systems, system output contains names (symbols) that are > in uppercase, while in the source files, these names appear in > lowercase. That's irrelevant because typing lowercase letters will still match uppercase. Only if you explicitly type in uppercase stuff, you get case-sensitive matches. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Manic depression is cool... your body can make its own drugs.

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 September 1998