March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Backspace direction reversion 25 years, 8 months

Michael Sperber

[ I moved this exclusively to xemacs-beta. ] >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> The only other applications that use Delete to delete backwards are Martin> shells and other Emacsen. Shells are special because of historical Martin> tty legacy braindamage - the only editing possible was backward Martin> deletion, using exactly one designated backward erase key (no way to Martin> define two). *Any* application accepting input from stdio works this way. Passwords, vi command lines, ... And, by the way, shells are special in that I use them all the time. Also, I don't see how converts from FSFmacs are unimportant in this picture. I'm not arguing whether one behavior or the other is braind-dead---plenty of XEmacs keybindings are braindead. In that sense, there's a *huge* amount of "legacy braindamage" in XEmacs. As long as there's no decision in principle to update the way XEmacs is operated by a keyboard according to more "modern" usage, I don't think it makes sense to change just this little detail. You're talking about your users, but if we really care about them, we should have a survey at least on xemacs-beta to find out. Martin> Commercial software tends to be Motify, which uses the industry Martin> standard user interface for Backspace and Delete. Well, how many commercial software packages do you use under Unix? The ones I use I would rather not be associated with. Martin> New free software will use libraries like GTK or Qt, which I Martin> have never used, but would be surprised if they didn't also Martin> use the industry standard user interface. Note the word "will." We're not there yet. Martin> P.S. Oh, yeah, xedit on Unix (not VM/CMS) does things Steve's way. Martin> An editor I would rather not be associated with. So, you would rather be associated with Windows and Notepad? :-) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Backspace direction reversion 25 years, 8 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > There are keyboards that can fake this code out. I consider it every > bit as broken for the Big Key on the upper right side of the keyboard > to not delete backwards as to enter the help subsystem. <rant meta="skippable because followed by real argument later"> So why don't you bind that key to the 'Backspace' keysym then? I think the whole cause of this problem is that X keysyms and the text printed on the keyboard were to close. This caused the "Key above return" to have the keysym "Backspace" on PC style keyboards (FYI almost every Workstation has PC style keyboards now), where it should really have been "delete". However we can not change all that. Effectively what has happened is that the-keysym-that-deletes-backward is now backspace. What needs to happen is for people running older setups to realize this and rebind their "Key above return" of </rant> > > So apparently XEmacs thinks that on your keyboard Backspace can be > > generated without a modifier and thus that it is safe to change the > > keyboard. This is not a question of defaults. This looks like a real bug. > > Perhaps. Someone fix it if you want this patch in. The problem is: You keyboard seems to be very exceptional so you need to give better bug reports and help a bit to find a better heuristic. So a. how DO you generate 'backspace' on your keyboard? b. On my keyboard (Sun-5) and a nearby Linux machine 'xev' says that the Delete key has an empty Xlookupstring, whereas backspace has an "^H". I am assuming that on your keyboard the 'delete' keysym generates some ascii rubout stuff (either ^? or C-h). Could you chekc with xev? Then we can do something like (defsubst delete-forward-p () (and delete-key-deletes-forward (or (not (eq (device-type) 'x)) (eq 'delete-key-deletes-forward 'force) (and (x-keysym-on-keyboard-sans-modifiers-p 'backspace) (x-keysym-empty-lookup-string-p 'delete))))) It would need somebody to write x-keysym-empty-lookup-string-p or something like that though. I am not even sure it can be done. > > P.S. Let's all remember that set-mark-command is also bound to a key > > which can be close to impossible to generate. Can you say 'telnet.exe'? > > `telnet.exe'? We removed VMS support well over a year ago. What do > you mean? Windows Telnet. The program that comes with every windows install. Neither C-S-2 nor C-SPC produce anything there. Jan

2 participants
1 comments

Distribution Build Report for XEmacs-21.2.13 25 years, 8 months

Steven Baur

Greetings XEmacs beta testers. I am in the process of building the next distribution of XEmacs 21.2. I have tested the attached configuration. Sincerely, The XEmacs Build 'Bot -- uname -a: BSD/OS camelot-soft.camelot-soft.com 3.0 BSDI BSD/OS 3.0 Kernel #0: Thu Jul 17 23:30:01 PDT 1997 root＠camelot-soft.camelot-soft.com:/usr/src/sys/compile/CAMELOT i386 ./configure '--prefix=/usr/home/steveb/staging' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.2-b13 "Demeter" configured for `i386-pc-bsdi3.0'. Where should the build process find the source code? /usr/home/steveb/staging/xemacs-21.2 What installation prefix should install use? /usr/home/steveb/staging What operating system and machine description files should XEmacs use? `s/bsdos3.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? none Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in Mule (multi-lingual) support. movemail will use "flock" for locking mail spool files.

1 participants
0 comments

Re: Backspace direction reversion 25 years, 8 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > Please, Guys. Let's get NOT get emotional about this please! (It must > be the spring air. There is even an endiannes flamewar on linux-kernel). Well, Spring was starting to come here in Japan and then the past few days it has returned to Winter. Maybe that's it. SL> right of the keyboard and getting help sucks. I think we should be SL> conservative about it and leave the setting as it is in 21.0. It is a SL> lot safer, IMO. > Personally i think we have been conservative about it way too long. We > really should have done it for 21.0 because we had a good reason then: > The NT port (which is a good justification) and a major version > number increase. That's a good reason. I reject and continue to reject pleas to emotion. Make me *want* to change it by convincing me logically and we'll do it for 21.0, even now, days before release. > The argument _against_ doing it in 21.0 (and maybe 20.4) is that the > tty-erase-char stuff has not been tried in the field yet. That's not a good excuse, it's not an excuse I would consider acceptable, and it's not an excuse I'm citing. > Anyway, Steve, How come it is broken for you? This is the code that is > used > (defsubst delete-forward-p () > (and delete-key-deletes-forward > (or (not (eq (device-type) 'x)) > (x-keysym-on-keyboard-sans-modifiers-p 'backspace)))) There are keyboards that can fake this code out. I consider it every bit as broken for the Big Key on the upper right side of the keyboard to not delete backwards as to enter the help subsystem. > So apparently XEmacs thinks that on your keyboard Backspace can be > generated without a modifier and thus that it is safe to change the > keyboard. This is not a question of defaults. This looks like a real bug. Perhaps. Someone fix it if you want this patch in. > P.S. Let's all remember that set-mark-command is also bound to a key > which can be close to impossible to generate. Can you say 'telnet.exe'? `telnet.exe'? We removed VMS support well over a year ago. What do you mean? P.S. set-mark-command was bound to Control Shift 2 on the AT&T Unix PC keyboard and I survived. Having *anything* wrong with delete-backward-char is unacceptable.

2 participants
1 comments

Re: Not autosaving when SIGHUP?? 25 years, 8 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > karl(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: >> I think that XEmacs 21.2 isn't autosaving when it's signalled. Will >> someone else please test this? I discovered it when an unmapped >> XEmacs' gnuserv died. > The autosaving int the fatal error handler was turned off. The > reasoning was that if you get SIGSEGV you do not want to overwrite > your valid autosaves with freshly corrupted data. > However on SIGPPIPE and SIGHUP (and maybe others) there should be no > reason not do the autosaves. We *should not* ever be crashing on SIGPIPE, it is supposed to be trapped and handled. Any condition where SIGPIPE is raised in XEmacs indicates a grievous coding error somewhere. Agreed about SIGHUP.

1 participants
0 comments

Re: Backspace direction reversion 25 years, 8 months

Martin Buchholz

>>>>> "M" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "P" == P E Jareth Hein <jareth(a)camelot.co.jp> writes: P> - A majority of new users are coming from IBM-clone, Macintosh or P> Amiga backgrounds now, and they are all used to the 'backspace P> deletes the character before the cursor and moves backwards' P> functionality. If we wish to attract new users or at least make P> them feel more comfortable, supporting this as a default they don't P> have to think about is a win. M> Well, the problem is that, on Unix, this behavior disagrees with the M> rest of the system. It might be a good idea on NT, but not on Unix. The person who originally pushed me to change the default was Ben, who was unable to actually type the change himself. So consider the original change to make delete-key-deletes-forward to default to yes to be Ben's. I am merely strongly defending his opinion. The only other applications that use Delete to delete backwards are shells and other Emacsen. Shells are special because of historical tty legacy braindamage - the only editing possible was backward deletion, using exactly one designated backward erase key (no way to define two). Commercial software tends to be Motify, which uses the industry standard user interface for Backspace and Delete. New free software will use libraries like GTK or Qt, which I have never used, but would be surprised if they didn't also use the industry standard user interface. Martin P.S. Oh, yeah, xedit on Unix (not VM/CMS) does things Steve's way. An editor I would rather not be associated with.

1 participants
0 comments

XEmacs 21.0.65 crashes on Linux 2.2.2, SMP, i686, libc.so.5.4.44 25 years, 8 months

Heiko Münkel

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.0 "20" [Lucid] (i586-pc-linux) of Wed Mar 10 1999 on enterprise configured using `configure --prefix=/prog/xemacs/21.0.65 --exec-prefix=/prog/xemacs/21.0.65/i586-pc-linux-gnulibc1 --with-dialogs=motif --external-widget --with-pop --with-site-lisp --with-png' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: The XEmacs crashed during running one of my own lisp functions. I'll send you the lisp code, if you need it, but you should be warned: it is a little bit complex and it chrashes most times but not ever. The following is the Lisp backtrace. After the lisp backtrace you'll find the C stack backtrace and after that some info about the installation. ------------------------------------------------------------------- backtrace() # bind (standard-output print-escape-newlines print-length) byte-code("..." [pop-to-buffer debugger-buffer erase-buffer t 50 print-length print-escape-newlines standard-output backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable debugger-args (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?\* 0 exit "Return value: " debugger-value prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" buffer-read-only inhibit-trace recursive-edit] 3) # (unwind-protect ...) # (unwind-protect ...) # bind (last-command this-command unread-command-event last-input-event last-input-char last-input-time last-command-event last-command-char overriding-local-map load-read-function standard-input standard-output cursor-in-echo-area) # (unwind-protect ...) # bind (debugger-value debug-on-error debug-on-quit debug-on-signal debugger-buffer debugger-old-buffer debugger-step-after-exit executing-macro debugger-outer-match-data debugger-outer-load-read-function debugger-outer-overriding-local-map debugger-outer-last-command debugger-outer-this-command debugger-outer-unread-command-event debugger-outer-unread-command-events debugger-outer-last-input-event debugger-outer-last-input-char debugger-outer-last-input-time debugger-outer-last-command-event debugger-outer-last-command-char debugger-outer-standard-input debugger-outer-standard-output debugger-outer-cursor-in-echo-area debugger-args) debug(error (wrong-type-argument listp [1] Segmentation fault /prog/xemacs/21.0.65/i586-pc-linux-gnulibc1/bin/xemacs (core dumped) ------------------------------------------------------------------- (gdb) where #0 0x815d373 in print_internal (obj=142243656, printcharfun=137765444, escapeflag=1) at print.c:1213 #1 0x815ca59 in print_cons (obj=142693128, printcharfun=137765444, escapeflag=1) at print.c:914 #2 0x815d385 in print_internal (obj=142693164, printcharfun=137765444, escapeflag=1) at print.c:1214 #3 0x815b9b5 in Fprin1 (object=142693164, stream=137765444) at print.c:506 #4 0x80be714 in Fbacktrace (stream=137765444, detailed=137656944) at eval.c:4936 #5 0x80b16b3 in fatal_error_signal (sig=11) at emacs.c:245 #6 0xbfffba24 in ?? () #7 0x815ca59 in print_cons (obj=142693128, printcharfun=143159512, escapeflag=1) at print.c:914 #8 0x815d385 in print_internal (obj=142693164, printcharfun=143159512, escapeflag=1) at print.c:1214 #9 0x815b9b5 in Fprin1 (object=142693164, stream=143159512) at print.c:506 #10 0x80be714 in Fbacktrace (stream=143159512, detailed=137656916) at eval.c:4936 #11 0x80ba96a in funcall_recording_as (recorded_as=137741428, nargs=0, args=0xbfffc0fc) at eval.c:3197 #12 0x80babf3 in Ffuncall (nargs=1, args=0xbfffc0fc) at eval.c:3238 #13 0x808d996 in Fbyte_code (bytestr=138082020, vector=142384424, maxdepth=7) at bytecode.c:416 #14 0x80ba167 in Feval (form=142686580) at eval.c:3063 #15 0x80b5329 in Fprogn (args=142680576) at eval.c:758 #16 0x808dd75 in Fbyte_code (bytestr=139002644, vector=143215904, maxdepth=47) at bytecode.c:554 #17 0x80bbc90 in funcall_lambda (fun=142213000, nargs=2, arg_vector=0xbfffc648) at eval.c:3597 #18 0x80baafe in funcall_recording_as (recorded_as=138012192, nargs=2, args=0xbfffc644) at eval.c:3214 #19 0x80bb3e2 in Fapply (nargs=2, args=0xbfffc68c) at eval.c:3463 #20 0x80bc278 in apply1 (fn=138012192, arg=142693212) at eval.c:3895 #21 0x80bf172 in call_debugger_259 (arg=142693212) at eval.c:336 #22 0x80b6ef9 in internal_catch (tag=137740240, func=0x80bf160 <call_debugger_259>, arg=142693212, threw=0xbfffc72c) at eval.c:1328 #23 0x80b4a8f in signal_call_debugger (conditions=136630976, sig=137657084, data=142693140, active_handlers=137656916, signal_vars_only=0, stack_trace_displayed=0xbfffc7a0, debugger_entered=0xbfffc79c) at eval.c:390 #24 0x80b7c1b in signal_1 (sig=137657084, data=142693140) at eval.c:1946 #25 0x80b802a in Fsignal (error_symbol=137657084, data=142693140) at eval.c:2044 #26 0x809d0c3 in Fcdr (list=142243656) at data.c:105 #27 0x811cc5c in mapcar1 (leni=160, vals=0xbfffc870, fn=141759644, seq=142139848) at fns.c:3240 #28 0x811cdac in Fmapcar (fn=141759644, seq=142139848) at fns.c:3287 #29 0x80ba96a in funcall_recording_as (recorded_as=137751540, nargs=2, args=0xbfffcc80) at eval.c:3197 #30 0x80babf3 in Ffuncall (nargs=3, args=0xbfffcc80) at eval.c:3238 #31 0x808d996 in Fbyte_code (bytestr=136749300, vector=136749384, maxdepth=9) at bytecode.c:416 #32 0x80bbc90 in funcall_lambda (fun=136749432, nargs=2, arg_vector=0xbfffce78) at eval.c:3597 #33 0x80baafe in funcall_recording_as (recorded_as=137975648, nargs=2, args=0xbfffce74) at eval.c:3214 #34 0x80bb267 in Fapply (nargs=4, args=0xbfffce74) at eval.c:3408 #35 0x80ba755 in funcall_recording_as (recorded_as=137741176, nargs=4, args=0xbfffce70) at eval.c:3178 #36 0x80babf3 in Ffuncall (nargs=5, args=0xbfffce70) at eval.c:3238 #37 0x808d996 in Fbyte_code (bytestr=136759904, vector=136759940, maxdepth=11) at bytecode.c:416 #38 0x80bbc90 in funcall_lambda (fun=136759988, nargs=3, arg_vector=0xbfffcf10) at eval.c:3597 #39 0x80bb538 in apply_lambda (fun=136759988, numargs=3, unevalled_args=137656916) at eval.c:3501 #40 0x80ba3af in Feval (form=141759596) at eval.c:3085 #41 0x80b5329 in Fprogn (args=141759296) at eval.c:758 #42 0x80b5aa9 in FletX (args=141759188) at eval.c:857 #43 0x80b9cb5 in Feval (form=141758636) at eval.c:2997 #44 0x80b5329 in Fprogn (args=141758624) at eval.c:758 #45 0x80bbc00 in funcall_lambda (fun=141760192, nargs=1, arg_vector=0xbfffd1f4) at eval.c:3589 #46 0x80bb538 in apply_lambda (fun=141760192, numargs=1, unevalled_args=137656916) at eval.c:3501 #47 0x80ba3af in Feval (form=141760504) at eval.c:3085 #48 0x80b5329 in Fprogn (args=141760528) at eval.c:758 #49 0x80bbc00 in funcall_lambda (fun=141760468, nargs=1, arg_vector=0xbfffd3f0) at eval.c:3589 #50 0x80baafe in funcall_recording_as (recorded_as=141760468, nargs=1, args=0xbfffd3ec) at eval.c:3214 #51 0x80bc340 in call1 (fn=141760468, arg0=142703424) at eval.c:3921 #52 0x811cc4c in mapcar1 (leni=12, vals=0x0, fn=141760468, seq=142736348) at fns.c:3237 #53 0x811ceb9 in Fmapc (fn=141760468, seq=142736348) at fns.c:3320 #54 0x80ba140 in Feval (form=141760456) at eval.c:3063 #55 0x80b5329 in Fprogn (args=141760444) at eval.c:758 #56 0x80b5f79 in Flet (args=141760408) at eval.c:924 #57 0x80b9cb5 in Feval (form=141760336) at eval.c:2997 #58 0x80b4fe9 in Fif (args=141760324) at eval.c:697 #59 0x80b9cb5 in Feval (form=141760312) at eval.c:2997 #60 0x80b5329 in Fprogn (args=141760264) at eval.c:758 #61 0x80bbc00 in funcall_lambda (fun=141760732, nargs=1, arg_vector=0xbfffd828) at eval.c:3589 #62 0x80bb538 in apply_lambda (fun=141760732, numargs=1, unevalled_args=137656916) at eval.c:3501 #63 0x80ba3af in Feval (form=141931788) at eval.c:3085 #64 0x80b5329 in Fprogn (args=141761248) at eval.c:758 #65 0x80bbc00 in funcall_lambda (fun=141932220, nargs=3, arg_vector=0xbfffda24) at eval.c:3589 #66 0x80baafe in funcall_recording_as (recorded_as=141932220, nargs=3, args=0xbfffda20) at eval.c:3214 #67 0x80bb3e2 in Fapply (nargs=2, args=0xbfffda6c) at eval.c:3463 #68 0x80bc278 in apply1 (fn=141932220, arg=138982344) at eval.c:3895 #69 0x808f607 in Fcall_interactively (function=141892132, record_flag=137656944, keys=137656916) at callint.c:397 #70 0x80b8db3 in Fcommand_execute (cmd=141892132, record=137656944, keys=137656916) at eval.c:2584 #71 0x80ba80e in funcall_recording_as (recorded_as=137741120, nargs=2, args=0xbfffde04) at eval.c:3193 #72 0x80babf3 in Ffuncall (nargs=3, args=0xbfffde04) at eval.c:3238 #73 0x808d996 in Fbyte_code (bytestr=136813588, vector=136813748, maxdepth=17) at bytecode.c:416 #74 0x80bbc90 in funcall_lambda (fun=136814072, nargs=1, arg_vector=0xbfffdf2c) at eval.c:3597 #75 0x80baafe in funcall_recording_as (recorded_as=138013452, nargs=1, args=0xbfffdf28) at eval.c:3214 #76 0x80babf3 in Ffuncall (nargs=2, args=0xbfffdf28) at eval.c:3238 #77 0x8090fe1 in Fcall_interactively (function=138013452, record_flag=137656916, keys=137656916) at callint.c:949 #78 0x80b8db3 in Fcommand_execute (cmd=138013452, record=137656916, keys=137656916) at eval.c:2584 #79 0x80f2ab2 in execute_command_event (command_builder=0x849c1a0, event=141268384) at event-stream.c:4346 #80 0x80f361c in Fdispatch_event (event=141268384) at event-stream.c:4637 #81 0x8096ee3 in Fcommand_loop_1 () at cmdloop.c:579 #82 0x8096c2d in command_loop_1 (dummy=137656916) at cmdloop.c:494 #83 0x80b7356 in condition_case_1 (handlers=137657028, bfun=0x8096be0 <command_loop_1>, barg=137656916, hfun=0x8095fd0 <cmd_error>, harg=137656916) at eval.c:1653 #84 0x80970ec in command_loop_2 (dummy=137656916) at cmdloop.c:256 #85 0x80b6ef9 in internal_catch (tag=137731316, func=0x80970b0 <command_loop_2>, arg=137656916, threw=0x0) at eval.c:1328 #86 0x809645b in initial_command_loop (load_me=137656916) at cmdloop.c:305 #87 0x80b2a28 in xemacs_21_0_b65_i586_pc_linux (argc=1, argv=0xbfffe2a4, envp=0xbfffe2ac, restart=0) at emacs.c:1705 #88 0x80b31ad in main (argc=1, argv=0xbfffe2a4, envp=0xbfffe2ac) #89 0x8079d8e in _start () ------------------------------------------------------------------- M-x describe-installation uname -a: Linux enterprise 2.0.32 #11 Sun Apr 5 10:23:41 MEST 1998 i586 unknown ./configure '--prefix=/prog/xemacs/21.0.65' '--exec-prefix=/prog/xemacs/21.0.65/i586-pc-linux-gnulibc1' '--with-dialogs=motif' '--external-widget' '--with-pop' '--with-site-lisp' '--with-png' XEmacs 21.0-b65 "20" configured for `i586-pc-linux'. Where should the build process find the source code? /phys/hdb7/prog/xemacs/src/xemacs-21.0.65/xemacs-20 What installation prefix should install use? /prog/xemacs/21.0.65 What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the Linux C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access Using Lisp_Objects with minimal tagbits. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Recent keystrokes: misc-user Recent messages (most recent first): Parsing /home/muenkel/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug...

1 participants
0 comments

Re: DANGER: Re: Backspace direction reversion 25 years, 8 months

SL Baur

Olivier Galibert <galibert(a)pobox.com> writes in xemacs-beta(a)xemacs.org: > On Fri, Mar 12, 1999 at 10:41:01AM +0100, Michael Sperber [Mr. Preprocessor] wrote: >> All the rest of Unix has Delete-moves-backwards. > Negative on that, Houston. > OG. > PS: Motif, gtk, Qt. Motif is broken. It has always been broken in numerous ways. Even worse, it killed off a perfectly logical and infinitely better GUI (IMO). gtk is hopelessly broken. It is useless to hold up as a model of good design. If GNOME/GTK are examples of thought-out and good design, I am truly ashamed to be a programmer. I'd be happy to change my assessment of GTK if someone would point in the documentation where it is possible for the user to change key bindings. I'll revisit GNOME when I return to the US next month, but the betas I was attempting to compile in January repeated many mistakes that I thought Linux had outgrown years ago. Qt too? I don't recall having this problem in Nethack with qt-1.3? and it wasn't broken in the same way Motif and GTK are the last time I looked at it, but I might be mistaken. I like Qt, but I wish it wasn't locked into C++ and that's a different issue.

1 participants
0 comments

Re: DANGER: Re: Backspace direction reversion 25 years, 8 months

Michael Sperber

[ I've edited xemacs-reviews out of the header. ] >>>>> "Olivier" == Olivier Galibert <galibert(a)pobox.com> writes: Olivier> On Fri, Mar 12, 1999 at 10:41:01AM +0100, Michael Sperber [Mr. Preprocessor] wrote: >> All the rest of Unix has Delete-moves-backwards. Olivier> Negative on that, Houston. Olivier> OG. Olivier> PS: Motif, gtk, Qt. Well, I'll concede on Motif, which drives me nuts every time I have to type into one of its application's text fields generally. Neither gtk nor Qt are parts of Unix. None of these libraries has achieved the kind of dominance that would warrant making the change, IMHO. Also, we're not really a Motif app. If we would follow more of Motif's UI standards, than I'd say go with it (WHEN linking against Motif). But XEmacs has _Emacs_ keybindings otherwise very different from how anything else in the world works nowadays. If we're not ready to change all the rest of the keybindings, then I don't see why we should change that particular bit of behavior. I expect users coming from PCs raised on any of its editors or word processors would have far more serious problems than this single keybinding. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: DANGER: Re: Backspace direction reversion 25 years, 8 months

Michael Sperber

>>>>> "Chipsy" == Michael Sperber <sperber(a)Informatik.Uni-Tuebingen.De> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> This patch REALLY REALLY REALLY REALLY REALLY REALLY SUCKS. Martin> Please help save the world. Martin> Speak out against this patch which takes us back to the dark ages. Chipsy> I agree with Martin. Kyle just pointed out to me that I fucked up royally, having misread Martin's patch. I DISagree with Martin. Restating what I said before: it may be true that many users are coming from a Mac/PC background. However, they're moving to Unix, not just exclusively XEmacs. All the rest of Unix has Delete-moves-backwards. I think the issue probably looks different on NT. Sorry for the confusion. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 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 March 1999