September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

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

Jan Vroonhof

Glynn Clements <glynn(a)sensei.co.uk> writes: > I disagree. Even if the use of help-char can be fixed (e.g. removed; > IMHO it ought to be help-keysym), I still don't think that 'backspace > or 'delete should have an 'ascii-character property. It already IS "help-keysym". Setting it to (control h) already works on X and most of the time on ttys. Jan

2 participants
1 comments

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

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Glynn Clements <glynn(a)sensei.co.uk> writes: > > > Presumably there is some reason why the help-char/help-form stuff > > needs to be performed in next-event, but I don't know what it is. > > Probably to do handle things like C-x r C-h. While we're at this, I'd like to point out how ugly keymap names are treated in some circumstances. To see what I mean, press `C-x C-k' to edit a keyboard macro, and then press `C-h l'. Between C-h and l you'll notice that the "(Type ? for further option)" is displayed, which it shouldn't be. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!!

1 participants
0 comments

Status of sources/patches on cvs.xemacs.org 26 years, 2 months

SL Baur

I've seen some build reports already ... The XEmacs 21.0 and experimental 21.2 trees have been updated with all approved[1] Unix-specific patches. I've been running with it most of the day and I *have* briefly tested 21.2. There are numerous unapplied MS Windows patches that will get applied early next week. There is no need to resend these. There is also no need to resubmit patches to the XEmacs lisp libraries. I've not applied those patches either, but will next week. Footnotes: [1] The one Unix/general patch I haven't applied is the ograf patch that intends to fix a memory leak but hasn't been verified by anyone. The corollary is that if you have a patch applicable to Unix that isn't in the current CVS tree, it might be a good idea to resubmit to xemacs-patches(a)xemacs.org.

1 participants
0 comments

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

SL Baur

Olivier Galibert <galibert(a)pobox.com> writes in xemacs-beta(a)xemacs.org: > On Fri, Sep 25, 1998 at 01:17:36PM -0700, SL Baur wrote: >> I question the timing of this change and I see numerous reports of >> problems. Why can't this wait until 21.2? > The fundamental reason is that 21.0 is the first win32 release. I have no problem letting this setting be architecture specific in 21.0/21.1 and finalizing it in all architectures in 21.2. Um, why don't you instead add an appropriate `setq' in sample.emacs with the legend ``This will be a default in 21.2''. The fundamental question why not is `do we intend to get 21.0 out this year?'

1 participants
0 comments

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

SL Baur

Glynn Clements <glynn(a)sensei.co.uk> writes in xemacs-beta(a)xemacs.org: > Martin Buchholz wrote: >> treat the source as if you owned it and just do it Right. >> And (re)read the comment at the start of event-stream.c. Excellent advice. > Do you mean the > * DANGER!! > * > * If you ever change ANYTHING in this file, you MUST run the > * testcases at the end to make sure that you haven't changed > * the semantics of recent-keys, last-input-char, or keyboard > * macros. You'd be surprised how easy it is to break this. > bit? Yup. > Does removing last-input-char altogether constitute changing its > semantics? :) I notice that its docstring currently says: Yes. Grep through all the lisp packages for current usage of it. > : If the value of `last-input-event' is a keyboard event, then > : this is the nearest ASCII equivalent to it. Remember that there is > : NOT a 1:1 mapping between keyboard events and ASCII characters: the set > : of keyboard events is much larger, so writing code that examines this > : variable to determine what key has been typed is bad practice, unless > : you are certain that it will be one of a small set of characters. > Would `[pre]historic baggage: do not use' be a better docstring? Is > there any compelling reason why code shouldn't be forced to use > last-input-event instead? FSF Emacs compatibility. I'll defer to Martin if he disagrees, but I would think a `do not use' docstring and obsoleting the variable would be sufficient. I disagree strongly with removing it altogether without fair warning and at least a year and a release or three with it obsolete. > IOW, is there a good reason for any code to process input in terms of > characters, rather than keysyms? I don't think so. ... > In fact, of what relevance is the ASCII standard? In a Mule world, none, I believe. > Does the underlying protocol need to be exposed to the user (beyond > what is inevitable on text terminals)? I would rather try to shoehorn > TTY-mode into the event-driven GUI framework than the other way around. <AOL> Me too. </AOL>

1 participants
0 comments

Re: XEmacs packages poll 26 years, 2 months

