[this post is a excerpt from
The Modernization of Emacs, Xah Lee, 2006-04 at http://xahlee.org/emacs/modernization.html
]
The Modernization of Emacs
----------------------------------------
THE PROBLEM
Emacs is a great editor. It is perhaps the most powerful and most
versatile text editor. And, besides text editing, it also serves as a
email application, newsgroup application, ftp application, irc
application, web browser, shell interface, file management
application, programable calculator, calendar and personal info
management application, lisp language system, among other things.
These seemingly wild functionalities are employed in production daily
by a significant number of programers around the world. Some calls
emacs as a Operating System as a joke. (Technically it does not
qualify because a OS implies management of hardware.).
If emacs is such a great and powerful text editor why almost nobody
knows about it? Vast majority of people who need to write will be more
than happy to use editors other than emacs. Ask a Microsoft Windows
user. She'll be more than happy to use Microsoft Word↗. If he doesn't
have MS Word, he'll use NotePad↗ or WordPad↗. If he is a programer,
most will be more than happy to use any of other graphical editors on
the Windows platform or any of the Integrated development
environment↗. Same is true on other operating systems, and new editors
spring up here and there even though they don't have as much power or
flexibility as emacs. For example, there are NEdit, JEdit, Eclipse,
Xcode↗ , or the various associated with languages or third party
language software, such as Visual Basic or Borland C++.
Many reasons can be made out of this. For example, emacs is not
bundled on popular operating systems such as Windows or Mac, which are
used by some 99% of computer users worldwide. Windows and Mac both
have simple text editors bundled that will satisfy majority of
computer users, which are non-professional computer users. (NotePad
and WordPad on Windows, TextEdit↗ on Mac) For the few professional
computer users, a majority will need a easy to use, yet powerful
editor that also does styled text, formatting, and sundry light
publishing needs such as table layout, simple line graphics drawing,
embedded images, math formulas. They will choose and adopt Microsoft
Word for their needs. The tiny percentage that might be interested in
emacs, are programers. Even among professional programers, a majority
shy away from emacs.
A major difficulty among programers who do not use or like emacs, is
that emacs's user interface is rather esoteric, involving arcane
terminologies and keystrokes. This is in sharp contrast to the
thousands of software applications used today, where their User
Interface are similar and familiar to today's computer users.
----------------------------------------
THE COMMON USER INTERFACE
The following is a excerpt from the Wikipedia article on Common User
Access↗:
CUA was a detailed specification and set strict rules about how
applications should look and function. Its aim was in part to bring
about harmony between MS-DOS applications, which until then had
implemented totally different user interfaces.
Examples:
* In WordPerfect, the command to open a file was [F7], [3].
* In Lotus 1-2-3, a file was opened with [/] (to open the menus),
[W] (for Workspace), [R] (for Retrieve).
* In Microsoft Word, a file was opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load).
* In WordStar, it was [Ctrl]+[K]+[O].
* In Emacs, a file was opened with [Ctrl]+[x] followed by [Ctrl]+
[f] (for find-file).
Some programs used [Esc] to cancel an action, some used it to complete
one; WordPerfect used it to repeat a character. Some programs used
[End] to go to the end of a line, some used it to complete filling in
a form. [F1] was often help but in WordPerfect that was [F3]. [Ins]
sometimes toggled between overtype and inserting characters, but some
programs used it for “paste”.
Thus, every program had to be learned individually and its complete
user interface memorized. It was a sign of expertise to have learned
the UIs of dozens of applications, since a novice user facing a new
program would find their existing knowledge of a similar application
absolutely no use whatsoever.
----------------------------------------
SIMPLE CHANGES
In the following, i describe some critical changes that are also very
easy to fix in emacs. If emacs officially adopt these changes, i think
it will make a lot people, at least programers, like emacs and choose
emacs as their text editor.
* Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
v as to be the same with all modern applications.
* Change the undo behavior so that there is a Undo and Redo, as
the same with all modern applications.
* Get rid of the *scratch* buffer.
* Change the terminology of “kill” to “cut”, and “yank” to
“paste”.
* Change the terminology of Meta key to Alt.
* Make longlines-mode the default editor behavior for any file.
Things emacs should do now, even though it eventually will do.
* When opening a HTML document, automatically provide highlighting
of HTML, CSS, and Javascript codes. Similarly for other multi-language
files such as PHP, JSP, et al. This behavior must be automatic without
requiring user to customize emacs.
Possible Documentation Change Proposals
* Reduce the use of the word “buffer” in the emacs documentation.
Call it “opened file” or “unsaved document”.
* Switch the terminology of Window and Frame so it is more
standard. That is, Emacs's “Window” should be called Panes or Frames.
While Emacs's “Frame” should be termed Window.
* Change the terminology of keybinding to “keyboard shortcut” in
emacs documentation. Use the term keybinding or binding only in a
technical context, such as in elisp documentation.
Xah xa*@xahlee.org
∑ http://xahlee.org/
Jun 17 '07
331  14658 
Twisted wrote:
If I sit down at a windows text editor (or
even kwrite or similar) I can just focus on the job. Faced with emacs
or most other text-mode editors (but not MS-DOS Edit, interestingly)
the editor keeps intruding on my focus. Oops.
"emacs or most other text-mode editors" sounds very much like you
believe emacs works in a pure text mode too? It can, of course, and
that's a good thing, but that's certainly not how I usually use it -
it has a GUI, you know.
Bjorn Borud <bo********@borud.nowrote:
>
bah, UNIX is not user hostile; it is just selective about its
friends.
Right. My favorite Unix quote is from the same source (Dennis Ritchie):
Unix is the answer. You just have to phrase the
question very carefully.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Cor Gest <co*@clsnet.nlwrote:
>Some entity, AKA ne********@gmail.com,
wrote this mindboggling stuff:
>On Jun 22, 6:32 pm, Cor Gest <c...@clsnet.nlwrote:
So now we're expected to go on a filesystem fishing expedition instead
of just hit F1? One small step (backwards) for a man; one giant leap
(backwards) for mankind. :P
that's M-` Escape-Backtick in a CLI, for you, thank you very much ...
Function-Keys do not work in in a vt100 terminal.
You really are that shallow, aren't you ? and lazy too, huh ?
Boys, do you really not understand that this is a religious issue? You
can't use arguments and logic to convince someone to convert their
religion, and you can't use arguments and logic to convince someone to
change editors.
Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine. Editor, that is. I do
occasionally change my underwear.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Falcolas <ga******@gmail.comwrites:
>
>It's Mac OS and Windows which are inconsistent. Emacs has been
around since they were mere glimmers in the eye of Jobs & Gates...
Inconsistent? I would have to disagree. They changed paradigms -
terminal text based interfaces to GUIs. You wouldn't expect a piece of
software built for a terminal to be backwards compatibility to punch
card interfaces, would you? Why would a GUI based program limit itself
to functionality as defined by a terminal application?
You're making the assumption that Mac OS in 1984 offered some textual
capability (textual, since we're discussing text editing) which emacs
did not. It didn't.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A: Top posting
Q: What's the most annoying thing about Usenet?
Twisted <tw********@gmail.comwrites:
>
How clunky versus usable an interface to a tool is is for those who
invest some, but not extraordinary amounts of, time into its use to
decide. If it requires years of mastery, it is clunky -- period. This
may be unavoidable if it's something involved in nuclear power plants,
delicate neurosurgery, or whatever. If it's a text editor, on the
other hand, it's clearly going to have superior competition in the
area of usability.
Of course, emacs doesn't take years of mastery. It takes 30, 40
minutes. And a functioning intellect, of course.
Incidentally, a violin requires years of mastery, and is hardly cranky.
Granted, there are few people with the talent to play a violin well.
Maybe an automobile is a better example...
Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky.
That sounds like vi, not emacs.
Applications that not only eschew normal methods of navigation of the
interface, but force you to fumble your way between the help and the
task you're trying to do, are definitely clunky.
a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
its own thing since before there _were_ Mac OS or Windows
b) I believe you've never used the emacs tutorial, which is quite
definitely designed for you _not_ to have to fumble around between
windows
The interface never improved over that time -- the biggest problem
consistently being that whenever focus was successfully transferred to
the document window, the help window was invariably open to the
instructions for switching windows, so you could never be doing
something with the document and have the help for that something
available at a glance.
That doesn't even make sense. Either your memory is faulty, you've
never actually used emacs (something I'm beginning to suspect more and
more) or you're just making things up. 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. In
fact, I am not aware of any package which auto-changes the *info* or
*Help* buffers to reflect the last keyboard command.
Even though it would be at the price of no full- text search
capability -- not that I could ever get that to work in emacs
anyway. There was no apparent way to do a simple substring search and
click "next match" or "previous match" to navigate among the
hits...more arcane keypresses would be required, and as soon as it
showed you the first match inside the help, the keypress documentation
of course vanished.
Dude, you hit C-s; you're prompted for a search string; you hit C-s to
search for the next match. From line 899 of the tutorial:
>Now type C-s to start a search. SLOWLY, one letter at a time,
type the word 'cursor', pausing after you type each
character to notice what happens to the cursor.
Now you have searched for "cursor", once.
>Type C-s again, to search for the next occurrence of "cursor".
If you had actually, you know, actually _read_ it this would not be a
surprise. I hate to be rude, but I just don't see how you could ever
have actually done what you claim to have done.
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; it displays
commands and shortcuts next to them; one can learn to use them instead,
at one's own pace.
Every time you want to use the command but can't remember the shortcut
you just find it in the menu and activate it from there, and see the
shortcut while you're at it, helping to eventually memorize it. And
the commonest sorts of File and Edit menu items have near-universal
shortcuts, the big variation tending to be whether Redo is
shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.
You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same. I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.
The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing? Wouldn't it be
cool not to have one program implement search in one way, and another a
second way, and yet another a third? Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?
But you can start using it right away with low productivity, and
increase your productivity with proficiency and learning (optional)
shortcuts, chiefly those to the commands you happen to use a lot.
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).
One person elsewhere in this thread even went so far as to suggest
that to avoid having a similar hurdle with every application you just
use emacs for everything. If you like being claustrophobically trapped
in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
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.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A wealthy man is one who earns $100 a year more than his wife's sister's
husband. --H.L. Mencken
Bjorn Borud <bo********@borud.nowrites:
>
| The idea is to start Emacs once and use it for everything.
...which is fine as long as you are only fiddling around on one
machine or you have emacs windows running on all your machines.
Tramp can be used to access files on other hosts. It even supports
multi-hop stuff like 'ssh to $HOST and su to root.'
One thing GNU emacs needs to support is the ability to open a new X or
terminal window via a command. I think Xemacs can already do this.
also, I make extensive use of the readline and history features when
fiddling about in the shell. shells have a lot of context if you use
them effectively. context that isn't easy to transport between the
shell and emacs -- and it isn't really easy to explain either.
M-x shell, or M-x terminal
--
Robert Uhl <http://public.xdi.org/=ruhl>
That's just 'mostly dead.' What we are concerned with here is 'Pining
for the Fjords' dead. --Mark Urbin
Twisted <tw********@gmail.comwrites:
That's entirely orthogonal to the issue of interface learning curve
OR interface ease-of-use. Emacs has deficiencies in both areas, if
principally the former. (For an example of the latter, consider
opening a file. Can't remember the exact spelling and capitalization
of the file name? Sorry, bud, you're SOL. Go find it in some other
app and memorize the name, then return to emacs. Now THAT is what I
call disruptive context switching.
Again, you are talking nonsense out of ignorance. When you are _not_
using filename completion, any case entry on a case insensitive file
system will work (even when we are talking about a FAT/NT file system
mounted on Unix). And _when_ you are using filename completion, on
_those_ systems where case insensitive file names are standard
(DOS/Windows/VMS/MacOSX), Emacs will notice and replace stuff with the
proper case _when completing_ (in all other cases, there is no problem
in mixing up case in the context of case insensitive file systems).
If you want a different standard than that of your operating system,
customize the variable `read-file-name-completion-ignore-case'.
It would probably be most clever if Emacs completed case-independently
only on those parts of a file name which are on a case-independent
file system (or a case independent context) so that a file name like
/da*@box.gnu.org:/media/usbstick/Photos/nice.jpg
~~~~~~~~~~~ ~~~~~~~~~~~~~~~
would get case-insensitive completion just on the underlines areas.
In practice, it is actually more the users than the operating systems
which are or are not comfortable with the consequences of case
sensitivity, and so making the default depend on the default
convention of the system seems reasonable.
So please: before you continue spewing about a system you don't even
know, could you educate yourself about the state of affairs?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Twisted <tw********@gmail.comwrites:
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD
TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?!
Because there is a menu called "HELP" and because the "standard"
keybinding for help, f1, brings up help?
Not to mention that there is an initial splash screen pointing this
out?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Pascal Bourguignon <pj*@informatimago.comwrites:
Falcolas <ga******@gmail.comwrites:
>>
Would you mind elaborating on *what* took 3 hours to do, as opposed
to just throwing around unquantified numbers? Would you also mind
explaining the user's familiarity with the tools they were using on
the mac?
Anything that the user have to do repeatitively with the GUI, like
copy-and-paste, or reformating of a lot of paragraphs or table
entries, and which is done automatically by writting a one-liner
program in emacs or shell.
Actually, in Emacs the task more often than not is solved by using
C-h a or M-x apropos and then finding the command that already does
the job.
>It's just as easy for me to say that it took me 30 minutes to
simply exit emacs, and use that to justify that emacs, and by
extension Linux, is a terrible tool.
Somebody who needs 30 minutes to find the File/Exit Emacs menu is not
qualified for reporting _any_ computing experience.
It is like letting yourself get a report about the points of violin
playing from somebody who has just had his first exposure to music,
incidentally in the form of a violin lesson.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Falcolas <ga******@gmail.comwrites:
On Jun 22, 11:28 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
>It's Mac OS and Windows which are inconsistent. Emacs has been
around since they were mere glimmers in the eye of Jobs & Gates...
Inconsistent? I would have to disagree. They changed paradigms -
terminal text based interfaces to GUIs. You wouldn't expect a piece
of software built for a terminal to be backwards compatibility to
punch card interfaces, would you?
You are aware that the ubiquitous standard terminal width of 80
columns has been chosen to match the 80-column punch card standard?
Why would a GUI based program limit itself to functionality as
defined by a terminal application?
Emacs uses variable width fonts, can deal with a larger-than-8bit
variety of GUI-based input events and can display images. Take a look
at the screen shots for preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.html>
illustrating WYSIWYG LaTeX editing in Emacs windows.
So what is your problem?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Twisted <tw********@gmail.comwrites:
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD
TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?!
Because there is a menu called "HELP" and because the "standard"
keybinding for help, f1, brings up help? And because there is that
standard GNOME icon of a lifesaver which you can click?
Not to mention that there is an initial splash screen pointing most of
this out?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum ne********@gmail.com writes:
PS you'll have to stop posting such a high volume here. I'm getting
BS from Google Groups about posting limits being exceeded again.
Oh, but that just means that _YOU_ will have to stop posting such a
high volume here. Others are not affected. Though I have no doubt
they'll welcome a thinning out of this thread (followups directed to
comp.emacs for that reason).
Apparently they've lowered it still further, from 25 in a 24 hour
period to 12 or so in a 24 hour period. Fuckers.
How about making _summary_ answers then? Your whole contributions
boil down to "You must be lying. This can't be Emacs you are talking
about, since I know Emacs intimately because of having looked at an
old version of it for half an hour about 10 years ago." anyway. You
don't need to post this 12 times per day. You don't even need to post
this at all. It does not get any less stupid by repetition.
What _is_ sort of amusing is that years ago you already accused me of
forgery when I pointed you to the Emacs screenshots on the
preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.htmlpage.
It appears that you still have not bothered educating yourself, years
after you were pretty much universally derided in comp.text.tex for
making a spectacle of your self-chosen ignorance.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Some entity, AKA Tim Roberts <ti**@probo.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
Boys, do you really not understand that this is a religious issue? You
can't use arguments and logic to convince someone to convert their
religion, and you can't use arguments and logic to convince someone to
change editors.
Nah, nothing beats a nice flame-war on a slow fridaynight & a Pint
of Bitter, while it spares the fingers to keep on manipulating all those nice
keyboard-modifiers to nag the ignorati for an other day ... ;-)
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
[Twisted <tw********@gmail.com>]
|
| I have observed similar opinions in other non-computer-freaks. people
| who see the computer only as a tool and are only interested in getting
| the job done. they have a surprising preference for Linux.
|
| But not emacs, I'll bet. I think emacs appeals to people who like
| dealing with the mechanics of emacs or fiddling with and extending the
| darn thing. But most people just want to get the job done, and the
| editor or other tools they use have to get out of the way and simply
| let them work.
no, Emacs is not among the applications they use. nor are any IDEs or
compilers. I don't think Emacs is that relevant to these users since
what they do is mostly word-processing, spreadsheets, mail and web
browsing. Emacs is not really targeted at Word processing as
such. (although that doesn't stop some people from thinking that it
would be a good idea to turn Emacs into a wordprocessing application
with support for graphics, mixed fonts etc.)
I use Emacs for creating documents, but this is very different since I
use LaTeX and I'm a programmer, so it is very conventient for me to
use a system that allows me to treat documents like code (with respect
to revision control systems etc). outside academia or the technical
community, not that many use LaTeX, but I have seen it in the past.
-Bjrn
[Twisted <tw********@gmail.com>]
| You end up having to memorize the help, because *you can't
| have arbitrary parts of the help and your document open side by side
| and be working on the document*. All because you can't simply tab or
| click to the document.
yes you can. you even have a lot of choice as to how you want to do
it and it even works on the simplest of text terminals (which is
useful when you are on the road and only have a computer with a
browser availabe and you've had the foresight to set up the Mindterm
SSH applet on a machine so you can log in and edit code from anywhere
in the world).
I use multiple frames on-screen most of the time. either to edit and
view multiple files at once or to edit different locations of the same
file. if you're a programmer it is often useful to be able to do
this. you can look at more than one file at the same time, have
documentation up on screen etc.
| At minimum, you have to *memorize* some arcane key controls for
| switching panes ... er, "windows", that are totally unintuitive and
| unlike what is normally used.
following the built-in tutorial in Emacs I understood how to
manipulate buffers and split windows in various ways. there are
basically three commands you need to know. one of them is used to
switch between active buffers in a given window, so it is not specific
to splitting.
it took me minutes to learn and within days I didn't even think about
what I was doing -- I was just using the features.
I think you fail to understand the approach. if you know an editor
like VI or Emacs properly you have a much bigger bag of tricks, that
are applicable to a wide range of scenarios, than what is encouraged
by GUI intensive editors. and you don't think of them as "tricks".
it is just the way you edit text.
| Oops. The interface design is a nightmare. The most basic requirement,
| that it be easy to have the help open side by side with your document
| and switch back and forth and navigate inside the help easily, is
| broken. If you have to consult the help just to navigate the help or
| to switch focus between document and help, then you're trapped, and
| that is what happens with emacs.
why don't you learn Emacs before you say what it can and can't do?
it is so frustrating to debate editors with people who haven't even
bothered to make a minimal effort to at least spend a day or two
learning it.
let's look at Word and word processing. how long does it take you to
learn Word properly? to understand how to efficiently edit large
documents, automate common tasks, use the built-in features for
helping you organize documents?
-Bjrn
Joel J. Adamson wrote:
Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
in to how people already lived, not the other way around.
I've never got my hands on a genuine Xerox. About the nearest to that I
managed was an ICL PERQ back in 1980, with a portrait-mode black and
white screen and a three button mouse. That was the first GUI I saw
(next was an Apple Lisa in 1984). The PERQ was dead easy to use after
about 5 minutes instruction.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
BartlebyScrivener wrote:
On Jun 22, 3:47 pm, Twisted <twisted...@gmail.comwrote:
>If it requires years of mastery, it is clunky
Well, now you keep harping on this, but it's just not true.
I use vim myself, but for purposes of this argument it doesn't matter.
If you take the Vim tutorial and use the help (which appears in a
split window anytime you want it), you can use Vim like any other text
editor within a day or so, especially if you use Cream, which is set
up to hold your Windows hands and act like any other Windows text
editor on the surface. But if you use Vim for YEARS you get better and
faster and more efficient precisely BECAUSE of its arcane
capabilities. If you are going to keep your hands on the keyboard
where they belong, if you REALLY want to go fast, then there's no
alternative to having complex key commands, which become second nature
over time, and take the place of repetitive, totally inefficient
mousing around.
You might enjoy this. Especially the link to an old essay called
"Interface Zen"
http://tinyurl.com/2da3om
A good reference. Thanks.
I like Interface Zen - much sense there.
However, there's a case he missed, probably through never using a CAD
system. All the good ones can be driven either by mouse, or by
non-chorded key sequences or any combo the user likes. The essence of
CAD is very accurate pointing but all too many mice move slightly when
clicked. Fortunately a decent CAD system offers the possibility of
purely pointing with the mouse and doing everything else with the other
hand on the keyboard. The result is both fast and extremely accurate.
An interface design point that nobody has yet mentioned here is that
there are four different types of user that map onto a grid:
casual dedicated
untrained 1 2
expert 3 4
I first ran across grid this in "Design of Man-Computer Dialogs" by
James Martin and its been very useful in systems interface design.
The problem with almost all current GUIs is that they are aimed at types
1 and 3 users - this certainly applies to Windows, OS X and Gnome
desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
at type 3 and 4 users.
Where does emacs fit on this grid? My guess would be 3 and 4.
Its very difficult indeed to design an interface that suits both
untrained and expert users. About the closest I've seen have been
keyboard driven menu structures which have been designed so the user can
build their own "command sequences" that traverse menu levels without
showing the menus, as long as items are selected correctly from each
level. Many CAD systems approximate to this but I've yet to see a
graphical desktop, IDE, or editor menu structure that came close.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[Falcolas <ga******@gmail.com>]
|
| I guess ultimately I'm trying to argue the point that just because a
| tool was written with a GUI or on Windows does not automatically make
| it any less a productive tool than a text based terminal tool. Even in
| windows, you can use the keyboard to do all of your work, if you learn
| how (thanks to the magic of the alt key).
as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.
the point I am trying to get across is that Emacs (and vi) is its own
niche, and that if you want to improve them, there are more important
things than fiddling around with superficial details (like keybindings
-- which you can customize to your own liking anyway).
for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).
-Bjrn
Bjorn Borud wrote:
[Falcolas <ga******@gmail.com>]
|
| I guess ultimately I'm trying to argue the point that just because a
| tool was written with a GUI or on Windows does not automatically
| make it any less a productive tool than a text based terminal tool.
| Even in windows, you can use the keyboard to do all of your work, if
| you learn how (thanks to the magic of the alt key).
as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.
I think it worthwile to point out again here that emacs does in fact
have a bitmapped, windowy GUI, has done for years - e.g. http://oldr.net/emacshelp4.gif ...
Some people in this silly thread (not Bjrn specifically) seem to be
labouring under the impression that it is solely a text-only
interface - "Mouse longcuts" exist for the most basic keyboard commands
when you're using emacs on a WIMP system like X11 or Microsoft Windows
(though you can turn them off to stop wasting screen real estate on
pretty-pretty once you know the keyboard commands)
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).
Climacs @ http://common-lisp.net/project/climacs/
[Twisted <tw********@gmail.com>]
|
| That sort of negative-sum thinking is alien to me. Software being easy
| for beginners to get started using does not in and of itself detract
| from its value to expert users.
the fact that you imply that this is my argument tells me that either
you have not paid attention, or you have a raging inferiority complex.
given the sum of your postings so far I'd say that you neither are,
nor consider yourself, a cerebral sort of person, so this narrows it
down somewhat (although not to the exclusion of you not having paid
attention).
-Bjrn
Tim Roberts wrote:
Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine.
You really should have stopped here.... :)
Matthias Buelow <mk*@incubus.dewrites:
Tim Roberts wrote:
>Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine.
You really should have stopped here.... :)
Well if "It stinks!" is not incentive enough for him to change his
underwear, what will?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Twisted <tw********@gmail.comwrites:
>
For an example of the latter, consider opening a file. Can't remember
the exact spelling and capitalization of the file name? Sorry, bud,
you're SOL. Go find it in some other app and memorize the name, then
return to emacs.
Once again I am forced to wonder if you have _ever_ actually used
emacs. find-file has tab completion: hit tab without anything typed, and
it displays _everything_ in the directory; type a few characters to
narrow it down; hit tab to complete the filename and be done with it.
Or of course you could use directory mode, which enables you to navigate
around a directory tree, performing actions on files (including editing
them).
Then of course there's ido.el, which is even better: type a few
characters from anywhere in the name, and it displays files matching
those characters.
You've never actually run emacs, have you?
--
Robert Uhl <http://public.xdi.org/=ruhl>
The power of Satan is as nothing before the might of the Lord, so don't
go getting any ideas. --I Abyssinians 20:20
Twisted <tw********@gmail.comwrites:
>
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
Because WHEN YOU START EMACS IT DISPLAYS A MESSAGE TELLING YOU HOW TO
GET TO THE TUTORIAL. ONCE YOU'VE FOLLOWED THE TUTORIAL YOU KNOW
EVERYTHING YOU NEED TO KNOW.
If you had ever actually run emacs you'd know this.
Of course, Notepad is so easy to use it doesn't even need help,
despite which it's readily available. In case you forgot the bog-
standard (and therefore it IS self-evident) "F1" there's even a "Help"
menu in plain view as soon as you open a Notepad.
Any modern emacs comes with F1 configured to start the help system too.
Wow!
[remainder snipped, apparently describing some piece of software that
presents you automatically with an emacs tutorial if you start emacs
while it's running. I've seen emacs a few times in my day but never
whatever unnamed piece of software is being referred to here...
The message about the tutorial is displayed by a piece of software
called 'emacs.' It's the piece of software we've talking about this
entire time. It does this every time you start it. Every single time.
Without fail. Of course, if you somehow missed it, you could also go to
the menu titled, helpfully, 'Help'; the first item therein is 'Emacs
tutorial'; the second is 'Emacs tutorial (choose language).'
If you had ever actually run emacs you'd know this.
Do you think that Mercedes are awful cars because their engines don't
start when you turn the key in the ignition? Do you think homemade
burgers are disgusting because cheese doesn't melt on them?
--
Robert Uhl <http://public.xdi.org/=ruhl>
Using SWITCHAR in MS-DOS 2.0 was a kludge on top of a kludge, back in
the days before Microsoft kludge-stacking turned the OS into a game of
Jenga played with sweating dynamite sticks. --Steve VanDevender ne********@gmail.com writes:
>
So now we're expected to go on a filesystem fishing expedition instead
of just hit F1?
Interestingly enough, f1 _is_ bound to the help system in emacs. So's
C-h. So's the 'help' key.
--
Robert Uhl <http://public.xdi.org/=ruhl>
That's why I love VoIP. You don't get people phoning up to complain that the
network is down. --Peter Corlett
In article <m3************@borud.not>,
Bjorn Borud <bo********@borud.nowrote:
[Giorgos Keramidas <ke******@ceid.upatras.gr>]
|
| Educating the user to avoid confusion in this and other cases of made
| up, 'user-friendly' descriptions is not a good enough answer.
there are two types of "user friendly". there's "user friendly" and
then there is "beginner friendly" which is often mislabeled. the
latter is more important for applications which are to be used
casually. like utilities you only use once or twice per year -- those
need to be "beginner friendly".
Maybe this is an okay point at which to mention one of my favorite
bits of commentary on this subject. It's an interview with Leslie
Lamport (originator of LaTeX, among other things) in which he
talks about the needs of beginners versus the needs of experts,
and how the latter are often neglected: http://research.microsoft.com/users/...-interview.pdf
(Yes, he works (worked? but this seems current) for Microsoft.
Astonishing.)
Asked whether whether LaTeX is hard to use, he replies "It's easy
to use -- if you're one of the 2% of the population who thinks
logically and can read an instruction manual. [otherwise not]"
for applications you are likely to use for prolonged periods of time
(like programming, video editing, music production etc), it does not
make sense to optimize for "beginner friendly". at least not at the
cost of making the application less "user friendly".
applications you spend a lot of time using are worth an investment in
learning how to use them. what creates friction in an application you
know reasonably well is when common tasks are fiddly. for instance,
while menus are often good for casual use and lower the initial
threshold for absolute beginners, depending heavily on menu navigation
becomes too fiddly if you are performing a certain task 2-3 times per
minute. it is not _user_ friendly.
Sing it, brother.
(I'm a vim fan myself, but my thinking is that these days emacs
and vi(m) people should be banding together against a common enemy
rather than carrying on the fine old tradition of arguing with
each other. We have in common a preference, maybe, for learning
one editor really well and using it for everything.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Bjorn Borud <bo********@borud.nowrites:
>
for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).
Agreed. Stallman got sidetracked by Scheme, which IMHO was a dead-end.
A Common Lisp emacs would be pretty sweet. There's a Climacs project,
but they're just focused on providing an editor, not on providing a
full-fledged emacs.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Cinder blocks: $100
Mortar: $30
A cask of amontillado: $300
The faint screams of a desperate PHB: priceless. --O. Schwarz
In article <11**********************@z28g2000prd.googlegroups .com>,
Twisted <tw********@gmail.comwrote:
[ snip ]
I find these anecdotes liberally sprinkled into this thread frankly
unbelievable. Either they are not using the same software I understand
"emacs" to refer to,
I think this may be the explanation. The other people's anecdotes
seem pretty plausible to me in the context of emacs as it currently
exists. You, however, appear to be talking about -- well, I'm not
quite sure, but perhaps emacs as it existed at some earlier point
in its history? The first emacs I used (in 1980-something) didn't
have a GUI either. But the ones currently available to me do.
or someone somewhere is simply lying. Or maybe
there's a bunch of prodigies around and they all picked now to pipe
up? We can't design software or any other tool to cater exclusively to
a handful of Mozarts, though, unless there's no reason to believe
anyone outside that small and exclusive club will ever have a use for
it.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
In article <85************@lola.goethe.zz>, David Kastrup <da*@gnu.orgwrote:
ne********@gmail.com writes:
[ snip ]
It appears that you still have not bothered educating yourself, years
after you were pretty much universally derided in comp.text.tex for
making a spectacle of your self-chosen ignorance.
Ah, I *thought* this discussion was starting to sound familiar.
"This is where I came in"?
(Reverting to the original set of newsgroups on the purely selfish
grounds of not wanting to follow an additional newsgroup, comp.emacs,
in order to read any replies.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor. ne********@gmail.com writes:
>
And both of them, though especially the latter, regarding what a
feeping creature emacs is.
I like it. Every new version has great new abilities.
I don't suppose there's also a kitchen sink in there somewhere? Or is
that just nethack?
Check out nethack.el <http://www.nongnu.org/nethack-el/>. You can run
nethack within emacs. This, of course, means that there _is_ a kitchen
sink within emacs (when it's running nethack within itself)...
--
Robert Uhl <http://public.xdi.org/=ruhl>
I don't think the Java folks are nuts for what they've done. I just
don't like how hard they make certain simple and important things.
--Kent M. Pitman
On Jun 23, 10:36 am, Martin Gregorie <mar...@see.sig.for.address>
wrote:
However, there's a case he missed, probably through never using a CAD
system. All the good ones can be driven either by mouse, or by
non-chorded key sequences or any combo the user likes. The essence of
CAD is very accurate pointing but all too many mice move slightly when
clicked. Fortunately a decent CAD system offers the possibility of
purely pointing with the mouse and doing everything else with the other
hand on the keyboard. The result is both fast and extremely accurate.
Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.
An interface design point that nobody has yet mentioned here is that
there are four different types of user that map onto a grid:
casual dedicated
untrained 1 2
expert 3 4
I first ran across grid this in "Design of Man-Computer Dialogs" by
James Martin and its been very useful in systems interface design.
The problem with almost all current GUIs is that they are aimed at types
1 and 3 users - this certainly applies to Windows, OS X and Gnome
desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
at type 3 and 4 users.
The problem of course being the complete exclusion of type 1 users.
Everyone starts out as type 1, and I don't think type 2 occurs in
practise. You'd have to be some kind of religious nut to be
"dedicated" while still "untrained", rather than only as a result of
experience. Apps that provide no traction for a type 1 user will not
see much adoption except in an environment of immersion, mentoring, or
desperation. I wonder which of the three explains the majority of
emacs users, and of vi users, and whether those prove to be the same
one. :) (Actually, there'll be a single or a small number of class-2
users: the original developers, who presumably became dedicated before
having much experience *using* the tool. Their experiences are
atypical however, and their knowledge of the internals probably means
they're type 4 by the time they actually use it to do more than debug
it. Unsurprisingly, never experiencing it as a type 1 themselves they
tend to be inconsiderate of future type 1 users...this is normal, and
requires effort to avoid, in much the way blinkered views of stuff and
seeing what you want to see can be normal, and efforts like using
double-blind studies may be needed to avoid bias in evaluating, say, a
new drug. That such efforts are needed should not be seen as
disparaging the programmer or the drug-studier, but as merely
reflecting human nature, and as a simple pragmatic requirement if one
is to maximize utility.)
Its very difficult indeed to design an interface that suits both
untrained and expert users.
One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?
Funnily enough I can count the software I've seen with that range of
capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand.
Here's the list, in fact:
ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
QBasic had mouse and menu support, but an immediate mode command line.
You might not count ROM BASICS as as friendly, due to the lack of
menus and such, but then at that time in history NOTHING had menus and
such! And comprehensive introductory use manuals came with those, and
with pre-Windows PCs (DOS also had a decent and easy to navigate help
system). Most other BASICs and programming environments more generally
lack an integrated environment with an immediate mode prompt. Eclipse
actually sort of does, but the evaluate line can't be used really
arbitrarily and I've found it touchy, and rarely use it.
Hypercard (found commonly on old Macs; had a command prompt you could
access to directly communicate to an interpreter).
Fractint (fractal graphics making software for old pre-Windows PCs;
had a similar prompt, accessed by typing 'g', but also had extensive
help and menus readily controlled by stock keyboard commands such as
the arrow keys, and later a Windows port with menus and mouse
support).
Quake and descendants (yes, the games. Easy to just use the menus and
play the game. Advanced users could hit ~ to drop down a console and
do a few things. Really advanced ones made config files to rebind
weapons and make chat macros to fire off a taunting sentence with a
single keystroke -- no more embarrassment getting fragged while typing
it in longhand in mid-game. Super-advanced ones got at the QuakeC and
made bots, flag-capture mode mods, and other enhancements and
utilities. And sometimes cheats.)
There's probably some more out there, but I've yet to see such
desirable things as:
* The paint program with the usual interface, except you can also do
stuff like hit ~ and type "resample files:c:\foo\*.jpg width:640
height:480 preserveAspectRatio:true doNotEnlarge:false"
* The word processor with the usual interface, except you can also do
stuff like hit ~ and type "format leftIndent 2 where paragraph begins
'Quotation: '"
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
* The word processor with the usual interface where I can also view an
underlying markup representation and hand-hack that, and which likely
has the capabilities of the first two as a direct consequence of the
implied architecture. Only please, proper functional markup, not
macros like LaTeX or (shudder) winword. I don't want it to be possible
for documents of dubious origin to make it start sneezing, or any of
the general ugliness that follows TeX around like its shadow.
Documents that look as nice when displayed and printed, sure, but just
as nice under the hood if you please.
* Something as powerful as Mathematica, but with a more
straightforward basic-use interface as well as access to a fancy
interpreter.
* The operating system where you can do powerful stuff with a command
line and a script or two, but can also get by without either. (Windows
fails the former. Linux fails the latter.)
* For that matter, the operating system whose GUI takes the concept
behind OLE to its logical conclusion, and lets the user separately
choose and configure their text editing, this-editing, that-editing,
whosit-viewing, and the like components, and those components are used
in building more complex applications. All the alternatives would of
course adhere to a common interface for a particular sort of
component, of course. (An OO language like Java lends itself to this,
what with interfaces and inheritance and dynamic class loading!)
When I run my browser and go to GG to make a post I'd get a text entry
field that was actually my choice in a box, with the usual
capabilities such as spellchecking available, and its own little menu
bar at the top and suchlike. I'd be able to save the contents to disk
without futzing around with the clipboard and launching Notepad, and
later reload, in case the web site was prone to eating the odd
submission. My Jave IDE would display code in the same editor (the
interface should therefore support the using application externally
driving coloring/highlighting, as well as jump-to-line and similar
capabilities). Of course the editor wouldn't itself be Java-aware,
which might not be useful, for example composing a usenet post.
Instead it would provide a variety of abilities to the embedding
application, which may or may not use them. What it would provide
being its particular internal search, spell check, key bindings, etc.
About the closest I've seen have been
keyboard driven menu structures which have been designed so the user can
build their own "command sequences" that traverse menu levels without
showing the menus, as long as items are selected correctly from each
level. Many CAD systems approximate to this but I've yet to see a
graphical desktop, IDE, or editor menu structure that came close.
The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision. When I go to save a file with unsaved changes my first
inclination is ctrl+S; if the app doesn't support that the very next
thing I try is alt, f, s, before resorting to the mouse.
On Jun 23, 2:04 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Of course, emacs doesn't take years of mastery. It takes 30, 40
minutes.
I gave it twice that, and it failed to grow on me in that amount of
time.
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. 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 ... and a cramped 80x10 or so each, at that ...
Applications that not only eschew normal methods of navigation of the
interface, but force you to fumble your way between the help and the
task you're trying to do, are definitely clunky.
a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
its own thing since before there _were_ Mac OS or Windows
I'll admit that it didn't USED TO 'eschew normal methods of
navigation', but at a certain point in time there began to be 'normal
methods of navigation' and emacs naturally began eschewing them
promptly and has done so ever since.
b) I believe you've never used the emacs tutorial, which is quite
definitely designed for you _not_ to have to fumble around between
windows
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. 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, including some fairly sophisticated network-using tools,
and clearly am not an idiot or untalented in technically demanding
areas involving substantial amounts of arcana. Of course, I might have
put more effort into learning effective Java; effort like that in
learning some language is necessary to being a programmer. Thanks to
modern editors and IDEs, putting a comparable amount into learning the
mere mechanics of operating a text editor is not necessary, and I
chose to spend the time and effort elsewhere, where it was necessary,
such as on learning a programming language.
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.
The interface never improved over that time -- the biggest problem
consistently being that whenever focus was successfully transferred to
the document window, the help window was invariably open to the
instructions for switching windows, so you could never be doing
something with the document and have the help for that something
available at a glance.
That doesn't even make sense. Either your memory is faulty
Impossible
you've never actually used emacs
Untrue
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.
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). Cheat sheet? Memorized with painstaking months of hard
effort? Thanks for proving my point, either way.
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)
* Now nothing much works (typing stuff bleeps), hit esc a bunch of
times
* Now it complains of hitting esc too many times, 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. 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 scrolling>
* 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.
[snip]
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*
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.
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.
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.
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. 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 keyboard.)
You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same.
It's an "operating system" to precisely the extent Windows 3.1 was.
It's like Windows 3.1 in a number of other ways too, including size
and aesthetics, though not stability. Even more like its predecessor
DOSShell.
Take that however you wish.
At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys. Including whatever you'd use to rebind them. And the help
you'd use to find out what the damn keys are in the first place. ;)
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
usable. The human optic nerves have about 100Mbps of bandwidth *each*;
that's a couple of ethernet cables directly into the cortex. Even a
large, high resolution, big-color-gamut display with a decent refresh
rate doesn't use more than a fraction of that capacity to deliver
information to the user, even when the display is used to maximum
advantage by the software to provide state information and navigation
cues (and document views!).
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. It's a good thing some people are
apparently very good at maintaining most of the state information in
their head that that tiny little box of text isn't displaying to them,
and "reading between the lines" to make use of even fairly complex
applications through such a tiny interface. Or those replacements
might never have been built.
I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.
I'm not sure that's such an advantage. Sometimes, unifying tasks too
much creates security holes, especially when some of those tasks are
network-facing and some are not. Some proposed or actual Windows
features result in an unclear boundary between "my computer" and "the
net out there", and that's bound to result in leaked passwords and
credit-card numbers and all manner of other accidental breaches, as
well as enable a variety of new social engineering attacks to
purposely compromise more of the same. Phishing and similar attacks
already pose a problem, but if the "phishing" looks like it's local
applications or content instead of online, it's even more likely to be
mistakenly trusted.
One sometimes wonders if Microsoft has more sinister motives than "get
rich with as shoddy and cheap a product as possible" in light of
things like this. I do hope the unified stuff you describe in emacs
isn't the open source equivalent. There's frank danger in making it
too easy to mix up local stuff and online stuff while at work at a
computer.
The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing?
Define "we". It can't be "people", because a substantial fraction of
people use computers heavily for image or even 3D manipulation, or
sound, rather than text, or a mixture with text not predominant, and a
much larger fraction use computers for absolutely nothing at all.
"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.
Wouldn't it be cool not to have one program implement search in one way, and another a
second way, and yet another a third? Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?
Search is usually ctrl+f, type something, hit enter in my experience.
And I can use any text editor I want to edit HTML.
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. 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 granted. 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.
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? 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. :)
On Jun 23, 8:35 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
For an example of the latter, consider opening a file. Can't remember
the exact spelling and capitalization of the file name? Sorry, bud,
you're SOL. Go find it in some other app and memorize the name, then
return to emacs.
Once again I am forced to wonder if you have _ever_ actually used
emacs. find-file has tab completion: hit tab without anything typed, and
it displays _everything_ in the directory; type a few characters to
narrow it down; hit tab to complete the filename and be done with it.
Or of course you could use directory mode, which enables you to navigate
around a directory tree, performing actions on files (including editing
them).
Then of course there's ido.el, which is even better: type a few
characters from anywhere in the name, and it displays files matching
those characters.
Really? None of this happens if you just do the straightforward file-
open command, which should obviously at least provide a navigable
directory tree, but definitely does not. One sounds like it involves
managing a separate open window on each directory you're interested in
(versus having a file...open dialog that falls open to the last place
you'd left it and doesn't clutter up any space when you're not opening
a file); the other sounds like it involves actually installing a
plugin of some kind, which is obviously well beyond what a beginner
should need to do just to get a freaking directory listing. :) Tab
completion is a poor cousin to a real directory tree navigator, as I'm
sure most would agree. Even if it will show all matches to a partial
name instead of none, it's the textual equivalent of navigating a
directory tree made into menus instead of provided by a proper folder
view window. Windows users unfortunately have the experience
regularly: the notorious Start menu. You have to expand submenus to
find stuff, and you can't leave it idling to do something somewhere
else and come back to it because it's a menu. Moreover, clicking an
item may display a large number of items the next level down, which
runs into screen display space issues. Even a large video mode can't
hide the fact that menus weren't really designed to list hundreds of
sibling items or for scrolling or finding stuff in a large set of
files, unlike folder windows. I can only imagine the pain of trying to
navigate an equivalent way in an 80x25 box of text information. That
would be like navigating the Windows start menu from outside your
house by peeking through a keyhole and reaching through a window with
a repurposed straightened out coathanger. Clumsy AND the neighbors'll
see you and call the cops well before you find the item you're looking
for. :) (Navigating the Windows start menu in safe mode, at 640x480,
is about as close as most Windows users are ever likely to come to the
nightmare of opening a file in emacs when you don't already know its
exact path.)
On Jun 23, 11:56 am, Bjorn Borud <borud-n...@borud.nowrote:
[Twisted <twisted...@gmail.com>]
|
| That sort of negative-sum thinking is alien to me. Software being easy
| for beginners to get started using does not in and of itself detract
| from its value to expert users.
the fact that you imply that this is my argument tells me that either
you have not paid attention, or you have a raging inferiority complex.
given the sum of your postings so far I'd say that you neither are,
nor consider yourself, a cerebral sort of person, so this narrows it
down somewhat (although not to the exclusion of you not having paid
attention).
That ... makes no sense. Sorry. Previously, I said:
Being beginner-friendly doesn't have to be at the expense of power or
expert-user usability
and you said that depended on the definition of "expert". Apparently
you believe there is a type of "expert" for whom beginner-friendly
software is intrinsically less usable than beginner-hostile software.
Given that beginner-friendliness does not preclude any kind of expert
level functionality being available (consider something configurable
enough that an advanced user can start it up and open an advanced-uses
window and immediately do advanced stuff, and a real expert can make
it start up with that window already open and focused by default), it
follows that these experts' perceptions of decreased usability are a
psychological result of simply knowing beginners can easily become
proficient in using basic functions of the software in question,
rather than a material result of some compromise necessarily made in
the software's design, as there is no such compromise that can't in
practise be avoided.
An expert who feels software is less suitable for his use *purely*
because the unwashed masses can actually use it to accomplish
something is quite obviously some type of elitist jerk.
I rest my case.
Twisted <tw********@gmail.comwrites:
On Jun 23, 2:04 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
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.
Nonsense.
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
the mouse...
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
of Emacs.
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
exist.
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
unaware.
>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
easy.
hit esc a bunch of times *
The splash screen already explains that C-g is used for aborting
operations.
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
scrolling>
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.
[snip]
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.htmlon 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
keyboard.)
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
usable.
You are talking about Emacs 18, or (in a DOS box, likely) at best
Emacs 19.
[Rest of the nonsense assuming that Emacs is a terminal application
only deleted]
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
granted.
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
hinderance.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Twisted <tw********@gmail.comwrites:
On Jun 23, 8:35 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
>Twisted <twisted...@gmail.comwrites:
For an example of the latter, consider opening a file. Can't remember
the exact spelling and capitalization of the file name? Sorry, bud,
you're SOL. Go find it in some other app and memorize the name, then
return to emacs.
Once again I am forced to wonder if you have _ever_ actually used
emacs. find-file has tab completion: hit tab without anything typed, and
it displays _everything_ in the directory; type a few characters to
narrow it down; hit tab to complete the filename and be done with it.
Or of course you could use directory mode, which enables you to navigate
around a directory tree, performing actions on files (including editing
them).
Then of course there's ido.el, which is even better: type a few
characters from anywhere in the name, and it displays files matching
those characters.
Really? None of this happens if you just do the straightforward file-
open command, which should obviously at least provide a navigable
directory tree, but definitely does not.
It definitely _does_ when you are using the mouse to open your file
dialog. Again, _try_ a current version of Emacs before showing your
ignorance.
[Other nonsensical speculation deleted]
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Sun, 24 Jun 2007 04:57:20 -0000, Twisted <tw********@gmail.comtried to
confuse everyone with this message:
>On Jun 23, 2:04 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
>Of course, emacs doesn't take years of mastery. It takes 30, 40
minutes.
I gave it twice that, and it failed to grow on me in that amount of
time.
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. 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 ... and a cramped 80x10 or so each, at that ...
What an idiot. At least get yourt facts straight before posting such bullshit.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
What an idiot. At least get yourt facts straight before posting such
bullshit.
I think at this stage it's quite reasonable to assume he's trolling, and
recycling old trolls, too. Certainly looks like someone very like him
used to haunt rec.games.roguelike.development as "Neo" and "Twisted
One", in the 2005 era. Of course, by bothering to point this out, I'm
giving him more attention, the recognition he presumably craves, my
bad. http://groups.google.com/group/rec.g...0fac979ef1d117
"""
Message-ID: <D5********************@rogers.com>
Date: Tue, 22 Mar 2005 19:00:06 -0500
From: Twisted One <twisted...@gmail.invalid>
Emacs doesn't let you do that either. It lets you have exactly two
panes.
""" http://groups.google.com/group/rec.g...d723fbdc4a93f8
"""
From: David Damerell <damer...@chiark.greenend.org.uk>
Date: 23 Mar 2005 13:22:00 +0000 (GMT)
Message-ID: <4V*******@news.chiark.greenend.org.uk>
Quoting Twisted One <twisted...@gmail.invalid>
>Emacs doesn't let you do that either. It lets you have exactly two
panes.
No, this is completely false.
"""
.... So, probably deliberately trolling, or just maybe a learning
difficulty - literally (corrected on multiple occasions, still
failed to learn).
Twisted wrote:
At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys. Including whatever you'd use to rebind them. And the help
you'd use to find out what the damn keys are in the first place. ;)
You're mis-remembering this.
Apple, first with the Lisa and then with the Mackintosh, had extremely
consistent menus, menu shortcuts and other key assignments. It was
possible to teach almost anybody to use them in 15 minutes flat. A major
reason for the consistency was the Programmer's Toolbox, a piece of ROM
that contained all the stuff an application needed to handle keyboard,
mouse and menus. It was there and easy to use, so of course all
applications programmers used it.
Windows 3 and 3.1 were the first usable Windows versions. Windows 1 and
2 were a bad jokes. Win/286 worked but had no applications. Win 3.x
worked a lot better. However, it lacked any equivalent of the
Programmers Toolbox and as a result the applications were anything but
consistent. MS applications were self-similar, but other apps used
wildly divergent ideas about menu structures, shortcuts and key
assignments. Compare 3.x versions of Word with Wordperfect, or the
Borland IDEs and this is obvious.
MS finally kicked applications providers into more-or-less consistency
but that wasn't before Win 95 appeared and they then spoilt the record
by arbitrary and capricious menu changes as each version of MS Office
appeared.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Twisted wrote:
On Jun 23, 10:36 am, Martin Gregorie <mar...@see.sig.for.address>
wrote:
Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.
That might work for visual design apps, but it doesn't for CAD, where
you may want to point to an arbitrary position with a (scaled) accuracy
of microns.
The fact remains that mechanical mice do jump when you click them,
though optical mice are better in this respect.
The problem of course being the complete exclusion of type 1 users.
Totally untrue. They are the people that all the standard GUIs are
designed for and some (e.g Mackintosh) are very fast to learn. The
exclusion is down to the way that the purveyors of GUIs keep spreading
bullshit about how any untrained person can use a computer and never
mess it up or loose data. Thats not true and never can be: a computer is
the most complex device the average person will own or use and is likely
to retain that title for the foreseeable future.
I grant you that type 2 users are rare, but I think flight simulators
may fit this case when used for training.
One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?
Not really. What's needed is a single interface that can be used by
anybody from beginner to expert and that, in the case of an error, shows
precisely where it got, what caused the action to fail to complete and
that allows the user to continue from that point without having to
undo/redo the bits that were successful. Its not easy, but it can be done.
ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
Hang on: you don't read manuals. You object to using tutorials and to
buying books, so its a bit precious to claim this example.
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
Thats been in Word since DOS days and is part of OpenOffice. Its called
a "style sheet". The only WPs I've used that didn't use them were
Wordperfect, WordStar, DEC WPS+ and the Wang dedicated WP systems. All
were horrid to varying degrees, with Wordperfect and Wordstar tying for
worst.
* The word processor with the usual interface where I can also view an
underlying markup representation and hand-hack that,
You're thinking of Wordperfect and its 'Reveal Codes' function. That was
the worst idea I've ever seen in a WP, matched only by the illogically
arranged set of 12 function keys, each with 4 shifts.
and which likely has the capabilities of the first two as a direct
consequence of the implied architecture.
It didn't. 'Reveal codes' could only let you inspect the current
document. Unfortunately it was essential to use it because some input
sequences could completely mess up the formatting and the only way to
recover was via 'Reveal codes'. The effect was similar to making a data
entry clerk use a hex editor on a database to fix keyboarding errors.
NOTE: I'm not talking about secretaries using WordPerfect. Those that
used it hated it. I'm talking about the experience of IT professionals
writing structured text, e.g. system specifications.
* The operating system where you can do powerful stuff with a command
line and a script or two, but can also get by without either. (Windows
fails the former. Linux fails the latter.)
Here you're talking about two different interfaces again. The nearest
I've seen to good solutions at OS level were the CL interface provided
by ICL's VME mainframes and IBM's AS/400 systems. The latter was
particularly good, with a single unified text screen interface which
provided help screens, menus and a command line. You could search for
and find commands via a menu structure, and then use form filling to
provide the arguments, with help available at any stage. If you were
writing a script the entire menu and form filling system was available
from within the text editor - but when you hit ENTER the completed
command was written into your script instead of being executed.
Both OS/400 and VME were very consistent in the way they assigned
command names and argument keywords. In both OSen it was possible to
think "if there's a command to do this it will be called BLAHBLAH", type
the name, hit the command completion key and have the argument entry
screen pop up ready to be filled in.
BTW, in both OSen this capability applied to user-written scripts and
programs as well as to the standard command set. Both could claim to be
object oriented: the VME command language was derived from Algol-68,
arguably the granddaddy of all OO programming languages.
* For that matter, the operating system whose GUI takes the concept
behind OLE to its logical conclusion, and lets the user separately
choose and configure their text editing, this-editing, that-editing,
whosit-viewing,
The AS/400 editor did exactly that. There was only one, but it swapped
personality to match the task and was language-aware as well as
application aware. It produced form-filling interfaces to help you write
command scripts. If you were writing a program it gave language-specific
prompts and could run syntax checks on each statement as it was entered.
If you didn't want any of that, it would just quietly accept input like
any other text editor.
The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision.
No they don't: you can't easily string them together to act as a single
command and the error diagnosis and reporting is remarkably poor. Same
goes for Gnome, so I'm not particularly bashing Windows here.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
David Kastrup <da*@gnu.orgwrites:
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.
Actually, already Emacs 18, at least 18.55, supported X11. Although
I'll concede that the support was not very integrated, and didn't
offer a menu-bar or a scroll-bar, as far as I can remember, and I
think you could only have one frame open, not several.
*Dowloads emacs-18.59.tar.gz* According to the NEWS file, X11 was
supported from 18.50, but it appears that X10 was supported even
somewhat earlier.
There was also 'emacstool' for the SunView windowing system, but I
never used emacstool, so I don't know much about what it offered.
--
Thomas Bellman, Lysator Computer Club, Linkping University, Sweden
"God is real, but Jesus is an integer." ! bellman @ lysator.liu.se
! Make Love -- Nicht Wahr!
David Golden <da**********@oceanfree.netwrote: http://groups.google.com/group/rec.g...d723fbdc4a93f8
"""
From: David Damerell <damer...@chiark.greenend.org.uk>
Date: 23 Mar 2005 13:22:00 +0000 (GMT)
Message-ID: <4V*******@news.chiark.greenend.org.uk>
Quoting Twisted One <twisted...@gmail.invalid>
>Emacs doesn't let you do that either. It lets you have exactly two
panes.
No, this is completely false.
"""
I seem to recall that EMACS, the old TECO version on TOPS-20 and
ITS, only supported two windows ("panes" in Twisted's words). So
it's not *completely* false, just extremely outdated.
--
Thomas Bellman, Lysator Computer Club, Linkping University, Sweden
"Adde parvum parvo magnus acervus erit" ! bellman @ lysator.liu.se
(From The Mythical Man-Month) ! Make Love -- Nicht Wahr!
Thomas Bellman wrote:
I seem to recall that EMACS, the old TECO version on TOPS-20 and
ITS, only supported two windows ("panes" in Twisted's words). So
it's not *completely* false, just extremely outdated.
Well, that's going back a bit. I somehow doubt he was using that, but I
guess it's possible (he did claim emacs is a "unix" text editor
though)...
On Jun 24, 8:10 am, Martin Gregorie <mar...@see.sig.for.address>
wrote:
Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.
That might work for visual design apps, but it doesn't for CAD, where
you may want to point to an arbitrary position with a (scaled) accuracy
of microns.
I didn't mention that you should be able to zoom and make the grid
fine to whatever limit is reasonable given the application? The issue
being, how accurate is "accurate enough"? Pinpoint precision isn't
possible, unless it's an integer or a functionally derived value like
pi or some arithmetic result of that. Grids are good for getting
rational numbers exactly, and nothing will hit the irrational ones
exactly, save if you can enter a formula for it to use to compute the
point's location to any desired precision. A mouse click (sans grid)
will always introduce some error; the zoom level lets you limit the
magnitude of the error. So does a grid, and to zero if the desired
point is a grid vertex, and to half the grid size more generally.
The fact remains that mechanical mice do jump when you click them,
though optical mice are better in this respect.
Ultimately, the button has to be non-mechanical for this sort of thing
to really work. Or else not physically part of the mouse. Being able
to "click" from the keyboard makes sense given such requirements. So
does being able to snap to a grid.
The problem of course being the complete exclusion of type 1 users.
Totally untrue.
I'm not talking about in general. I'm talking about the specific sorts
of unixy applications that are under discussion here. Those
emphatically cater solely to type-3s and type-4s, aside from newer
graphical apps for KDE and Gnome, which are emerging as a third group
of type-1-accessible tool alongside Mac applications and Windows
applications.
Thats not true and never can be: a computer is
the most complex device the average person will own or use and is likely
to retain that title for the foreseeable future.
What about the fabrication devices? Oh, but I suppose the "foreseeable
future" has already ended by the time those trickle down to widespread
consumer use.
I grant you that type 2 users are rare, but I think flight simulators
may fit this case when used for training.
Anything you have to use to meet some important external goal, I
suppose. But most usually there are options. A programmer needs a text
editor but it need not be emacs. Jobs requiring the use of specific
software (for training, or just on the job) maybe, of which your
example is a subset.
Not really. What's needed is a single interface that can be used by
anybody from beginner to expert and that, in the case of an error, shows
precisely where it got, what caused the action to fail to complete and
that allows the user to continue from that point without having to
undo/redo the bits that were successful. Its not easy, but it can be done.
Why do those who have the skills, talent, knowledge, and thus
capability to do this insist on making cruft like emacs then? I've
never seen a classic-unix tool that didn't barf unhelpful and
uninformative error messages at the drop of a hat (just like Windows!)
and present a piss-poor UI, or even no UI at all (unless "usage: blah
blah blah" qualifies as a UI, to which my response is one word. "Non-
interactive.") When the error messages are informative, they're still
cryptic, and only someone with knowledge of the software's internals
has a hope in hell of fixing the problem as a rule. Of course, the
number one rule of interface design is to speak the user's language
and the language of the problem domain, and remain mute (except to
developers invoking debug modes) about the implementation details and
the language of the solution domain. Especially given that a different
version of the same software, nevermind a different app with the same
usage, is probably going to use a different implementation anyway. One
exception can be to expose a specific scripting language for advanced
users to use to automate tasks. Emacs does this, and it's one thing I
don't have a problem with. As long as knowledge of its arcana is not
needed to either do straightforward stuff, or fix the errors that
occur attempting to do straightforward stuff, anyway. If the beginner
can safely ignore the thing's existence (e.g. the VB-based scripting
language in some office and paint programs) it's fine.
ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
Hang on: you don't read manuals. You object to using tutorials and to
buying books, so its a bit precious to claim this example.
The manuals came with the computers, at no additional charge. It was a
different time. This isn't going to be true of any separately-
purchased book or user-made printout concerning emacs. Also, the
manuals provided a basic introduction for the beginning user. A
traditional-unix-tool providing anything resembling that would
genuinely shock me.
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
Thats been in Word since DOS days and is part of OpenOffice. Its called
a "style sheet".
I distinctly remember Winword circa 2002 not being able to
retroactively change all of a bunch of like-formatted paragraphs
easily. Not without delving into VBscript or something, anyway.
You're thinking of Wordperfect and its 'Reveal Codes' function. That was
the worst idea I've ever seen in a WP, matched only by the illogically
arranged set of 12 function keys, each with 4 shifts.
Why?
It didn't. 'Reveal codes' could only let you inspect the current
document. Unfortunately it was essential to use it because some input
sequences could completely mess up the formatting and the only way to
recover was via 'Reveal codes'. The effect was similar to making a data
entry clerk use a hex editor on a database to fix keyboarding errors.
Oh, because the implementation (of "reveal codes" and of everything
else) was awful, not because of any intrinsic flaw in the idea itself.
Would you want to edit a Web page without being able to hand-hack the
HTML? Use a GUI builder for Swing without being able to hand-hack the
Java? Thought not.
[Snip description of an advanced-for-its-time interface]
What happened to the guys that did all this stuff after it became
obsolete? Microsoft offer them $300 grand a year to mop floors or sit
in on various board meetings without a vote or something to get them
out of the way, being unable to use their talents competently and
equally unable to stand having them work for a competitor, or worse,
contribute to open source? Or offer a mob type $100 grand once to
whack them maybe?
The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision.
No they don't: you can't easily string them together to act as a single
command and the error diagnosis and reporting is remarkably poor. Same
goes for Gnome, so I'm not particularly bashing Windows here.
You can string them together manually, or use a keyboard macro
recording and playback tool (they exist, though one doesn't come
standard with Windows; I think maybe one does with MacOS). It would be
nice if straightforward macro recording was standard in Windows
though.
On the other hand, I've not always been 100% sure of that sort of
thing. Even seemingly straightforward search-and-replace can suffer
from Sorceror's Apprentice Syndrome even at the best of times. And if
the thing treats every individual replace as a separate undoable
action instead of the one batch-of-replaces, and has a buffer of only
10 undos, and 13 items match, and one of them was unexpected and
shouldn't have been replaced...
Macro capabilities might be a dream, but macros running amok are a
nightmare. Maybe a real programmability would be better. I think the
scripting language capabilities in some apps provide that, with more
ability to control and constrain it from going into Sorceror's
Apprentice mode, but every app tends to have its own scripting
language and API and no real introduction-to-scripting type stuff,
leading us back to "the emacs problem" -- an arcane interface that
begins and ends in midair, with nowhere for the beginning user to
climb aboard, and differing from application to application so
limiting the value of investing much time in any one of them versus if
a single universal one were used (say Lua, or even elisp, or even
*gag* VB...)
Hi Twisted,
>>>>"Twisted" == Twisted <tw********@gmail.comwrites:
Twisted* The operating system where you can do powerful stuff with a command
Twistedline and a script or two, but can also get by without either. (Windows
Twistedfails the former. Linux fails the latter.)
Twisted* For that matter, the operating system whose GUI takes the concept
Twistedbehind OLE to its logical conclusion, and lets the user separately
Twistedchoose and configure their text editing, this-editing, that-editing,
Twistedwhosit-viewing, and the like components, and those components are used
Twistedin building more complex applications. All the alternatives would of
Twistedcourse adhere to a common interface for a particular sort of
Twistedcomponent, of course. (An OO language like Java lends itself to this,
Twistedwhat with interfaces and inheritance and dynamic
Twistedclass loading!)
Have a look at Genera, the OS of the Lisp Machines. It offers all
that and much more. Unfortunately it is almost non existent
nowadays.
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
Twisted <tw********@gmail.comwrites:
On Jun 23, 8:35 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
>Twisted <twisted...@gmail.comwrites:
For an example of the latter, consider opening a file. Can't remember
the exact spelling and capitalization of the file name? Sorry, bud,
you're SOL. Go find it in some other app and memorize the name, then
return to emacs.
Once again I am forced to wonder if you have _ever_ actually used
emacs. find-file has tab completion: hit tab without anything typed, and
it displays _everything_ in the directory; type a few characters to
narrow it down; hit tab to complete the filename and be done with it.
Or of course you could use directory mode, which enables you to navigate
around a directory tree, performing actions on files (including editing
them).
Then of course there's ido.el, which is even better: type a few
characters from anywhere in the name, and it displays files matching
those characters.
Really? None of this happens if you just do the straightforward file-
open command, which should obviously at least provide a navigable
directory tree, but definitely does not.
The first does. Really, it does. Fire up emacs (which you've never
done before) and type C-x C-f. You will be presented with a prompt
something like 'Find file: ~/'; hit tab once; you'll see the message
'[Complete, but not unique]'; hit tab again and you will be presented a
list of all files in that directory.
Tab completion is a poor cousin to a real directory tree navigator, as
I'm sure most would agree.
I wouldn't. There are several directory navigators installed on this
machine, but I never use anything more than bash's tab completion.
If you like 'em, though, just select File:Visit New File. It gives you
a platform-default (gtk+, for me) file selector.
Even if it will show all matches to a partial name instead of none,
it's the textual equivalent of navigating a directory tree made into
menus instead of provided by a proper folder view window. Windows
users unfortunately have the experience regularly: the notorious Start
menu. You have to expand submenus to find stuff, and you can't leave
it idling to do something somewhere else and come back to it because
it's a menu.
Nope, because of the way emacs works you can stop what you're doing, do
something else and come back to the minibuffer. As an example, while I
was typing the first paragraph, I had find-file running in the
minibuffer (I was checking for the exact prompts and phrases used).
I can only imagine the pain of trying to navigate an equivalent way in
an 80x25 box of text information.
Fortunately, folks brighter than you & I have imagined a nice way for
us. It pops up a new Emacs window (pane, if you prefer the terminology)
showing a list of all filenames. You could continue typing, or just
click on a filename in the window, or hit return while the cursor is on
a filename in that window.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Dilbert: Not more than ten minutes ago you beat a man senseless.
Alice: He was senseless before I beat him.
On 25 Jun., 00:52, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
You guys are all in the wrong newsgroups. Please stay in comp.emacs
when discussing Emacs. Don't cross post.
Not everyone is interested in Emacs discussions.
Thanks.
Follow-up set to comp.emacs.
Twisted <tw********@gmail.comwrites:
>
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
... and a cramped 80x10 or so each, at that ...
I have two frames open right now: one 80x70, the other around 180x70
(characters, not pixels). One isn't split at all; the other is split
into four windows, horizontally and vertically.
I'll admit that it didn't USED TO 'eschew normal methods of
navigation', but at a certain point in time there began to be 'normal
methods of navigation' and emacs naturally began eschewing them
promptly and has done so ever since.
emacs has continued doing its own thing, mostly because that thing is
better. The CUA standards (there exists an emacs package if you really
want them) are broken and lame--I and most other don't wish to cripple
our text editor of choice.
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.
When you start emacs in a text console, you see this:
Welcome to GNU Emacs, one component of the GNU/Linux operating system.
Type C-l to begin editing.
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r
Emacs tutorial C-h t Undo changes C-x u
Buy manuals C-h C-m Exit Emacs C-x C-c
Browse manuals C-h i
Activate menubar F10 or ESC ` or M-`
(`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
If you have no Meta key, you may instead type ESC followed by the character.)
A GUI window shows a similar message. Note the 'Emacs tutorial' entry?
Or you could just go to the Help menu, then select 'Emacs Tutorial.'
>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).
Clicking within the document's window isn't obvious?!?
* OK, time to resort to *gulp* the help.
* Oh, great, now what did it do? I hit F1 and ...
* Eh. Try random stuff. 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.
Ha! f1 and C-h do the exact same thing. You've obviously not used emacs
this millennium.
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.
No, we're discussing emacs, a text editor which runs in both a GUI and a
text console. Which can display images. It's cool like that.
At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys.
Neither is right nor wrong; you're just used to one. The emacs keys are
certainly more flexible and powerful, though. Some might consider them
right for that reason.
>Wouldn't it be cool not to have one program implement search in one
way, and another a second way, and yet another a third? Wouldn't it
be cool to have access to a proper text editor when editing text on a
web page?
Search is usually ctrl+f, type something, hit enter in my experience.
Unless you want regexp search. And if you want to find again it can be
interesting. And maybe the program defaults to case-sensitive or
case-insensitive search...
And I can use any text editor I want to edit HTML.
You could use Notepad no doubt; you could also use a Turing machine. I
prefer to use a useful tool.
>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).
No, as I've said over and over and over again, emacs is not what you
think it is. It has a GUI; it has colours; it can display images; it
can use the native widget set. It can even be configured to use native
keybindings, although that way lies madness.
Some sort of bastardized Windows port I suppose?
Hah! Dude, I don't use Windows--I've better things to do with my life.
--
Robert Uhl <http://public.xdi.org/=ruhl>
With weapons, we are citizens. Without them, we are subjects.
On Jun 24, 6:52 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Really? None of [navigating a folder window analogue] happens if
you just do the straightforward file-open command, which should
obviously at least provide a navigable directory tree, but
definitely does not.
The first does. Really, it does. Fire up emacs (which you've never
done before) and type C-x C-f.
Whoa, Nellie. I seem to recall we were discussing the file-open
command.
That was something else, like C-x C-o or something. More apples-and-
oranges?
You will be presented with a prompt
something like 'Find file: ~/'; hit tab once; you'll see the message
'[Complete, but not unique]'; hit tab again and you will be presented a
list of all files in that directory.
Sounds clunky anyway. I don't need a bunch of keypresses to do the
equivalent in an Explorer-based file-open dialog in a native Windows
app. Just a double-click.
Emacs, with your C-x C-f:
C-x C-f tab tab ("Startofnameofdirectory somethingElse
otherstuff")
Startofname tab tab ("Subdirectory anotherSubdirectory")
Subd tab tab
Windows:
Alt, f, o ("Startofnameofdirectory somethingElse
otherstuff")
Click-click
or Startofname-down-enter ("Subdirectory anotherSubdirectory")
Click-click
or Subd-down-enter
Worst case (all keyboard): one fewer keypress. Best case (judicious
use of the mouse and smart hand placement, one by left alt and one on
the mouse): five TOTAL gestures.
In particular, C-x C-f tab tab is replaced by alt f o (four down to
three keypresses) or click file, click open (two instead of three
inputs, but you have to locate the File menu from halfway across the
screen with the pointer, so count it as three as well).
Being able to pick an item from a list just by touching the damn thing
instead of typing in a sufficiently long prefix is definitely an
advantage, and if a lot of things share the same 16-character prefix
in a particular directory, the emacs way starts to look SLOW.
Of course, there's an even faster Windows way, if you don't mind not
seeing lists of possible items:
Alt, f, o
Startofname-down-/-Subd-down-/
Straight to the subdirectory without waiting for it to display the
parent directory or the root. Same number of inputs. And of course
there's the super-fast
Alt, f, o, C-v, enter
if you happen to have the exact path in the clipboard already. I'd
like to see emacs do that, at least if the text to paste originated
outside emacs. (If I'm doing this in Winword's file open dialog it
could have originated in Notepad, Firefox, or just about anywhere
else, not just Winword.)
If you like 'em, though, just select File:Visit New File. It gives you
a platform-default (gtk+, for me) file selector.
Now we're talking about a graphical port instead of stock emacs
again. :P
Nope, because of the way emacs works you can stop what you're doing, do
something else and come back to the minibuffer.
After spending a while brushing up on my Tibetan, I may or may not
agree, but until I've got some real meaning out of your use of jargon
like "minibuffer", I'll have to pass on this one. Nonetheless, stuff
you can do but can't know you can do without learning Tibetan is
unlikely to be of much help to the average user. :)
Fortunately, folks brighter than you & I have imagined a nice way for
us. It pops up a new Emacs window (pane, if you prefer the terminology)
showing a list of all filenames. You could continue typing, or just
click on a filename in the window, or hit return while the cursor is on
a filename in that window.
Back to discussing a graphical port again. Besides the apples and
oranges issue, this amounts to implementing a dodgy imitation of a
file open dialog anyway. Why bother with such an imitation when you
can use a natively-GUI editor written for your platform and get access
to the real thing?
On Jun 24, 7:19 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
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
... and a cramped 80x10 or so each, at that ...
I have two frames open right now: one 80x70, the other around 180x70
(characters, not pixels). One isn't split at all; the other is split
into four windows, horizontally and vertically.
Then you're obviously not using the One True Emacs I am criticizing,
which is a console app. If we're not talking about the same piece of
software (and the one the fanatics evangelize about) then this is
pointless.
emacs has continued doing its own thing, mostly because that thing is
better. The CUA standards (there exists an emacs package if you really
want them) are broken and lame--I and most other don't wish to cripple
our text editor of choice.
"CUA standards"? I'm sorry, I don't speak Botswanan. If you mean
Windows standards like for cut, copy, and paste, "broken and lame" is
obviously in the eye in the beholder, and something 97% of computer
users are used to is the defacto standard, so it's the other 3% that
are "broken and lame". ;)
When you start emacs in a text console, you see this:
Welcome to GNU Emacs, one component of the GNU/Linux operating system.
Type C-l to begin editing.
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r
Emacs tutorial C-h t Undo changes C-x u
Really? That is not what I recall seeing. Are you talking about emacs-
the-text-mode-editor, or emacs-the-hybrid-somethingorother-when-you-
happen-to-run-it-from-the-command-prompt-on-unix? Because I've been
discussing the former.
Buy manuals C-h C-m
How crass.
First I've seen anything open source/"free" software that makes sales
pitches at you. Mostly I've only seen that with closed-source Windows
"free"ware loaded with adware, and with shareware that nags you to
register or otherwise spend money with its author. And with actual
paid products, particularly those from Intuit which act as Intuit's
front-line salesmen by trying to constantly upsell you and sell stuff
to your friends and relatives. Er, thanks but no thanks. (I don't
personally spend a dime on any Intuit products. I unfortunately know
people who do. One version of some accounting software of theirs even
spammed all of a user's email contacts, by God. Where are those
Russian spammer-targeting hitmen when you need them?)
Activate menubar F10 or ESC ` or M-`
Definitely not the stock text-mode emacs I've had my runins with in
the past, but some kind of hybrid or offshoot, then.
Clicking within the document's window isn't obvious?!?
Clicking within the document's window is obvious but doesn't work,
unless you're using something other than vanilla emacs at least. It
did of course work in MS-DOS Edit, later versions.
No, we're discussing emacs, a text editor which runs in both a GUI and a
text console. Which can display images. It's cool like that.
No, we're discussing ... oh, nevermind. It looks like there are
several utterly different pieces of software that have one thing in
common - the name "emacs". Anyone can dodge or seem to rebut a
criticism of one of them by describing how another of them isn't like
that. :P
At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys.
Neither is right nor wrong; you're just used to one. The emacs keys are
certainly more flexible and powerful, though. Some might consider them
right for that reason.
The Windows keys are familiar to 97% of the population. Some might
consider them right for that reason.
This is also a change from your earlier position that they were, and I
quote, "broken and lame", assuming you mean the same stock Windoze
keybindings you meant with the cryptic term "CUA standards".
Search is usually ctrl+f, type something, hit enter in my experience.
Unless you want regexp search. And if you want to find again it can be
interesting.
I rarely want regexp search, and if I want it I can use Notetab, a
notepad replacement with tabbed MDI and yes, regexp search. A few tabs
and a space keypress to turn it on after ctrl+f.
As for "find again" hitting enter additional times is the usual
method, in Notetab, Notepad, and elsewhere.
And I can use any text editor I want to edit HTML.
You could use Notepad no doubt; you could also use a Turing machine. I
prefer to use a useful tool.
Painting it as a choice between Notepad and emacs is the fallacy of
false dichotomy. There's Notetab (useful, but non-free) and lots of
(sometimes free) other text editors (for Windows and for other
platforms).
Some specialize in HTML editing the way Eclipse's built-in editor
specializes in Java editing (and with plugins, can be made to
specialize in, say, C instead).
No, as I've said over and over and over again, emacs is not what you
think it is. It has a GUI; it has colours; it can display images; it
can use the native widget set. It can even be configured to use native
keybindings, although that way lies madness.
One thing I agree on regarding emacs is the phrase "that way lies
madness". I'm amending that belief to include participating in Usenet
discussions about emacs, as well as actually trying to use emacs.
Given that everyone seems to mean a distinct piece of software by the
term "emacs" it's a wonder anything coherent can be said about "emacs"
at all. Actually, the one constant to emerge in all of this is C-h
being associated with accessing the help in all of these various
emacses. And we all know that that results in backspace doing
surprising things for a text editor. :P
Hah! Dude, I don't use Windows--I've better things to do with my life.
Xemacs then, or whatever they're calling the bolted-on-an-X-GUI-and-
the-rivet-job-shows-from-1000-paces version these days. This thread has been closed and replies have been disabled. Please start a new discussion. |
