Re: Great SWT Program
bbo...@gmail.com wrote:
On Oct 31, 8:02 pm, Lars Enderin <lars.ende...@gmail.com> wrote:
If all you want to do is write email, you don't need emacs, but of
course you can use emacs as an email client if you wish. Using emacs for
plain text editing does not require more training than using Notepad.
To lay this to rest, I've done some of the research you refuse to[0]
[1]. The following screenshots were taken on a fresh install of
Ubuntu Desktop 7.10, the most recent release, installed in VMWare.
Anyone can repeat my experiments, either on VMWare or on real
hardware. Hopefully this is suitably in the spirit of the scientific
method for you. All links in this post to bast.lionsanctuary.net are
of type image/png or text/html (HEAD them yourself) and of reasonable
size, and contain no advertisements. The images, since they are of
GPL, Mozilla, and BSD-licensed software, are released into the public
domain under the appropriate fair-use laws. Do not take this post
internally.
The only thing I did prior to the experiments themselves was start the
system from the desktop disk image (it boots to a running environment)
and install emacs using the Add/Remove tool on the Applications menu.
It's listed under Accessories as "Emacs 22 (GTK)" and "Emacs 22
(X11)":
<http://bast.lionsanctuary.net/~owen/images/Emacs22/Installing>
chose the X11 version, as the Add/Remove tool did not allow me to
install the GTK version (the GTK version is only available from the
'universe' apt repository, which is disabled by default). The X11
version does not install an icon in the Applications menu (but see
below; the GTK version does).
The preinstalled text editor is Gedit; obviously you'd have to
consciously choose to use emacs to get it.
I particularly did NOT copy any .emacsrc or other configuration files
from any other machine.
Bull! No normal GUI;
<http://bast.lionsanctuary.net/~owen/images/Emacs22/JustLaunched>
The result of typing 'emacs' with no arguments at a shell.
no easy way to access the help
<http://bast.lionsanctuary.net/~owen/images/Emacs22/HelpMenu>
The help menu. Note the hotkeys listed next to menu items.
or most other functionality;
<http://bast.lionsanctuary.net/~owen/images/Emacs22/EditMenu>
The edit menu.
normal command inputs just don't do the expected
<http://bast.lionsanctuary.net/~owen/images/Emacs22/
FromFirefoxToEmacs>
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
window).
<http://bast.lionsanctuary.net/~owen/images/Emacs22/EmacsToGedit>
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).
the old problem of focus being in the document window only when the help
is either not open, or open to "help on switching windows"
<http://bast.lionsanctuary.net/~owen/images/Emacs22/RegionHelp>
The help on selecting text, displayed alongside a document in a
single emacs process.
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. I used the al jazeera site as a source of
arabic text.
I noted earlier that the
way Bent describes navigation depends on exact memorization of the
entire text of a document.
Emacs users are no more *restricted* to search as a navigation tool
than Wordpad users are. In cases where searching makes no sense, you
can use the Page Up/Page Down keys or the scrollbar (see second and
subsequent screenshots). Or jumping to a line number, as you
mentioned. Or the mouse wheel.
Bent only described one tool for navigating.
Well, if the original search term was insufficient, you have to type
some more characters. What's the problem with that?
The problem is that us Windows users can navigate easily and freely
inside of a document with NO TYPING AT ALL and no guesswork or
memorization, AND in a fraction of the time, so all of this is an
amazingly elaborate argument over a crutch-like instrument that might
come in handy one day if your mouse goes on the fritz. Me, I'd prefer
to have a spare mouse lying about, because the alternative sounds like
torture. :P
By the time Bent's done typing his query and arriving *maybe* where he
wants to go, I'm already there and well on my way to completing the
next step in whatever my task is.
If it works, it works beautifully. If you don't know what you are
searching for, you have to look at the text and try to find it, just as
you would have to do with your tools.
No, with my tools I can get there by scrolling with the mouse and
scrollbar, or scroll wheel. He's stuck hitting page up sixty thousand
times. :P
See second and subsequent screenshots: he can use the scroll bar. Or
the scroll wheel (I tested it on the help and on a normal document).
If the selection is invisible (not high-lighted) it's not vulnerable.
The phantom selection that isn't. Pray tell, if you can't interact
with it at all, just what good is it?
First, I'll note that the X11 GUI defaults to showing the region as a
pale yellow highlight ("active region highlighting")[2], and the
console UI defaults to not showing the region; either can be
configured independant of the other to show or not show the selected
region.
The selection defines a region for commands that use a region
(conveniently, the symbolic names for those commands almost
universally include the word "region"). Typing more text is not a
command that uses a region. Copying, cutting, and pasting are. So is
reindenting (reindent-region) and rewrapping.
I routinely use "kill-region" (C-w) + undo to copy a piece of text,
which I can then use somewhere else.
So doing tasks efficiently in emacs requires living dangerously? Why
-- cut and paste but no copy?
M-w. Same key, different modifier. He may find C-w C-/ (or one of
the other two undo keys) faster to type. It's hardly living
dangerously -- either he completes the operation (it's two keystrokes)
or he doesn't. If he does it that way habitually he probably has to
consciously stop himself before the undo if he wants to do some other
operation first.
It being different from everything else in the known universe might
have something to do with it.
Emacs key bindings precede DOS and Windows' key bindings.
In other words, they have an excuse -- they didn't break the standard
because no standard had established itself yet. That doesn't make them
not nonstandard and awkward, though.
If you don't like them, there are configuration files available on
google that map them to something you might find more comfortable.
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).
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):
<http://www.gnu.org/software/emacs/manual/html_node/emacs/CUA-
Bindings.html>
This option is disabled by default on most distributions because the
majority of emacs users prefer the keystrokes they're already
comfortable with. You're free to improve the world by releasing an
emacs package that is nothing more than GNU Emacs with cua-mode
enabled by default, if you like.
I had no problem with learning CUA keys despite having used emacs for decades
before I saw DOS or Windows..
That might have something to do with the fact that CUA keys make
sense.
What does the letter 'z' have to do with undo? It's just a
convention, like many others; it's not noticably better or worse than
the OS X conventions or the emacs conventions or the vi conventions.
The CUA conventions are a fairly recent arrival (invented by IBM less
than 20 years ago, for VMS and OS/400); compare that with Mac OS
(1984) or the original emacs (1976).
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.
(There is also a history of marks, which you can use to revisit old
places in the document.)
So much for a simple model for selections it seems. The novice won't
know if he's coming or going ... or what chunk of the document will go
away if he hits cut or delete. :P
You simply navigate outside the selection with some key, maybe a down
arrow. You can also use the mouse and click.
??? I thought you'd implied that once you set one endpoint you're
always at the other of a selection between the two. Moving down would
then just extend the blasted thing a line, or shrink it a line,
depending.
Clicking outside a selection, by convention, sets a new mark at the
click (clearing the old mark, and thus the old selected region). With
active region highlighting on, text navigation also clears the mark
(since having a moving highlight is distracting).
As for a mouse click, anyone inputting a mouse click to emacs remotely
via a VT220 or whatever terminal and posting the video to YouTube as
proof wins a prize.
Have you used Links (a web browser) recently? You might; it can
accept mouseclicks over putty (a terminal emulator for windows) or
gnome-terminal (a terminal emulator for linux).
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**
series.
You *cannot* clobber an unmarked selection. Typing will not overwrite
it. If you want to replace a selection (unmarked or not), type C-w, and
it will disappear (but can be recalled). Then you can type anything in
its place.
Lovely, so your invisible phantom selection can still be accidentally
destroyed. Meaning nobody will dare to hit Ctrl+w for fear of the
consequences. Combined with a history of past selections, it sounds
like *anything* could disappear, and not even near the current
insertion point.
The mark history (something I only just learned about) is not exactly
easy to trigger by accident. If you're not using it, then either
a) you can see the region, because you have active region
highlighting turned on (the default when run as a GUI, on the test
system), and you know what will be effected, or
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!
Undo in emacs is smarter than that. You can undo the last undo by e g
typing a space, then hit undo twice, etc.
I don't like this, personally; I use a navigation keystroke (undo, up,
undo) to redo, but an explicit redo would be better.
*checks the help*
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.
However, there is an option to undo changes only within the region,
which is kind of cool.
Eh. Worse than useless. Undo undoes undos means only one undo level.
Emacs' undo lets you undo and redo an arbitrary number of changes.
The fact that the keystroke for undo switches between redo and undo
based on the user's behaviour in practice works pretty well for me.
Sane apps have many undo levels and separate undo and redo commands.
And none can cope with a "branch": do X, undo X, do Y -> X can't be
gotten back now, and do X, do Y, undo Y, undo X -> Y can't be gotten
back without also redoing X.
I have a Go board program (glgo) that says you're wrong here, too.
Revision control systems like mercurial or PVCS might constitute a
form of "undo" (that's a relatively common use of them, certainly)
that can handle branching and merging changesets.
Very few *text editors* support it because within any single session
very few users want branching change paths. The complexity isn't
worth the benefit there.
No, it isn't. I wouldn't want to try to navigate a web page using
solely Firefox's search -- I'd need to memorize the whole thing
precisely in order to find any given spot reliably. Maybe such
memorization comes easily to you, but it doesn't for the vast majority
of human beings.
[insult deleted]
Liar!
It's very easy to go back one step when searching incrementally.
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.
Ctrl-S.
It has no "previous match" correspondent to go in the other direction
Ctrl-R. The same key is used to start searching backwards initially.
typically, so if you miss your stop, you have to wait for the next
bus, so to speak.
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').
More guesswork, this time with numbers.
You need to remember something to find it.
You need to remember an exact four-digit number to find it. In fact,
instead of knowing the exact text of the whole document precisely, now
you need to know exactly what line number goes with each important
fact. This isn't gonna happen unless you give up the leftmost five
characters (1/16 of the screen real-estate!) to displaying line
numbers for every line and spend hours poring over the whole fucking
document. Lovely. Just lovely.
Me: Scroll to approximate area; then make more precise small movements
to get the destination in view and stop there.
We can do that too, it that's what it takes.
With what, some kind of "accelerating and decelerating page up" key?
It's called a "mouse wheel" or a "scroll bar". See second and
subsequent screenshots.
That doesn't sound very easy to use to me. Windows apps of course give
you a scrollbar with many nifty features. The little bit you drag (the
"thumb") has a height representing the proportion of the visible
portion to the full document
As does Emacs' scroll bar.
You keep harping on the supposed savants. You don't need to be one to
use emacs.
No, you just need to be one to use it and be productive instead of
frustrated.
Honestly, you might *possibly* have had a point fifteen years ago.
The X11 frontend for GNU Emacs has been around in broadly similar form
for most of that time, so if you can point and drool, you can use
emacs.
Yes you can. A vertical scrollbar shows the relative position.
In what application? I thought we were discussing emacs?
See second and subsequent screenshots.
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.
There is a command history in emacs. You can go back to some old command
and reissue it, possibly after editing it.
Editing commands? Now it is sounding excessively complicated.
You know, like "backspace" and "left arrow".
The M-x grep command prompts for arguments - search string and file(s).
After execution, you get a buffer with matching lines. You can choose
one of these matches and instantly have the document in a buffer. "Next
match" is a simple key combination.
Eh -- there's a command when editing a text file to interpret the line
with the insertion point as a file path and open it?
Nothing says a buffer has to be text. Most of them are, but (for
example) dired buffers list directory contents in a semi-hot way:
pressing "enter" while the cursor is over a filename in them, or
clicking on the filename, opens the file in a buffer (or the
directory, if it is one, in another dired buffer). There are other
special-behaviour buffers provided by other packages, such as the
buffer M-x grep produces to display its results.
Since you don't like "special" buffers, you're free not to use them:
emacs never opens a buffer except in response to your actions, so if
you discover something that opens a buffer you don't like, close the
buffer (C-x k <RET> is the sequence I use; there may be a faster one)
and don't do that again.
Emacs commands are saved in the history, including arguments, and are
fully editable.
??? At a one-line prompt? The equivalent of a one-line input field in
a Windows dialog box? This makes no sense. There isn't *room* for the
drop-down or any other useful visual feature anyway.
You can expand the command history into a full-blown buffer of its
own, if you like, and edit it there.
Of course the command mini-buffer supports paste!
Not using the normal paste command.
If the active buffer is the mini-buffer, C-y (the default paste key)
pastes into it. If the active buffer is a document buffer, C-y pastes
into it. The only time that's not true is for search, and that's
because of a special case in the search code, not because there's a
special "paste into command" key.
After I finished writing this up, I actually used my debian knowledge
to install the emacs22-gtk package to compare notes. Here's some
screenshots, for comparison purposes:
Applications Menu:
<http://bast.lionsanctuary.net/~owen/images/Emacs22/AppMenu>
File Dialog:
<http://bast.lionsanctuary.net/~owen/images/Emacs22/FileOpen>
I18n:
<http://bast.lionsanctuary.net/~owen/images/Emacs22/Unicode>
Some katakana text copied and pasted from google, in Emacs (GTK).
<http://bast.lionsanctuary.net/~owen/images/Emacs22/ConsoleUnicode>
The same text in console-mode emacs. Note the presence of the
menu bar within the emacs window and the overall similarity to the X11
GUI. (TERM=color-xterm)
If Twisted keep his shit up, I'll probably do the same thing for the
Mac OS port of emacs (specifically Emacs.app, because it's the one I'd
use if I were to use emacs instead of TextMate), just to demonstrate
how far behind the state of the art your opinion of emacs is. I could
do Windows, too: there's a native version of GNU Emacs available for
that, too.
[0] Any takers for vi? I'm even less of a vi user than I am an emacs
expert.
[1] This isn't as insane as it sounds, since I've been meaning to try
out 7.10 anyways.
[2] It also enables global font lock in X11 by default, which means
that if you open a file ending in .java, you get Java syntax
highlighting to go with the extra, Java-specific menu items that
appear.