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.

bbo...@gmail.com wrote:


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.


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?


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.


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.


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.


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).


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.)


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).


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.


Rather, the CUA conventions borrowed heavily from the existing Mac OS
conventions.


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.


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
intended to?


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.


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.


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
"last" search).

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.


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
numeric keypad.


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.


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.


*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.