The Modernization of Emacs: terminology buffer and keybinding
dak at gnu.org
Sun Jun 24 08:52:27 CEST 2007
Twisted <twisted0n3 at gmail.com> writes:
> On Jun 23, 2:04 am, Robert Uhl <eadmun... at NOSPAMgmail.com> wrote:
>> > Besides, ANY interface that involves fumbling around in the dark
>> > trying to find a light switch is clunky.
>> That sounds like vi, not emacs.
> That sounds like any application where you need to read the help, but
> "f1" does not bring up a separate help window, switchable with the
> main one using alt-tab or the mouse, and navigable using arrows,
> pageup, pagedn, and the mouse.
Well, f1 brings up a prompt: f1 (type ? for further options)-
Typing ? brings up a separate window (and instructions how to scroll
it) with a variety of help options, among them the tutorial. If you
want a separate window, File/New Frame will give you that. Of course,
switchable with the main one using alt-tab or the mouse, and navigable
using arrows, pageup, pagedn and the mouse.
> The result of that is invariably that when the document has the
> focus, the help is open to "help on switching windows" rather than
> whatever you need it to be on once the document has the focus. You
> can read the help on doing what you want to do with the document,
> but to apply it you need to transfer focus back to the document. If
> doing that isn't second-nature, you have to navigate the help away
> from where you need it to get the focus back to the document.
> Now the focus is on the document, but the help you need isn't
> displayed next to it anymore. Frustrating? You can't begin to
> imagine, I suspect. Apparently, some people are born somehow able to
> avoid this problem without having to memorize one or the other piece
> of help. You're clearly one of those. I am equally clearly NOT one
> of those. Of course, if emacs let you keep THREE windows open and
> visible at the same time, instead of being limited to one or a
> horizontally split two ...
Which it does...
> and a cramped 80x10 or so each, at that ...
Emacs frames can certainly be resized and repositioned at will using
You are really babbling a lot of nonsense that is, at best, somewhat
relevant for prehistoric versions of Emacs without GUI support.
Just shut up until you have installed and worked with a modern version
> If I haven't, it must be the case that finding this tutorial (or
> even discovering that it exists) was nontrivial, or it wasn't built
> into emacs, one or the other. My memory is somewhat fuzzy after all
> these years so you'll forgive me if I don't make a definite
> statement about which.
"After all these years"... You really should not rely on 10-year old
memories about an application.
> On the flip side, if I have, the tutorial can't have been all it's
> cracked up to be. Especially given I can program Java proficiently,
Apparently, at the time you last looked at Emacs, Java did not yet
> including some fairly sophisticated network-using tools, and clearly
> am not an idiot or untalented in technically demanding areas
> involving substantial amounts of arcana.
Up to now you have not delivered any discourse that would warrant the
"clearly" in this sentence. Not that using Emacs involved
"substantial amounts of arcana".
> The technical term for managing limited resources, such as time and
> effort, first where needed and never where avoidable, is
> "efficiency", in case you were unaware.
Sure, but babbling about a system you have never seen in its present
state for 10 years, and consequently putting your foot in your mouth
in hundreds of postings requiring hours of times spread over several
months, when it would take all of 10 minutes to get your information
somewhat up to scratch, is called "stupidity", in case you were
>> or you're just making things up.
> Also untrue, and you've just accused me of incompetence once and of
> lying twice, which in a formerly civil discussion constitutes
> behavior that I consider to be in poor taste.
Well, so what is it about you accusing people of lying that report
experiences about a system you have never looked at in its current
state? You even accused me of lying when I posted _screenshots_ from
a publicly accessible site, suspecting me of forgery.
>> If I'm browsing the manual online, I can switch from said manual to
>> my document buffer without making the manual scroll to the
>> documentation for switch-to-buffer.
> Apparently because you find the switch second nature, despite its
> not being the obvious (which is ctrl-tab, to switch between
> documents in an MDI app).
And which works fine when using Emacs frames. Look, you are making a
complete spectable of yourself. Get a current version of Emacs and
actually try it.
> Cheat sheet? Memorized with painstaking months of hard effort?
> Thanks for proving my point, either way.
You are babbling. Not that this is new.
>> In fact, I am not aware of any package which auto-changes the
>> *info* or *Help* buffers to reflect the last keyboard command.
> I didn't say it auto-changes. It manual-changes. The exact sequence of
> events that causes this with a novice user being:
> * Need to do X, and the usual command doesn't work (e.g. go to save
> document and get search prompt)
Try the File/Save menu.
> * Now nothing much works (typing stuff bleeps),
Typing letters will search (the I-search: prompt in the message area
is pretty obvious). Typing other stuff (like cursor keys) will abort
the search and do their normal work. Clicking with the mouse into the
main window will abort the search and reposition the cursor. Quite
> hit esc a bunch of times *
The splash screen already explains that C-g is used for aborting
> Now it complains of hitting esc too many times,
No, it says "Quit" since it has quit the search.
> but typing into the document at least works again * OK, time to
> resort to *gulp* the help. * Oh, great, now what did it do? I hit
> F1 and ... * Eh. Try random stuff.
No, F1 works fine for entering the help.
> Help starts with h. Alt-h? Ctrl-h? ... * Oh, right. I seem to
> remember the help popping up unwanted when I tried to backspace over
> a typo earlier, so I'll just do that. * Hrm, now how to search the
> bloody thing? * <Hours pass, some spent trying ctrl+f and ctrl+s,
> mostly fruitlessly, followed by a load of
Well, what kind of help did you select? The tutorial explains about
Searching some point down in the document, certainly not requiring
hours of paging. But you could, of course, also click on the
Edit/Search menu. Or on the "Search" button in the toolbar: after
all, Emacs is a modern GUI application.
> * Ah. "How to do Foobar to your open document". Perfect!
> * Oh crap. How do I do anything to my open document, when the focus
> is on the help instead of the document?
> * <Scrolling for ten
> minutes> * Ah, I hit this. It worked! * Oh, fudge. Where did "How
> to do Foobar to your open document" go? The help's open to "How to
> switch windows". For shame. * Switch back, scroll ... there it is.
> * Crap, now I don't remember how to put the focus back on the
> document window. * More scrolling. * Oh, fudge. Where did "How to
> do Foobar to your open document" go? The help's open to "How to
> switch windows". For shame. * <however many repetitions of the
> preceding 4 lines> * Error: Stack overflow. Dumping core.
> I trust you get the picture.
Yes. You don't have a clue what you are talking about. Your
experience is, self-admitted, at least 10 years old and completely
irrelevant to the modern state of Emacs. And, of course, the "Stack
overflow. Dumping core." nonsense bears no relation to _any_ behavior
_any_ version of Emacs, prehistoric or not, ever showed.
> Whoa, what did you just say? Page 899 of the ... good Christ. Er ...
> Run! Flee! It's a monster! Head for the hills! Sound the civil
> defense sirens, tornado TORNADO! *runs*
You are getting delirious.
>> > Infrequently used commands you can stand to hunt for in
>> > menus. When you find you use one frequently, you can try to learn
>> > the keyboard shortcut -- and you can find it without even
>> > consulting the help, simply by finding the command's menu item.
>> This is no different from emacs. There's a menu bar
> What are you blithering about? Oh, great, now I'm using the term
> "blithering". :P But ...
> WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
> in a cramped little 80x24 grid of letters, numbers, spaces, and
> punctuation with no menus, no concept of a pointing device, and a
> bad attitude.
We are discussing Emacs. An editor tightly integrated into the GUI
of, at choice, Windows, MacOSX, X11 Athena, X11 Gtk+, its own Lucid
widget set, with mouse navigation, toolbar, multiple resizable frames,
menubars, support of graphics, proportional and different-sized fonts
in the frame. The one displayed in the screenshots
<URL:http://www.gnu.org/software/auctex/screenshots.html> on the
AUCTeX web site.
You, on the other hand, are not "discussing Emacs" but talking
nonsense based on fuzzy memories of passing decade-old experiences
with an early predecessor.
> Actually, the big thing the GUI and mouse did was rescue us from
> escalating UI problems with tasks complex enough to require
> modes. You needed either separate components with separate
> associated functionality and a "focus" to move among them, or you
> needed commands and keyboard-toggled modes. The former got you an
> emacs and the "can't switch back from the help" syndrome,
> and the latter got you ... something vile.
Get an update. Emacs started supporting window systems with Emacs 19
(a very long time ago), at first just under X11. But current versions
of Emacs support all modern GUIs with all features they offer.
> Until the GUI-with-pointing device, which made user control of a
> "focus" a snap requiring virtually zero learning curve, and better
> yet, what little learning there was being transferred readily across
> applications. Unified windowing systems, with Macs and Windows,
> cemented the victory of the pointing device over the problem of
> focus management. Point at the thing you want to use next and click;
> that simple. A child can do it. Using a GUI is like doing a job
> yourself, such as washing the car. Using something from the dinosaur
> age, especially afterwards, feels like sitting back and directing
> some hired help. Help that happens to be blind as a bat as well as
> having the usual poor grasp of English. "Left, Senor. Right,
> Senor. No not THAT far right! Now you've gotten it all into the open
> drivers-side window, and those documents I left on the front seat
> are ruined!" Ouch. Yet trying to control old text-mode tools is
> pretty much exactly the same, only the flawless English it speaks
> belies an even dodgier grasp of same, or even the need to speak to
> it in some obscure dialect of Greek full of "meta" instead...and it
> doesn't apologize when there's a screwup a more hands-on interface
> would easily have prevented.
Again, you are babbling based on decade-old passing exposure to an
early predecessor of modern Emacs.
It is not like you have not been told a hundred times, over a duration
of several months. You could have downloaded, tried and _learnt_ a
modern version of Emacs in half the time you used for spewing about
it. You choose ignorance, and showing off what an idiot incapable of
rational behavior you are.
> If you want a job right, do it yourself. With a mouse, you can; no
> need to speak an obscure variant of Swahili into a keyboard just to
> get the focus to the document from the help or wherever. And to top
> it off, every Windows app understands tab and alt-tab and most
> understand ctrl-tab.
As does Emacs. Or rather, it does not need to. Instead it reacts,
like other applications, to the frame and focus switching commands
from the window system which in itself interprets alt-tab.
> Actually, the OS GUI components themselves understand alt- tab, and
> the applications just get told the focus went elsewhere or came
> back, making it one less area for application designers to screw
> things up. (All too often, they screw up ctrl-tab in tabbed/MDI
> apps, or screw up tab by using a dodgy tab order or controls with no
> visual indication of focus, mind. And then you can just resort to
> the mouse, rather than throw up your hands or find something
> non-electronic to sob into so as to avoid ruining another $40
And your point was?
> And let's not forget that to someone with a 17" LCD monitor and a
> blisteringly fast graphics card, 80x24 text in a terminal emulator is
> somewhat underwhelming, and doesn't provide anything like the
> information density needed to make truly complex software interfaces
You are talking about Emacs 18, or (in a DOS box, likely) at best
[Rest of the nonsense assuming that Emacs is a terminal application
> Those dim old greenly-glowing 80x24 terminals flickering at 20-odd Hz,
> by contrast ... barely adequate to design their own replacements on,
> though necessary for same.
Again, you parade your incompetency even about the decade-old
experiences you choose to talk about. No terminal ever flickered at
less than 50Hz. The normal frequency for US built terminals was 60Hz.
> "Programmers" maybe. Even so, some people program from time to time
> but do a lot of, say, image manipulation.
> I expect even most programmers like to be able to see what the heck
> they're doing, rather than resorting to fumbling around with a
> flashlight or grunting terse instructions to a blind butler with an
> IQ in the mid-zeros.
The latter sounds like a description of you. Current versions of
Emacs 22 even offer browsing through directories with images (use the
image-dired function) and applying basic operations like rotating
them. Good for managing a photograph collection.
>> That's how I learnt emacs. I was 13, and had only ever used Mac
>> software up until that point. I had a fairly limited command set
>> (basically, C-x C-f, C-x C-s & C-x C-c).
> That looks like three commands, although I can't be sure -- my
> Swahili is a little rusty from years of disuse. ;)
> I'd normally use at least eight -- open, save, quit, find/find next,
> replace, cut, copy, and paste.
All of those are on the toolbar (not to mention in the menus).
> That's not counting arrows, page up, page down, del, backspace, and
> the like, and unixy tools don't let you take even THOSE for
All of those work with Emacs.
> And if I needed more, add help. Add the four arrows, page up, page
> down, delete-forwards, backspace, and help to the original eight and
> we now have 17 commands. I seriously doubt that your short chunk of
> Swahili up above encompasses all of them.
All of that is available by clicking on icons, using scrollbars and
dedicated arrow/pageup/dn keys.
>> Do you realise that emacs has a GUI these days? I'm writing this
>> in a 70-line window, with gtk+ widgets. Which means
>> full-resolution, full-colour.
> What are you talking about? Clearly not emacs, which is a console
> app for unix systems (with the inevitable MS-DOS ports and
> others). Some sort of bastardized Windows port I suppose?
You are so clueless. Take a look at the web page for AUCTeX
<URL:http://www.gnu.org/software/auctex/screenshots.html>. That are
screenshots from a somewhat current version of Emacs.
> I've seen the occasional attempt at a Windows port of a unix tool,
> and the results are fairly uniformly awful. Everything looks mostly
> right, and nothing works quite right. They're often actually more
> unstable than native Windows apps, probably because the porters
> don't know half as many of the landmines littering the windoze APIs
> as real Windows application programmers do (and *they* only know
> maybe half of the total, to judge by the stability of even
> higher-quality Windows apps) and because they are bolting on a thin
> layer of Windows widgets onto a core that works in ways
> fundamentally alien to those same APIs. No real Windows app dares to
> try spawning around 700 threads to service a request to copy two
> lines of text to the clipboard, for example. :)
The Windows port of Emacs is full-quality and full-functionality and
tightly integrated with Windows' GUI. You can get it with an
installer from the EmacsW32 web page
<URL:http://ourcomments.org/Emacs/EmacsW32.html>, for example, or from
the main Emacs distribution site from the FSF.
You are babbling uninformed outdated nonsense, and have been pointed
to the relevant info dozens of times over months. Yet you choose to
stay ignorant and continue looking like an uneducatable idiot.
Uneducatable idiots should not choose to work in the computing
business since things move fast there, and uneducatability (and the
unwillingness to reevaluate decade-old experience) are plainly a
David Kastrup, Kriemhildstr. 15, 44793 Bochum
More information about the Python-list