March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Backspace direction reversion 25 years, 3 months

Jan Vroonhof

Dan Glastonbury <Dan.Glastonbury(a)adelaide.maptek.com.au> writes: > How do I fix this? I've been using using Xemacs for about 6 years[1] and > haven't figured out a work around for this one. I know the problem is > caused by my BS key generating ^H when in an xterm, but what control > sequence do I get BS to generate?! Well. With XEmacs 21.0 and above, if you set your tty-erase char correctly you will at least not call help, i.e. stty erase ^h before staring XEmacs. Try this first, just to check whether it works for you. The better long term solution is to leave stty-erase at ^? (which is probably what it is now) and fix your Xterm. XTerm*vt100.translations: #override <Key>BackSpace: string(0x7f) \n\ <Key>Delete: string(0x1b) string([3~) i.e. Backspace returns ^? (ascii DEL) now!. However XEmacs 21.0 will then turn it into 'BS' correctly!. The second line makes Delete return some escape code so you can actually distinguish between them. You can however leave that part of. Jan P.S. I am pretty sure this came from some FAQ. At least I copy/pasted this in from somewhere.

1 participants
0 comments

Paren expression staying permanently highlighted? 25 years, 3 months

Reid Rivenburgh

Hi, I just recently joined the beta mailing list, so sorry if this has come up before. (I did look on dejanews, but I came up empty.) I've been using version 21.0 betas for quite some time now (currently b65), and occasionally a paren expression will highlight and stay highlighted, even when the cursor is moved away. This ends up leaving chunks of garish green in my buffer. (That green is a fine color for temporary matches, but not all the time....) It doesn't always happen, and I haven't figured out what causes it. I'm seeing it at the moment running on: OSF1 turbo-01 V4.0 878 alpha and I'm pretty sure I've also seen it on Solaris. I'm not doing anything peculiar in my .emacs relating to paren matching. I don't think this happened before the 21.0 series. Anyone else seen this or am I crazy? Thanks, Reid

1 participants
0 comments

Re: [Various] Backspace direction reversion 25 years, 3 months

Hrvoje Niksic

Glynn Clements <glynn(a)sensei.co.uk> writes: > If it is supposed to delete backwards, then `the big key labeled > "Delete"' should be generating the `Backspace' keysym, not the > `Delete' keysym. > > It isn't our responsibility to work around X server > misconfigurations, IMO. But we *are* doing it. If there is no "BackSpace" keysym, then we take "Delete" to delete backwards, regardless of `delete-key-deletes-forward'.

1 participants
0 comments

Re: Backspace direction reversion 25 years, 3 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > `Normal'? `Normal'??? It's _not_ a normal keyboard for any canonical > meaning of normal. The parens are shifted left to be above `8' and > `9', `"' and `＠' are on the wrong keys, the square and curly braces > are on the wrong keys. Heh heh; so far, this looks like you're working on a keyboard with Croatian[1] mappings. My condolences. [1] In fact, the ideas were imported from German keyboards. I don't know why the Japanese do the same.

1 participants
0 comments

Re: Backspace direction reversion 25 years, 3 months

Martin Buchholz

>>>>> "SL" == SL Baur <steve(a)xemacs.org> writes: SL> My argument against is simple. The failure mode is catastrophic SL> in exactly the same way that we wanted to fix when we first got SL> into this. There are keyboards in the mule lab that XEmacs is SL> completely clueless to deal with[1]. With them, the big key SL> labeled "Delete" stops deleting backwards and in order to get a SL> delete backwards requires a shifted keystroke. What bugs me most about this argument is that Steve describes as `catastrophic' a situation where a user would have to use a modifier key (e.g. `Fn') to delete backwards, yet... a user who currently might want to delete forwards currently must ALWAYS use a modifier key, i.e. Ctrl+D. How exactly is this different? The number of keyboards where xemacs guesses wrong is very small. Steve's argument that xemacs should NEVER guess wrong is bogus, since there is no way we can ever control the labels actually physically inscribed on the keyboard keys by the manufacturer, or vendor mods to Xlib or the xmodmap setup. It is unfortunate that some versions of Linux start up with the keys labelled BackSpace and Delete both xmodmapped to the Delete keysym, although xemacs deals reasonably well with this situation by making the Delete keysym delete backwards in this case. Steve has suggested in personal communication[1] measuring the usage of Delete vs Backspace by users on xemacs-beta. I reject this suggestion, since: - the backspace/delete change is aimed at the novice users, not xemacs-beta denizens. - those folks willing to send in a usage report of their own keystrokes would hardly be a representative sample. Some (most?) would have an axe to grind[2]. - Even if the BackSpace key is used orders of magnitude more than the Delete key (I'll admit it *is* used more commonly - I don't know how much), it is still important that it does what the novice user would expect if he does use it. I use the `=' key much more rarely than the BackSpace key, yet I would be quite upset to lose it. An additional user interface argument for the Delete key deleting forwards is the fact that although (point) is really between characters, the visible indication of (point) is a modification of the *following* character[3]. So a novice user who wants to delete a single character would `select' it by making the cursor cover it, then pressing Delete. It is far less intuitive to delete a character by `select'ing the *following* character and then backspacing, although it is equally easy in some sense. Users expect to process data in the same order that they input it, so forward-deletion while holding down the Delete key is a very natural operation. Footnotes: [1] I don't think he'll mind me mentioning this in this forum. My apologies if I'm wrong about that. [2] Yes, I've got a bigger one than the rest of you. [3] On a non-tty device, we should probably fix this so that (point) is more visibly betweeen characters. The thin bar-cursor was a flawed attempt to implement this earlier.

