Re: Great SWT Program
Nobody's trying to convince you that you, personally, need to switch
to using vi or emacs. However, you continue to post things about both
editors that are at best out of date and at worst simply wrong. I'm
sure the editor (or editors) you use, whatever it is, is great and
does exactly what you've come to expect it to do, and you no longer
have to think about how it works to get what you want from it.
Could you please extend the same respect for difference I've just
shown you to others and stop telling them their preferred tools are
somehow worse than yours? It's a matter of opinion and widely-
variable personal experience, not fact, and your assertions are
irritating people who are, in fact, quite capable of trying out other
editors for comparisons' sake themselves and making rational choices
about what's superior for them.
On Oct 31, 11:59 pm, Owen Jacobson <angrybald...@gmail.com> wrote:
The result of typing 'emacs' with no arguments at a shell.
Meaningless. Anything, such as a graphical port or even a completely
unrelated app, could have been given the file name "emacs" and put on
the search path.
You appear to be assuming that there's a single piece of software
called "emacs" somewhere, of which all other emacs-like programs are
variants. That hasn't been true for a long time: the two most common
variants, XEmacs (formerly Lucid Emacs) and GNU Emacs have been
separate codebases for long enough to have diverged completely, and
neither is in any way derived from the original emacs package (a set
of TECO macros), being, as they are, implemented in C. There's also
James Gosling's now-long-dead rewrite, GOSMACS, and a few others.
There's a reason I was pretty specific about what program I was
running: there is no single program you can point at and say "that's
emacs". The variant in the screenshots is GNU Emacs version 22, with
an X11 frontend (which is part of the GNU Emacs source proper, and not
a "port" in any meaningful sense), except for the one terminal UI
screenshot. I also included as a footnote some screens from the GTK
frontend, which is visually a little nicer and provides some features
not available via Xlib, like the GTK file chooser.
The same is true of vi, incidentally, but I'm not as familiar with the
"family tree". As far as I know the most popular vi implementation
right now is gvim, which is not derived from the original vi source,
either, but from a reimplementation.
Emacs and vi are, themselves, nothing more than sets of conventions
around which other features can be and have been added.
normal command inputs just don't do the expected
Text copied into emacs from a non-emacs window using one of two
standard, conventional X copy/paste mechanisms respected by all X
applications (drag over text in one window, middle-click in another
I rest my case. I take it ctrl+C, ctrl+V would cause one or both to
On a platform where that was a normal copy-paste sequence? No, not
really. The CUA link explains how to get those specific keys for copy
and paste, on any platform, or you can set up your own bindings if you
don't like the default ones. Otherwise, you can look in the same
place you learned notepad's editing keystrokes: in the Edit menu.
You do realize that the select/middle-click thing is a long-standing
convention on X11 platforms, and ignoring it would be as rude as
ignoring Windows' conventions is on Windows, right?
Text selected in one window and pasted into a non-emacs window using
another standard X copy and paste mechanism respected by all X
applications (drag over source text, edit menu, copy, switch apps,
edit menu, paste).
That, at least, is normal, if perhaps unwieldy if done frequently.
Apparently the makers of graphical ports of console apps can
*occasionally* get something right.
If you want to do it faster, emacs helpfully lists the hotkeys for
copying and pasting text right in the edit menu. Those hotkey lists
even change if you change the hotkeys.
The help on selecting text, displayed alongside a document in a
single emacs process.
With the focus on the help no doubt.
As it happens, yes, but that's only because I spent some time
rearranging windows before taking the screenshot, so I could get both
windows in the shot without making it too huge. The focus was
alternately on the help, the Scratch file, and the terminal at various
points and I forgot to put it back on the Scratch file.
All of that window juggling, incidentally, was done with the mouse.
The default font it selected did not contain glyphs for the arabic
language, but it correctly saved arabic text which could be viewed in
other editors as such.
Editing special characters blind -- it's the new challenging game
that's all the rage! Too bad if you're trying to actually get
something done rather than amuse and challenge yourself, though.
Heh. I should've edited that paragraph out, actually. It was part of
a longer section wherein I copy-pasted some katakana text from Sony's
site into the document (it displayed fine). Unfortunately, I seem to
have lost the X11 screenshot, so I edited out the paragraph describing
it and forgot to take this out.
The only reason the Arabic text came out as boxes was because the font
emacs was using didn't have any glyphs for those characters. That's
not a problem with emacs; if there are no glyphs available for a given
codepoint, it can't exactly make something up and drawing a box is a
fairly conventional fallback behaviour. As far as I can tell, only
the font Firefox selected for plain text has those glyphs: gedit
didn't know what to do with them either. od(1) says the bytes in the
actual file are correct for UTF-8, though.
Or jumping to a line number, as you
mentioned. Or the mouse wheel.
I don't trust those making graphical ports of unix terminal apps to
get things like scrollbars and the scroll wheel right.
Trust doesn't enter into it: either the program behaves as you want,
or it doesn't. In the case of emacs, even with the Xlib frontend you
get a variable-sized draggable thumb proportional to the document
length, clickable "scroll by a page" as well as clickable "scroll to
here" behaviour, and full support for the scroll wheel with a
reasonable, and configurable, scroll rate. That corresponds well with
what you've described as wanting from programs (and rather well with
what you get from the Windows scrollbar widgets).
Some emacs distributions come configured that way by default (such as
emacs.app for OS X, which comes with Mac HIG keybindings enabled out
of the box).
Of course. They wouldn't DARE release something hard-to-use to Mac
users. Steve Jobs would have them all shot! The "emacs.app" port (OS X
port, I assume?) probably also actually implements a GUI that's up to
It's a very small set of extra sources (primarily implementing hooks
to call Quartz functions) on top of the core GNU Emacs codebase, and
it's packaged with the GNU Emacs source code -- the same source code
used to build the version I took screenshots of. Whether that
constitutes a "port" or not is kind of immaterial: it took very little
effort to add OS X support to emacs, in terms of code and
configuration size, so obviously GNU Emacs is designed to support
widely-varying environments with little effort.
(Quartz is almost nothing like either the terminal or X11 or Win32. I
speak from experience here.)
There's even a section *in the manual* on how to enable CUA-style
bindings in GNU Emacs (the version I'm running in the screenshots):
Struggling with the attempts to access and search that manual being
the gatekeeper to this valuable information, no doubt?
Well, there's this handy tool called "google" that can search the
online HTML version of the manual, if you don't like the versions that
come with the editor. GNU Emacs' documentation is very accessible
outside of emacs itself, if you don't want to use the emacs 'info'
system. Or you can find the same information in the help, very likely
by searching for 'cua' (I don't have the box I took those screenshots
on in front of me, or I'd check that).
This option is disabled by default on most distributions because the
majority of emacs users prefer the keystrokes they're already
Yeah, all three of them. Meanwhile new users continue to run it,
fiddle with it a bit to see what all the fuss is about, decide that
all the fuss is about how terrible and hard to use it is, and
I was never taught to use emacs: I chose it of my own accord based on
nothing more than having heard the name once or twice, when I was
learning Linux, after getting irritated with how simpleminded pico
was. At the time I regularly used TextPad on Windows.
Learning emacs has largely been a matter of experimentation for me:
reading the menus, trying things, and discovering that the emacs
variant (GNU Emacs, as it happens) I was using was very regular and
predictable. I've been adding things to that knowledge over the last
few years as I've needed to learn them, but initially getting up and
running with it to edit text took me minutes.
A particularly uncharitable view might be that CUA was a mistake and
IBM should've used the existing conventions (Emacs's, or the Mac's).
If I held it in 1990, I might even have a point.
The Mac's [conventions] are mostly CUA
Rather, the CUA conventions borrowed heavily from the existing Mac OS
Otherwise, please stop using outdated hardware. Nobody else is:
modern terminal emulators are emulators in name only, and are full-
blown terminals in their own right, with access to all the cool stuff
modern environments provide, like editing keys, mouse support and
unicode rendering and none of the unplesant limitations of the VT**
Such terminal "emulators" are even sillier than using a VT220. At one
time there was no such thing as a better UI than the VT220's. But
anything that can run one of these terminal "emulators" of yours can
do a full-blown proper remote GUI desktop, e.g. connecting to an X
server. Why settle for lukewarm leftovers when you can have the
freshly-cooked meal? Well, expense I suppose, but since all of this
stuff is free software...
I'll refer you to the excellent "In The Beginning Was The Command
Line" by Neal Stephenson for a full explanation of why power users of
all stripes tend to converge on text-oriented interfaces to computers,
but the short version is that a well-designed command line is
automatable much more readily than a GUI is. While there exist
packages for automating GUI actions in Windows (and AppleScript, for
Macs), they're separate tools with their own learning curves. On the
other hand, a good command line is both a user interface (when running
interactively) and a scripting tool, and lessons learned for either
purpose can be used for the other with little friction.
Automation isn't just for programmers.
On the other hand, text interfaces are very lightweight. You said
yourself that the framebuffer for a modern display is fairly chunky,
in terms of RAM; even the most efficient update schemes for that,
which send widget events rather than raw bitmaps, are noticably slower
than typing text into an SSH session and reading text in reply. X11
or msrdc, or worse yet Citrix or VNC, over the internet at full-screen
resolution and bit depth is painfully slow, and over a LAN I might as
well go over to the computer and use it myself.
b) you can't see the region, and applying region commands blindly is
a stupid thing to do. On the other hand, if you're about to cut some
text, you can select the text to cut first, at which point you know
where the region is because you just set it!
I still think there's scope for tragic accidents here. For example,
any of ctrl+Q, ctrl+E, ctrl+A, ctrl+S, and ctrl+D could be miskeyed
easily as ctrl+W. Also ctrl+1, ctrl+2, and ctrl+3, if those are ever
How often do you accidentally hit Ctrl-D or Ctrl-V when trying to copy
text? Why do you suppose emacs users are poor enough typists to make
that class of mistake frequently? And what prevents you from undoing
or cancelling the erroneous keystroke and performing the action you
There isn't. Bleh. You undo by doing anything other than an undo and
then using the undo keystroke. It will resume undoing again if you
(a) change the document or (b) do something other than an undo again.
The undo key will also switch directions one undo past the end of the
undo list: undoing after the first causes it to start redoing, redoing
past the most recent change causes it to undo again.
If this is the sort of stuff found deeper in the help, it's no wonder
people find emacs confusing and nigh-unusable.
It's a form of context sensitivity, and the first time I encountered
it (on my own, by surprise) it made sense fairly quickly. Since then
I haven't needed to worry about it because I know what the undo key
will do at any moment.
I'm talking about "next match", the function that is bound to F3 in a
typical Windoze app and to Christ alone knows what in emacs.
Lovely. I happen to know that on your typical terminal (or emulator!)
this will be intercepted and used as a flow control command. If I'm
not too much mistaken this in turn will result in emacs seeming to
hang. Oops. Another source of confusion and trouble for a new user!
Except that that doesn't happen.
No, really. Try it out for yourself. If you find I'm wrong, the
corresponding resume keystroke is Ctrl-Q (which does nothing harmful
inside emacs in either case -- it quotes the next control character,
in case you want to put a literal control character into the buffer).
The terminal flow control keys only apply when the terminal is
responsible for flowing text. Since emacs, when running in a
terminal, takes over flow control via its terminal library, it also
takes over those keys. When running in a GUI, the terminal keystrokes
are completely irrelevant since there's no terminal at all.
So, yes, Ctrl-S is the keystroke for searching, and for "next match"
once you've begun searching.
It has no "previous match" correspondent to go in the other direction
Ctrl-R. The same key is used to start searching backwards initially.
Eh? That can't be. Nothing I've ever used had a "previous match"
Then I suggest you get a better editor. Eclipse has it; I'm pretty
sure TextPad has it (warning: costs money for a non-nagware version);
various other editors may as well. Several do on the Mac. I'm
reasonably sure even Notepad has it now, in the form of 'up' and
'down' radio buttons (rather than a separate hotkey for acting on the
In emacs, the convention is for the Ctrl-R key to begin a search
backwards if no search is in progress, or to search for the previous
match if one is already in progress. It's the exact mirror of Ctrl-S,
and both keys can be used to navigate quickly through search results.
Your editor is way behind the curve, then. The packaged, shitty text
editor on this system (TextEdit.app) can search backwards with Cmd-
Shift-G (the platform standard hotkey for 'Previous Match', to go with
Cmd-G for 'Next Match').
Looks like one place where Macs do significantly differ from CUA. Did
the older Mac keyboard have function keys?
The Mac keyboard has had a variable number of function keys over its
life. The current crop of desktop keyboards have sixteen of them;
laptops have 12. Some quick research on Google suggests that this has
been true for the last ten or so years -- OS 7-9 and OS X eras.
The original Apple Macintosh, the Apple IIs, and the Lisa did not have
function keys, and in some cases also did not have arrow keys or a
That would explain it --
lack of F3 would mean they'd have to use something else, and ctrl+G is
right next to ctrl+F (find), but they use cmd instead, so...
Since all the keys involved can be reached without moving your left
hand off the home row, I suspect Cmd[-Shift]-G is faster than using
F3, which involves a movement that draws your fingers out of position
to reach and return from.
Search is not the only means of navigation! The current window may show
100 lines or more.
In a 3-point font? No thanks.
In a comfortable, antialiased window that's as short or tall as you
wish to make it.
A 17 inch, 1024-pixel-high display cannot display 100 lines at a
decent font size. Sixty or seventy maybe.
Ok, so on a 17 inch display it's only practical to have 70ish lines
visible. On the other hand, no emacs I know of limits it to that
many: if I turn my main monitor (which is much larger than your 17"
example monitor) to portrait orientation, I can display over 150 lines
at a comfortable size, and emacs handles that just fine too.
I hardly see what this has to do with emacs or vi, though, since you
presumably can only display 70 lines on your hypothetical 1024-pixel-
high display legibly regardless of what program is being displayed.
You know, like "backspace" and "left arrow".
Ah, the two keys least likely to work properly at prompts in a Unix
*If* you're using a terminal *and* it's misconfigured, then yes, the
editing keys may behave strangely. That's not emacs's fault, that's
the user's, for fucking up their configuration, or it's the
distributor's, for screwing up the default configuration. In cases
like that it's a small miracle of common sense that even the letter
keys work reliably.
In various GUIs emacs uses the same keyboard API every other program
uses, and backspace and the arrow keys are absolutely reliable.