Matt Simmons

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> It looks fairly manageable to me: sb> $ lf pkginfo sb> MANIFEST.Sun MANIFEST.games MANIFEST.sh-script sb> MANIFEST.apel MANIFEST.gnats MANIFEST.slider sb> MANIFEST.auctex MANIFEST.gnus MANIFEST.sounds-au sb> MANIFEST.bbdb MANIFEST.ispell MANIFEST.supercite sb> MANIFEST.calc MANIFEST.mail-lib MANIFEST.texinfo sb> MANIFEST.calendar MANIFEST.mailcrypt MANIFEST.text-modes sb> MANIFEST.cc-mode MANIFEST.mine MANIFEST.textools sb> MANIFEST.debug MANIFEST.misc-games MANIFEST.time sb> MANIFEST.dired MANIFEST.net-utils MANIFEST.tm sb> MANIFEST.edebug MANIFEST.os-utils MANIFEST.w3 sb> MANIFEST.edit-utils MANIFEST.pcl-cvs MANIFEST.xemacs-base sb> MANIFEST.footnote MANIFEST.prog-modes MANIFEST.xemacs-devel sb> MANIFEST.fsf-compat MANIFEST.psgml MANIFEST.zenirc sb> $ Two things: 1) IMHO this looks better: [simmonmt＠auckland]:9:05pm:~> ls /tmp/pkgs Sun dired ispell prog-modes textools apel edebug mail-lib psgml time auctex edit-utils mailcrypt sh-script tm bbdb footnote mine slider w3 calc fsf-compat misc-games sounds-au xemacs-base calendar games net-utils supercite xemacs-devel cc-mode gnats os-utils texinfo zenirc debug gnus pcl-cvs text-modes 2) What happens when there's another informational per-package file? The MANIFEST is the pkgmap from a System V package. What happens when something like a System V pkginfo file comes along? Matt -- Matt Simmons - simmonmt(a)acm.org - http://www.netcom.com/~simmonmt Why do banks charge you a "non-sufficient funds fee" on money they already know you don't have?

1 participants
0 comments

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

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > The right fix should not do a remprop. Then I suggest that help-char should be changed to '(control h) and that tty the code in if (XEVENT (event2)->event_type != key_press_event) retval = 0; else if (CONSOLE_TTY_P (XCONSOLE (EVENT_CHANNEL (event)))) { int ch1, ch2; ch1 = event_to_character (event, 0, 0, 0); ch2 = event_to_character (XEVENT (event2), 0, 0, 0); retval = (ch1 >= 0 && ch2 >= 0 && ch1 == ch2); } else if (EQ (event->event.key.keysym, XEVENT (event2)->event.key.keysym) && event->event.key.modifiers == XEVENT (event2)->event.key.modifiers) retval = 1; else retval = 0; be changed such that it does not try to compare characters but be more intelligent. Jan

3 participants
2 comments

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

SL Baur

Ben Wing <ben(a)xemacs.org> writes in xemacs-review(a)xemacs.org: > We all agree that this is the right thing to do, ... We all most certainly do not agree. I think you folks who want this have been abducted by reptilian aliens in UFOs and gotten a bit of brain surgery. :-) That being said, I appear to be in the minority and I'm resigned to an XEmacs that defaults out of the box to something I detest. I question the timing of this change and I see numerous reports of problems. Why can't this wait until 21.2?

2 participants
1 comments

Patches are getting lost 26 years, 2 months

SL Baur

I'm seeing discrepencies between what is going to xemacs-beta and xemacs-patches. Please make sure patches get submitted to xemacs-patches and try not to cross-post between xemacs-review and xemacs-beta, it confuses me greatly and delays the process of integration. Thanks.

1 participants
0 comments

Re: XEmacs packages poll 26 years, 2 months

SL Baur

Matt Simmons <simmonmt(a)acm.org> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> pkginfo/MANIFEST.gnats sb> pkginfo/MANIFEST.gnus sb> pkginfo/MANIFEST.mailcrypt > Is it too late to request pkginfo/$PACKAGE/MANIFEST? No. How are people coping with MANIFEST.${PACKAGE}? It's working for me. > It keeps ls output more manageable, especially if you have lots of > packages installed. It looks fairly manageable to me: $ lf pkginfo MANIFEST.Sun MANIFEST.games MANIFEST.sh-script MANIFEST.apel MANIFEST.gnats MANIFEST.slider MANIFEST.auctex MANIFEST.gnus MANIFEST.sounds-au MANIFEST.bbdb MANIFEST.ispell MANIFEST.supercite MANIFEST.calc MANIFEST.mail-lib MANIFEST.texinfo MANIFEST.calendar MANIFEST.mailcrypt MANIFEST.text-modes MANIFEST.cc-mode MANIFEST.mine MANIFEST.textools MANIFEST.debug MANIFEST.misc-games MANIFEST.time MANIFEST.dired MANIFEST.net-utils MANIFEST.tm MANIFEST.edebug MANIFEST.os-utils MANIFEST.w3 MANIFEST.edit-utils MANIFEST.pcl-cvs MANIFEST.xemacs-base MANIFEST.footnote MANIFEST.prog-modes MANIFEST.xemacs-devel MANIFEST.fsf-compat MANIFEST.psgml MANIFEST.zenirc $

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