5 participants
9 comments

Re: Backspace direction reversion 25 years, 3 months

Gary D. Foster

>>>>> "KJ" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: KJ> I was just showing why it was more importasnt to get the KJ> backspace key binding right. You seemed to be equating the I think Kyle is right on-target here. Although I'm on record as rabidly pro "delete key deletes forward", I'm also just as rabid about the backspace key ALWAYS doing the right thing... perhaps even more so than the delete key. I can guarantee you that one of THE most frustrating things for a new user is not "you want me to use ctrl-d to delete forwards?" but "what idiot decided that backspace should bring up help". The delete key behavior is probably the _second_ most frustrating thing. :) No matter _what_ we do, we have _got_ to make sure we get the backspace key handling correct, for as many definitions of "correct" as is humanly possible. However, I feel that we can do BOTH. We _can_ fix both the backspace AND the delete issues. They are not mutually exclusive. KJ> The question that remains in my mind is, "Can we set KJ> delete-key-deletes-forward to t without hosing a large number KJ> of existing users?" I want to get to the point where we can KJ> set this variable to t, but I don't want to do it if we're not KJ> ready. As I've wrote the last time this topic was discussed I KJ> think this is a worthwhile concession to those coming to us by KJ> way of Windows, to help ease their transition to open source KJ> software. Yes, yes, yes yes yes. Did I mention that I agree 100% with this? -- Gary F. -- "In the end, the overall 'productivity' of the system the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of 'hard.'" -- Ellen Ullman, "The Dumbing Down of Programming"

2 participants
1 comments

(old?) question: why is help-selects-help-window non-nil by default? 25 years, 3 months

John H Palmieri

XEmacs 21.2 "Demeter" [Lucid] (sparc-sun-solaris2.5) of Mon Mar 15 1999 on ahoward Hi, I have a few questions about the variable help-selects-help-window: why is it non-nil by default? When did XEmacs start behaving this way? I am curious about the reasons for this difference. (I also couldn't find anything about the change in etc/NEWS or etc/OONEWS. Did I just miss it, or is it even older than that?) (It recently occurred to me that this behavior ought to be customizable, which of course it is, so at least now I don't have to be confused by *this* difference between GNU Emacs and XEmacs as I switch from one to the other.) -- John H. Palmieri e-mail: palmieri.2(a)nd.edu 205 Computing/Math Bldg. URL:http://www.nd.edu/~jpalmier/ University of Notre Dame (219) 631-8846 Notre Dame, IN 46556

1 participants
0 comments

Re: [Various] Backspace direction reversion 25 years, 3 months

Gary D. Foster

>>>>> "MB" == Martin Buchholz <martin(a)xemacs.org> writes: MB> Martin: The BackSpace key should delete backwards and the MB> Delete key should delete forwards. and the backspace key should never, ever ever bring up a "help" dialog (unless, of course, the user specifically maps _for_ such an occurrence). Consider me voting for sanity... sanity being defined as the above quoted layout. -- Gary F. -- "It is by caffeine alone I set my mind in motion, it is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning ..." --Carlos Nunes-Ueno

