the Modernization of Emacs
in [Lisp]
|
From: John Thingstad on 13 Apr 2006 06:45 On Thu, 13 Apr 2006 12:23:16 +0200, David Kastrup <dak(a)gnu.org> wrote: > "John Thingstad" <john.thingstad(a)chello.no> writes: > >> The microsoft key inteface is part of the Common User Access >> Document (CUA). It was developed by IBM, not Microsoft. And they >> did spend the best part of two years carefully thinking it out. That >> noone ever did this for X-Windows, now that is obvious. > > Come off it. The X Window system is a network transparent hardware > interface, not a GUI. So it can hardly be blamed to not have any > default keybindings. That's not its job. > I said the X-windows system, not the X protocol. And yes, it was experimental and buildt to discover what a GUI should behave like so it laid most decitions open. Be that as it may. You now have Gnome, KDE, Motif.. so you never know what you are going to get.. A cludge.. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: David Kastrup on 13 Apr 2006 06:55 "John Thingstad" <john.thingstad(a)chello.no> writes: > On Thu, 13 Apr 2006 12:23:16 +0200, David Kastrup <dak(a)gnu.org> wrote: > >> "John Thingstad" <john.thingstad(a)chello.no> writes: >> >>> The microsoft key inteface is part of the Common User Access >>> Document (CUA). It was developed by IBM, not Microsoft. And they >>> did spend the best part of two years carefully thinking it out. That >>> noone ever did this for X-Windows, now that is obvious. >> >> Come off it. The X Window system is a network transparent hardware >> interface, not a GUI. So it can hardly be blamed to not have any >> default keybindings. That's not its job. > > I said the X-windows system, not the X protocol. I can read. And I can write, and you should be able to read what I have written. I did not talk about the "X protocol". > And yes, it was experimental and buildt to discover > what a GUI should behave like so it laid most decitions open. The X Window system is a network transparent hardware interface, not a GUI. It does not interpret keystrokes, but makes them available. It is not a "GUI with most decisions open", no more than flour is a "cake with most decisions open". It is a network transparent hardware interface. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: David Kastrup on 13 Apr 2006 06:56 Alan Mackenzie <acm(a)muc.de> writes: > David Kastrup <dak(a)gnu.org> wrote on Wed, 12 Apr 2006 11:01:01 +0200: >> "Tim Bradshaw" <tfb+google(a)tfeb.org> writes: > >>> David Kastrup wrote: > >>>> XEmacs is not Emacs. > >>> Um, yes, it is. > >> It is a fork, so you can't blame the Emacs developers for the >> deficiencies in XEmacs. Enabling font-lock by default in a version >> that is clearly not fit for general use is not something that happened >> in Emacs. When Emacs development made the decision to enable it by >> default in future versions, _months_ of work were invested until the >> state was deemed tolerable. And XEmacs has an even earlier version of >> font-lock. > >> So for the purpose of complaining about unusable defaults, you simply >> can't blame the Emacs developers, and it is extremely unfair to >> chastize Emacs over several postings and then mention in passing that >> you are actually talking about XEmacs, a completely different project. > > "Emacs" does not always, or even usually, mean specifically "GNU > Emacs" and this newsgroup, comp.emacs, is intended for discussion of > _all_ Emacs editors. What about "for the purpose of complaining about unusable defaults" did you not understand? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Floyd L. Davidson on 13 Apr 2006 07:00 "John Thingstad" <john.thingstad(a)chello.no> wrote: >On Thu, 13 Apr 2006 11:55:08 +0200, Floyd L. Davidson ><floyd(a)apaflo.com> wrote: > >> On the other hand I would *grossly* disagree with most of the >> various suggestions for changing default key bindings! That >> would interfere, and should be avoided. The fact that Microsoft >> did not spend enough time designing a keyboard interface does >> *not* mean that any version of emacs should revert to what >> Microsoft uses, even if it is a more commonly used interface. >> > >The microsoft key inteface is part of the Common User Access >Document (CUA). >It was developed by IBM, not Microsoft. And they did spend the best part of >two years carefully thinking it out. Apparently not carefully enough. It was designed to implement a monopolistic business plan... and the overall design strategy worked (for Bill Gates instead of IBM, but...). >That noone ever did this >for X-Windows, >now that is obvious. Why would anyone do that for X? It does not use key bindings... >With upteent window managers and people typically using software >written for >several you never know what you are going to get. >Every program on it's own in a sense defeats the point of a integrated >inteface. That doesn't make for very good logic. You are saying that once a majority of people have adopted any given design, everyone else should join in, regardless of whether it is a good design. If the popularity was based on good design, I might agree... but it virtually *never* is (and instead is almost always based on who has the best marketing!). >> The emacs interface should *never* be guided by a popularity >> contest amongst people who are unaware of the differences. It >> should remain directed at providing the best possible interface, >> even if it is not easy to learn as a "second language". >> > >People will have a easier time learning to use it if things work >as the expect. The keyboard interface design should have a priority for easy *usage*, not easy *learning*. Your suggestion is backwards and leads to the kind of poor design others are advocating. >Arrow keys, home, end etc.. It is visually intuetive to see what these keys >do. If they have to look up basic commands like moving a cursor that >alone would turn many away from the program. So you are saying that the example discussed earlier in this thread was correct, where supposedly the <Home> key is a better choice than C-a for beginning-of-line and <End> is a better choice than C-e for end-of-line???? That is an very good example of the backwards "intuitive" design advocated above. The fact is that those key bindings become *reflexive* after sufficient use. The highest priority is *not* whether it is obvious to a beginner what they do, but how easily they can be fingered by an expert. Given that there is very little variation in keyboard location and fingering for C-a and C-e, but there is a huge variation in where the <Home> and <End> keys are located, it is absurd to use the <Home> and <End> keys for commonly keyed commands. And I would argue that those are very non-intuitive bindings anyway, as it seems obvious that <Home> and <End> either apply to the beginning and end of the screen display or the buffer being displayed. >> This is not to say that emacs cannot and will not be improved, >> but those who complain need to realize that looking at what >> Microsoft has done is *not* the direction towards improvement. >> It was *intended* to be different for the mere purpose of being >> different, not better. > >Being different for it's own sake was never the point of Emacs. But that *is* what Microsoft has set out to do in many instances, which was my point (though I may not have worded that clearly enough). >It simply existed long before Windows or even X-Windows. >That Mac and Window's users have come to expect certain operations >to work is reasonable and indeed Emacs has come a long way in accomodating >them. I think they deserve praise for that. And as long as Emacs does *not* give in to the type of complaints that have been registered in this thread, they will continue to deserve praise. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: Floyd L. Davidson on 13 Apr 2006 07:17
"John Thingstad" <john.thingstad(a)chello.no> wrote: >I said the X-windows system, not the X protocol. >And yes, it was experimental and buildt to discover >what a GUI should behave like so it laid most decitions open. >Be that as it may. You now have Gnome, KDE, Motif.. >so you never know what you are going to get.. >A cludge.. A cludge??? How about a process that eventually ends up providing the *right* solution, rather than the most successfully marketed solution? For example, I do not use Gnome, KDE, or Motif. I run X based systems, using a very well honed FVWM configuration. Your "cludge" is opportunity knocking... -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com |