1 participants
0 comments

Re: Backspace direction reversion 25 years, 3 months

Gary D. Foster

>>>>> "MB" == Martin Buchholz <martin(a)xemacs.org> writes: MB> Alright, here's a plan: MB> - We leave the default on for 21.2. I fix any bugs related to MB> the change, including perhaps patches for external packages. MB> - I add docs where appropriate. MB> - I take on maintaintership of all the BS/DEL code and docs, MB> given that Gary Foster has less time now with his change in MB> marital status. Ok, I admit, I haven't been around as much as I wanted to be lately. I have to get my fiancee slowly acclimated to my true level of geekiness (which often includes getting up at 2 am to hack away at something just because...) but I _promise_ that I'll help you out on this maintenance, Martin. Just keep me apprised, and I'll slide back under the yoke. -- Gary F. -- Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind. --The INTERCAL Programming Language Reference Manual

1 participants
0 comments

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

Gary D. Foster

I think everyone knows _my_ opinion on the delete direction madness. The simple fact of the matter is that no, no matter how much you stick your head in the sand and pretend for it to go away, delete DOES NOT MEAN delete backwards to most of the rest of the world. The rest of the world has moved on beyond that simple madness and quite logically does not expect to have TWO keys on ONE keyboard that both delete backwards. I have a longer paper on this that I'd like to finish up (I was planning on trying to make it to Japan to present it but other obligations prevent me from coming) but I'll try to summarize here... The crux of what I'd like to discuss is this... we have to be responsive to the needs of our community. That includes noticing when those needs have changed and does not necessarily mean we need to be "keepers of the flame" and maintain the "old ways" just because that's the way it's always been done. Today's unix users are a hell of a lot different than the unix users of 5, 10, or 20 years ago. Like it or not, the unix users of today are coming from a PC-centric background. People _expect_ that certain behaviors will be there and when they find them they get baffled beyond belief and walk away. When enough of those people walk away, we'll be maintaining XEmacs for a smaller and smaller group of people, all of which are just sitting around in their chairs muttering about the "good old days". Steve... you are a smart man. I find it baffling that you are continuously pissed off about this change when a simple "setq" in your .emacs will remove it forever from your view. Instead, to avoid doing that and to continue to push an agenda you want to force thousands of other users into a baffling maze (to them) before they can figure out how to make something work logically. We can continue to enforce whatever behavior we want... whatever behavior we view "proper"... but just because you _can_ do something does not mean you _should_ do something. XEmacs is remarkable for being flexible, agile, and a living, evolving editing environment. And, whether you want to admit it or not, current thinking about keyboard mappings _has_ moved on and we are no longer keeping up with it. We're dinosaurs, desperately holding on to something just because "we've always done it that way". That doesn't sound like the attitude that has brought us all the other cutting edge features in XEmacs at all. Now, free software authors like to state that they are writing their software for their own satisfaction... that they don't get paid to write it therefore they should be able to write what they please. To a large extent, this is a quite valid assumption. However, any free software author who writes something never really wants to see their software languish unused. We _all_ get paid for what we write... as free software authors, though, our payment comes in the form of recognition. Our currency is, quite simply, how many people use our software. Don't kid yourselves, we _do_ get paid for writing this, albeit in a slightly different fashion. As responsible free software authors, we owe our users and our community due consideration... namely to be responsive to their needs and desires. How can we expect people to continue to use our software when we use it to further our own agendas at their expense? Yes, we have the prerogative. We have the ability. If we write something useful enough, we can unilaterally "correct" any behavior that we deem "undesirable". After all, isn't that what Microsoft does? I say that we stop infighting about this issue. It's dumb, it's divisive, and it's argued about as a religious issue instead of a simple matter of good user interface design. Instead, let's put a poll together. Hell, post it to Usenet or put together a web form or do something. Let's go to our _users_ and perform the unspeakable... let's _ask_ them which they'd prefer. And then let's _all_ agree to be bound by that instead of beating each other over the head. -- Gary F. -- "There is no shame in a UNIX Sysadmin not coping with a Mac. Auto mechanics don't have to fix rubber squeak toys." -- Carl Rigney

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 March 1999