effective emacs
xah...@gmail.com
(Long term emacs productivity tips.)
Xah Lee, 2008-05-29
I have used emacs daily since 1998. Typically, i spent several hours
inside emacs, everyday, for the past 10 years.
Here are 6 general emacs tips i felt that's the most important in
emacs productivity, among all other emacs tips and tricks of my decade-
long experience. If you use emacs only occasionally, these tips may
not be very meaningful because they are general and does not solve any
specific problems. If you have used emacs over a year, or is a
dedicated emacs user, you might find these tips helpful.
perm url: http://xahlee.org/emacs/effective_emacs.html
following is a text version. (table formatting are screwed, no images,
no links)
-------------------------------------------------
UNDERSTAND THE IMPORTANCE OF EMACS'S COMMANDS
In emacs, every keystroke is bound to a command (practically
speaking). For example, when you type a key “e”, emacs actually runs
the command self-insert-command. In other words, any key or key
combination or key sequence you press is bound to a command. There are
about 3000 commands in emacs. Most commonly used commands have a
keyboard shortcut. For example, moving the cursor, opening file, copy
paste, close a file, search text. To execute a command in emacs, type
“Alt+x” followed by the command name.
The following will let you execute any command, or cancel it.
Command Name | Shortcut | Purpose
execute-extended-command | Alt+x | Execute a given command
keyboard-quit | Ctrl+g | cancel any key sequence or command in
progress
The following will let you find out any command's name of a given
shortcut, or a shortcut of a given command name.
Command Name | Shortcut | Purpose
describe-key | Ctrl+h k | find out what command is associated with
a shortcut
describe-function | Ctrl+h f | find out what shortcut is bound to
a function, and what the function do
The following will let you find out any features or shortcuts of a
mode, and any command that you forgot the name.
Command Name | Shortcut | Purpose
describe-mode | Ctrl+h m | read the inline doc of the current
mode. For example, find out what features and shortcuts it provides.
apropos-command | Ctrl+h a | list all commands who's name contains
a given string.
Any operation in emacs is ultimately a command, and most of them are
bound by a keyboard shortcut. By mastering the above commands, you
will become self-sufficient.
Emacs provides a lot more other helping commands. For example, looking
up variable, searching emacs manual, launching the emacs manual,
searching commands with a given option, launching the emacs FAQ,
launching emacs tutorial...etc, but the above i relied on for my first
5 years of using emacs, and still is most useful among all the help
commands.
-------------------------------------------------
MASTER WINDOW SPLITTING
Use split-window-vertically extensively, and give it a easy shortcut,
such as “Alt+2” for spliting into 2 top and bottom panes, “Alt+1” to
expand the pane the cursor is on, “Alt+0” to get rid of the current
pane, and “Alt+o” for moving cursor to the next pane.
;;; WINDOW SPLITING
(global-set-key (kbd "M-2") 'split-window-vertically) ; was digit-
argument
(global-set-key (kbd "M-1") 'delete-other-windows) ; was digit-
argument
(global-set-key (kbd "M-0") 'delete-window) ; was digit-argument
(global-set-key (kbd "M-o") 'other-window) ; was prefix
In emacs, the window is split into panes frequently. It may be split
by a shell-command's output, by various emacs grep command (e.g. list-
matching-lines, grep-find), by emacs's various diff commands, by
viewing man page (“Alt+x manual-entry”), by list-buffers, by viewing
inline help (e.g. describe-function), by calc or calendar, or by lisp
error messages. In many of the split pane situation, you can type “q”
to exit the pane, but not always. And, some of the split panes put
your cursor in the pane, but not all.
By mastering the above 4 generic window splitting commands, with easy-
to-press shortcuts, you'll save a lot time opening or closing split
panes. Also, by having a easy shortcut, now you can split and unsplit
panes whenever you want and frequently. For example, i constantly have
one pane showing dired and another pane showing a file content, or one
pane of shell. A Top-Bottom-split window is extremely useful when
coding. (for example, when i need to edit part of a file based on the
current location, i often do a split pane first, then use isearch-
forward to the location and edit, while viewing the original
position.)
-------------------------------------------------
MASTER DIRED
In coding, almost every hour you need to look at different files or
directories, or do copying, deleting, renaming files or directories.
Emacs provides a file management mode, called “dired”. (“dired” is
acronym for DIRectory EDit. “Directory Editing” is 1980's term for
file management.)
Dired is very useful. Once you master it, you will almost never use a
graphical desktop. The only time i need to switch to OS's graphical
desktop is when dealing with special files such as video, sound,
images, etc. (Since emacs now can view images files too, so i almost
don't go to desktop for image files now.) Also, emacs use the same
interface of dired for ftp/sftp. So, for example, you can copy, move,
delete, change file owner/perm, or edit files on remote servers.
For details about dired, see File Management with Emacs.
Also, in combination of dired, you should master the command “shell-
command” (Alt+!) and “shell”. (For more detail about using shell
commands, see Emacs and Unix Tips).
-------------------------------------------------
REMAP MOST FREQUENTLY USED SHORTCUTS
The cursor moving commands are the most frequently used shortcuts. You
use them every few seconds.
Emacs's default cursor moving shortcuts are “Ctrl+f”, “Ctrl+b”, “Ctrl
+n”, “Ctrl+p”. The keys f, b, n, p are scattered around the keyboard
and are not under the home row. Also, Control key is typed by the weak
pinky finger. The Meta key (the Alt under thumb) is much easier to
type. So, remap keys so that Alt with a home-row key moves the cursor.
;; make cursor movement keys under right hand's home-row.
(global-set-key (kbd "M-j") 'backward-char) ; was indent-new-comment-
line
(global-set-key (kbd "M-l") 'forward-char) ; was downcase-word
(global-set-key (kbd "M-i") 'previous-line) ; was tab-to-tab-stop
(global-set-key (kbd "M-k") 'next-line) ; was kill-sentence
(global-set-key (kbd "M-SPC") 'set-mark-command) ; was just-one-space
(global-set-key (kbd "M-a") execute-extended-command) ; was backward-
sentence
For more extensive remapping, see: A Ergonomic Keyboard Shortcut
Layout For Emacs.
-------------------------------------------------
MASTER EMACS REGEX AND FIND-REPLACE COMMANDS
Searching text and find-replace text is tremendously useful. I use it
just about every hour. (Many find-replace commands has a regex
version) The following are the most useful search or find-replace
commands:
Command Name | Shortcut | Target | Description
isearch-forward | “Ctrl+s” | cursor point to end (cycles back to
file beginning) | interactive search
query-replace | “Alt+%” | region, or cursor point to end |
interactive find and replace
query-replace-regexp | “Ctrl+Alt+%” | region, or cusor point to
end | interactive find and replace with regex pattern
dired-do-query-replace-regexp | In dired, “Q” | multiple files |
interactive find and replace with regex pattern on multiple files
For detail about using these commands, in particular, how to control
whether the search is case-sensitive, or whether the replacement is
case-sensitive, see: Find and Replace with Emacs.
Many emacs find-replace commands uses a regex. Emacs has many other
commands that uses regex. For example, list-matching-lines, delete-
matching-lines, highlight-regexp, grep-find, dired-do-rename-regexp.
Mastering emacs regex will be a good investment. Also, you should know
how to enter TAB or Return character in emacs regex. (“\t” or “\n”
does not work) For a short tutorial on most important tips of emacs's
regex, see: Text Pattern Matching in Emacs.
-------------------------------------------------
GET A GOOD KEYBOARD
You switch to different applications all day. Web browsers, emacs,
terminal, Desktop, music player, image editor, ...etc. Their usage and
interface changes, but there is one thing that does not change: Your
keyboard.
Your keyboard is a intimate item. You touch it every minute. Emacs in
particular, use modifier keys extensively. This may sound silly, but a
good keyboard is one of the most important thing in productivity with
emacs.
A good keyboard for emacs, should be one with large Alt and Control
keys, and they should be available on both sides (one set for each
hand, just like Shift key), and the right side's set should be
positioned symmetrically (that is, the distance from your left index
finger to the left Alt, should be the same to the distance from your
right hand's index finger to the right Alt).
BAD
above: The Apple keyboard as of 2006. Note the ridiculous distance of
the right side's modifier keys. It is not possible, to use the right
thumb to press the alt key while the index finger remains on the J.
GOOD
Microsoft Natural Multimedia keyboard
above: The Microsoft Natural Multimedia keyboard. Note, the keys are
split and oriented for each hand. And, the Ctrl, Alt are very large
and symmetrically positioned with respect to each hand's thumb. (See A
Review of Microsoft Natural Keyboards)
Doesn't matter whether you like ergonomic keyboards, you should take a
closer look at your keyboard, and see if it works with emacs well.
Also, it's good to develop good habits when pressing the Control key.
You should avoid pressing it with pinky, and should learn using
alternate hand for Control-key combination, like you would with Shift
key. For detail, see: How To Avoid The Emacs Pinky Problem.
-------------------------------------------------
STEVE YEGGE'S EFFECTIVE EMACS
This article is inspired by Steve Yegge's Effective Emacs:
http://steve.yegge.googlepages.com/effective-emacs. I like to thank
Steve for his article.
However, I disagree with some of his tips strongly. In particular, his
tips about Swapping Cap-lock and Control key, Invoking M-x without the
Alt key, the “Lose the UI”. In the following, i give a brief
explanation why i disagree.
Swapping Cap-lock and Control is not a good solution because it puts
all the burden on the left pinky. The Control key on most PC keyboard
is at the corner, and is very easy to press with palm. Also, there are
2 Control keys, on both sides. One should use them both like how Shift
key is used, by using one hand for the modifier key and the other hand
for the letter key. Alternating hands ease the repetitive burden, and
avoids the awkward pinky-stretch. Swapping Cap-lock and Control can be
a good solution on laptop keyboards. I think better is to actually
swap Control and Alt. For detail, see How To Avoid The Emacs Pinky
Problem and Why Emacs's Keyboard Shortcuts Are Painful.
Related to the above, i don't find the advice of “Invoking M-x without
the Alt key”, by remapping to a Control key combination, a very good
one. Personally, i remap M-x to M-a, since the “a” key is in the home
row, and Meta (the Alt key under thumb) is easier to press then
Control.
Steve advices users to “Lose the UI”. In general, i also work in emacs
exclusively using keyboards. My emacs career, from 1998 to 2004
inclusive, are exclusive with text-terminals only (thru telnet/ssh on
remote servers). Only after 2004, i started to use emacs in a
graphical setting, under Mac OS X. I think graphical user interface is
very helpful, because it gives a listing of the most useful commands,
and can serve as a reminder or cheat-sheet. For example, i've been
using dired for over 10 years. Some of dired features i hardly ever
use. For example, looking at the dired “Operate” menu, i see that i've
actually never used the shortcuts S, H, B, L, T, C-t D, C-t a, C-t t,
C-t r. Under its “Mark” menu, i never used “* /”, “.”, “* *”, “M-{”,
“M-}”. Similarly, there are many commands i've never used, or aware,
that are listed under its Regexp, Immediate, Subdir menus. Maybe i've
been missing out something, but emacs has 3000+ commands and lots of
modes. Few people need to master all features. But occasionally, i can
browse the graphical menu and find out the command that i kept
forgetting to use, or see what most important commands are available
for a new mode i just installed. I think graphical menus are quite
useful in this aspect. Losing them doesn't save much screen space. I
would agree that tool bar (the one with icons for opening file, copy/
cut/paste, printing, help) is not much useful.
--------------------------------
Feedback welcome.
Another item i should add, is about using list-buffers or the buffers
mode. Actually, ibuffers, which i've been using in place of the
default since emacs 22.
Xah
x...@xahlee.org
∑ http://xahlee.org/
☄
Daniel Weinreb
> Effective Emacs
>
> (Long term emacs productivity tips.)
>
> Xah Lee, 2008-05-29
>
> I have used emacs daily since 1998. Typically, i spent several hours
> inside emacs, everyday, for the past 10 years.
Same for me, except the year is 1977. Nobody has been using Emacs
longer than I have (I was one of the original beta-testers. I refer
here to the original Emacs, written in ITS TECO for the DEC 10.)
>
> Emacs's default cursor moving shortcuts are “Ctrl+f”, “Ctrl+b”, “Ctrl
> +n”, “Ctrl+p”. The keys f, b, n, p are scattered around the keyboard
> and are not under the home row.
That's true. At the time Guy Steele put together the Emacs default
key mappings, many people in the target user community (about 20
people at MIT!) were already using these key bindings. It would
have been hard to get the new Emacs bindings accepted by the
community if they differed for such basic commands. As you point
out, anyone using Emacs can very easily change this based on
their own ergonomic preferences.
>
> GOOD
> Microsoft Natural Multimedia keyboard
Let me put in a quick plug for my own favorite keyboard, which
I am using right now: the Unicomp Customizer:
http://pckeyboards.stores.yahoo.net/customizer.html
I like the feel of the keys very much. I agree with you
that it's important, and worth some effort, for everyone
to find a keyboard that they feel most comfortable with.
> Problem and Why Emacs's Keyboard Shortcuts Are Painful.
I generally make few customizations to the key bindings, so
that when I work with another programmer, I can turn the
keyboard over to them and not cause confusion.
>
> Steve advices users to “Lose the UI”.
I rarely use the menu bar. On the other hand, I was raised on an
Emacs that didn't have a menu bar, so I could be atypical. Using
the mouse to set point or set the region is great, though, and I
use that a lot.
Here's another piece of historical trivia. The Emacs keyboard
macro feature was inspired by a similar feature in the Stanford
DRAW system, an electrical CAD system widely-used by the AI lab
hardware hackers at the time. It was very powerful. But if you
made a mistake, it could really destroy your design, and so it
was a good idea to save to disk before running it. We had a saying
for what happened if you forgot to save: "A moment of convenience,
a lifetime of regret." This predates the widespread use of "Undo"
functionality, surely one of the best ideas for user interfaces
ever invented.
-- Dan
Jason Gulledge (ramdac@ramdac.org)
> Let me put in a quick plug for my own favorite keyboard, which
> I am using right now: the Unicomp Customizer:
>
> http://pckeyboards.stores.yahoo.net/customizer.html
but does it have N-key rollover?
- Jason Gulledge
Nerd...@gmail.com
> Same for me, except the year is 1977. Nobody has been using Emacs
Stupid coincidence: I was born Jun 1, 1977, though not at 8:35am. I
also live in Emacs, but I had to start out with MicroEmacs (me.ttp) on
an Atari ST. If only I could have spent my formative years in Emacs
instead of Paperclip...
Mike.
xah...@gmail.com
«Effective Emacs
perm url: http://xahlee.org/emacs/effective_emacs.html
Another item i should add, is about using list-buffers or the buffers
mode. Actually, ibuffers, which i've been using in place of the
default since emacs 22.»
I have just now wrote the master buffer section.
Here's a text version of the added section:
-----------------------------
Master Buffer Switching
In emacs, every file is represented in a “buffer”. The term “buffer”
means a temp area of storage in computer science. From a application
user's perspective, it might be better to think of it as tabs, as the
tabs in browsers, or IDEs, which basically means a single window is
used to represent several different files or work area, but only one
is shown.
A typical emacs user will have tens of buffers in a session. Master
how to manipulate buffers will benefit you greatly.
Here's the classic commands related to buffers:
Command Shortcut Purpose
next-buffer Ctrl+x Ctrl+→ switch to next buffer
previous-buffer Ctrl+x Ctrl+← switch to previous buffer
list-buffers Ctrl+x Ctrl+b show all buffers
switch-to-buffer Ctrl+x b switch to a specific buffer
In emacs 22 (released in 2007), there's a new mode called ibuffer.
(start it by “Alt+x ibuffer”) “ibuffers” is a major improvement of the
classic “Buffer menu” mode. It includes color-differentiated buffer
listing, and few more powerful regex commands that manipulate buffers
in batch. I've been using ibuffers since about 2006 with emacs beta,
and found it completely replace the “Buffer Menu” mode used by list-
buffers.
emacs ibuffer
above: A screenshot of ibuffer mode.
In ibuffer mode, those purple are emacs's buffers, those blue are
dired, those red with a “>” in front are marked buffers. You can do
operation in batch to the marked ones, such as save all unsaved files,
close all files of a given dir, close all Java files, etc. The concept
and shortcuts are pretty much the same as in dired. Move your cursor
to a file name and press “RET” to switch to it. To mark a buffer,
press “m”. To close a buffer, press “D”. There are over ten commands
for marking; you can have a look at the graphical menu “View” and
“Mark”, once you are in ibuffer mode.
emacs ibuffer mark
above: Emacs's ibuffer mode's “Mark” menu.
Here's the ibuffer commands i use frequently:
Shortcut | Purpose
*u | Mark unsaved buffer.
S | Save marked buffer.
D | Close marked buffers.
** | Unmark all.
%m | Mark by mode name (e.g. all html files, all java files)
%f | Mark by file path (e.g. all files in a dir)
You might want to give ibuffer a easy-to-type shortcut. Since it
completely replaces the functionality of list-buffers command, you
might alias it to ibuffers.
(defalias 'list-buffers 'ibuffer)
Emacs often generates a lot internal buffers that users are not
interested in cycling thru. For example: *scratch*, *Messages*,
*shell*, *Shell Command Output*, *Occur*, *Completions*, *Apropos*,
*info*, etc. You might define your own next-user-buffer and previous-
user-buffer that skips emacs's buffers, and you might define next-
emacs-buffer, previous-emacs-buffer that cycles thru just the emacs's
buffers. Here's the code: modern_operations.el.
Also, the default shortcut for next-buffer (Ctrl+x Ctrl+→) involves
multiple keystrokes, you might define a single-key shortcut for it.
Here's some example code:
;; sample easy shortcuts
(global-set-key (kbd "<f5>") 'find-file) ; Open file
(global-set-key (kbd "<f6>") 'ibuffer) ; list buffers
(global-set-key (kbd "<f7>") 'previous-user-buffer)
(global-set-key (kbd "<f8>") 'next-user-buffer)
(global-set-key (kbd "S-<f7>") 'previous-emacs-buffer) ; Shift+f7
(global-set-key (kbd "S-<f8>") 'next-emacs-buffer) ; Shift+f8
(global-set-key (kbd "<f9>") 'kill-this-buffer) ; Close file
------------------
Xah
x...@xahlee.org
∑ http://xahlee.org/
☄
Xah Lee
Thanks for the historical perspective. Very informative.
Daniel Weinreb wrote:
> Let me put in a quick plug for my own favorite keyboard, which
> I am using right now: the Unicomp Customizer:
>
> http://pckeyboards.stores.yahoo.net/customizer.html
By my good fortune, i happened to have used famous IBM Model M
keyboard
http://en.wikipedia.org/wiki/Model_M_keyboard
for maybe a year, back in about 1991, that came with IBM PS/2
computer.
( http://en.wikipedia.org/wiki/IBM_Personal_System/2 )
I'd love to still use this keyboard today except since 2005 i've
adopted the split ergonomic keyboard. It's hard to go back now.
It's good to know the current reincarnation of the keyboard thought...
good for recommending to friends who don't like split ones...
(am a keyboard nerd)
Xah
∑ http://xahlee.org/
☄
On Jun 1, 5:35 am, Daniel Weinreb <d...@alum.mit.edu> wrote:
> xah...@gmail.com wrote:
> > Effective Emacs
>
> > (Long term emacs productivity tips.)
>
> >XahLee, 2008-05-29
Mikael Jansson
> [snip]
>
> Let me put in a quick plug for my own favorite keyboard, which
> I am using right now: the Unicomp Customizer:
>
> http://pckeyboards.stores.yahoo.net/customizer.html
>
> I like the feel of the keys very much. I agree with you
> that it's important, and worth some effort, for everyone
> to find a keyboard that they feel most comfortable with.
>
ordered. I've been using the Logitech UltraX lately, which has the
nicest feel so far, but they wear out rather quickly.
How is the durability of the Customizer, and does it click?
--
Mikael Jansson
http://mikael.jansson.be
Raymond Wiker
The Customizer is a descendant of the IBM Model M, which is
commonly regarded as one of the greatest keyboards, ever. It is rated
at something like 10 or 20 million keypresses (for each key), and has
all the clickiness you could reasonably ask for (it actually clicks
twice for each keypress :-)
I have 4 of thse keyboards (the 105-key, USB version - two
started life with a PS/2 interface, which I replaced with new
controller boards that i boughyt from Unicomp later).
The only thing I'm slightly unhappy with, is that Unicompdoes
not have alternative keycaps for the "Windows" keys :-)
Joseph Brenner
Daniel Weinreb <d...@alum.mit.edu> writes:
> I rarely use the menu bar. On the other hand, I was raised on an
> Emacs that didn't have a menu bar, so I could be atypical.
I don't know about atypical. Much of the emacs-user base is older
users. Kids these days don't see the point.
Myself, I shut-off the menu bar, along with the scrollbars and, of
course the drool-bar.
John Thingstad
<do...@kzsu.stanford.edu>:
Yeah at school we had a joke GNU EMACS stood for Generally Not Used Except
by Middle Aged Computer Scientists.
I turn off toolbars and scroll bars too. But I leave the menu bar on,
mostly for mode spesific menues.
--------------
John Thingstad
Andreas Eder
>>>>> "Joseph" == Joseph Brenner <do...@kzsu.stanford.edu> writes:
Joseph> I don't know about atypical. Much of the emacs-user base is older
Joseph> users. Kids these days don't see the point.
But seeing the point is easy -- it is the mark that is not always visible.
'Andreas
also an old-time user of emacs.
--
ceterum censeo redmondinem esse delendam.
Mark Hood
> Daniel Weinreb <d...@alum.mit.edu> writes:
>
> > I rarely use the menu bar. On the other hand, I was raised on an
> > Emacs that didn't have a menu bar, so I could be atypical.
>
> I don't know about atypical. Much of the emacs-user base is older
> users. Kids these days don't see the point.
I think it's more about how you use Emacs than how old you are.
The menu bar is sometimes convenient, but it really slows things down
when you're running Emacs as an X client tunneling through ssh on a
DSL line to a remote server. (Actually, in those conditions you
really need to build Emacs with the old X toolkit instead of the
extremely heavyweight GTK).
And the menu bar is just silly when you need to run Emacs on a
terminal console while debugging a window system, or if your only
access is through a terminal emulator like Putty.
I always disable the menu bar so I can keep my .emacs simpler across
the diverse environments I develop from. It's just better to learn to
do without it.
-- Mark
xah...@gmail.com
as for personal preference, i myself have the menu bar on because it
lists the most useful commands of new modes you are not familiar with.
i have the scroll bar on because scroll bar gives a visual clue of the
size of file and where you are. It contains more info than the line
number e.g. “L14” in the modeline, and conveys the info faster, and
more intuitively.
I have the Tool Bar turned off, because it is not useful for people
already familiar with emacs, or those who doesn't need to use mouse to
do copy/pasting, opening files, saving files, etc.
Xah
∑ http://xahlee.org/
☄
Joost Diepenmaat
> Joseph Brenner <do...@kzsu.stanford.edu> writes:
>
>> Daniel Weinreb <d...@alum.mit.edu> writes:
>>
>> > I rarely use the menu bar. On the other hand, I was raised on an
>> > Emacs that didn't have a menu bar, so I could be atypical.
>>
>> I don't know about atypical. Much of the emacs-user base is older
>> users. Kids these days don't see the point.
>
> I think it's more about how you use Emacs than how old you are.
>
> The menu bar is sometimes convenient, but it really slows things down
> when you're running Emacs as an X client tunneling through ssh on a
> DSL line to a remote server. (Actually, in those conditions you
> really need to build Emacs with the old X toolkit instead of the
> extremely heavyweight GTK).
Actually, in those circumstances, I just run emacs in the terminal
(i.e. emacs -nw) and use M-x tmm-menubar (or F10, or M-`) to get the
menu in terminal mode if I have to.
> I always disable the menu bar so I can keep my .emacs simpler across
> the diverse environments I develop from. It's just better to learn to
> do without it.
The most important reason I have the menu bar enabled in my GUI
environments, is that it makes it easy to find new and possibly
interesting commands. Once I find a useful commands, I make a point of
remembering the key commands. But for very rare commands, or as a way to
browse the options, the menu bar is very useful.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
David Kastrup
> I have the Tool Bar turned off, because it is not useful for people
> already familiar with emacs, or those who doesn't need to use mouse to
> do copy/pasting, opening files, saving files, etc.
cut/copy/paste with the mouse works perfectly well in Emacs without
reverting to any bar or the keyboard.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
xah...@gmail.com
but someone modified the newsgroup followup to comp.emacs only while
himself post to both. I wasn't aware of that and fell into the trap.
The follow is a post i'm reposting to comp.lang.lisp)
On Oct 9, 2:02 am, Tassilo Horn <tass...@member.fsf.org> wrote:
> IMO switching off the menu bar has nothing to do with "geekness", but
> indeed has the benefit of giving you two or three more lines of usable
> space. Especially on these modern wide-screen notebook displays that's
> a not so small benefit.
>
> But I agree with you that for exploring new modes the menu bar is a nice
> helper. But most emacs users don't use new modes on a daily basis and
> once you know the most important keystrokes, there's no use for the menu
> bar anymore. And if you need it only once, `M-`' is a very nice
> alternative.
>
> > Try to publish a book on these thoughts of UI, and see how stupid you
> > are considered the world.
>
> There are other (not-so-geeky) applications where you can turn off the
> menu bar, too, so it seems that there's a group of users demanding this
> feature. For example in all KDE apps that's possible and in a terminal
> or a browser, there's seldomly a need for using the menu bar. If an
> application makes the most useful commands accessible with an alternate
> quicker method, why persist on using the menu bar?
just a quick reply...
There's nothing i don't agree with you here. It's the implications in
previous post and most posts from tech geekers that are
problematic ...
the tech geeker don't understand much about society and critical
thinking... so in their online discussions, wild balls of drivel flys
back and forth unchecked.
In the past few months, i've participated in maybe 5 or so hundreds-
post sized threads on emacs UI in gnu.emacs.help. So, i'm taking a
break from another UI flamefeast. However, i've culled most of my
writings into more quality essays, and these have been published on my
website. So, if you are interested my opinions of UI, or my views
about how or why of tech geekers, see:
Emacs modernization related:
• Modernization of Emacs (suggestion on items emacs should adapt)
http://xahlee.org/emacs/modernization.html
• Suggestions on Emacs's Scratch Buffer
http://xahlee.org/emacs/modernization_scratch_buffer.html
• Emacs's M-‹key› Notation vs Alt+‹key› Notation
http://xahlee.org/emacs/modernization_meta_key.html
• Usability Problems With Emacs's Letter-Case Commands
http://xahlee.org/emacs/modernization_upcase-word.html
• Emacs Should Support HTML Mail
http://xahlee.org/emacs/modernization_html_mail.html
• Why Emacs's Keyboard Shortcuts Are Painful
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
at the bottom of many of these contains a link that points to the
hundreds post threads on the respective topic. So, if you are so
inclined, you can read them.
Xah
∑ http://xahlee.org/
☄
xah...@gmail.com
but someone modified the newsgroup followup to comp.emacs only while
himself post to both. I wasn't aware of that and fell into the trap.
See: Cross-posting & Language Factions
http://xahlee.org/Netiquette_dir/cross-post.html
)
On Oct 7, 5:09 pm, Mark Hood <inva...@invalid.invalid> wrote:
These are the most moronic thoughts typical of tech geekers. These
thoughts has little to do with any reality. They are expressions of
“I'm geeker than thou.”. These types of expressions are most typical
on tech geeker mecca such as newsgroups and slashdot. Try to publish
a book on these thoughts of UI, and see how stupid you are considered
the world.
Xah
∑ http://xahlee.org/
☄
Javier
wonderful and helpful.
Joost Diepenmaat
> I don't understand why people do hate Xah Lee, his postings are just
> wonderful and helpful.
He's on my ignore list. I don't hate him, he's just incredibly insulting
quite a lot of the time.
Apart from that I don't think that his general ideas are sound - he
appears to think that if things don't work exactly as they on whatever
operating systems / program he's used, that means it's bad. Which may be
a good starting point, but it takes a willingness to examine the
reasoning behind the choices in context; otherwise you're just
trolling. There are multitudes of (IMHO mostly good, some historical,
and a few bad) reasons emacs isn't like notepad, for example.
namekuseijin
> There are multitudes of (IMHO mostly good, some historical,
> and a few bad) reasons emacs isn't like notepad, for example.
Yes, the main one being that the CTRL+C, CTRL+V ease of usage is only
achieved when you have so freaking few functionality available.
Notepad is immediately accessible, but it's only helpful for small,
simple tasks. Notepad and its cc,cv paradigm don't scale well to more
complex, larger editing tasks, where you can see the benefit of
macros, quick jumps through the text and back, autocomplete, templated
text insertion, last edits buffer etc. And when you need much more
functionality at your fingertips, you need far too many keyboard
shortcuts.
It could certainly get better, like automatic keyboard shortcut
switching to current editing context.
Raymond Wiker
> I don't understand why people do hate Xah Lee, his postings are just
> wonderful and helpful.
For starters, you could ignore anything he says about Common
Lisp and Emacs Lisp - he's hardly an expert on either, is frequently
wrong, and the code he posts is often non-idomatic, sub-optimal and/or
plain inelegant.
For the rest of his posts on c.l.l and c.e, he can be ignored
as he is just wildly off-topic.
He's been in my kill-file for 10 years or so. Occasionally, I
check one of his post to see if there is anything that is worth
reading, but I haven't found anything, yet.
Paul Donnelly
What do you mean by that? Something other than associating modes with
buffers and file types, I gather.
namekuseijin
> namekuseijin <namekusei...@gmail.com> writes:
> > It could certainly get better, like automatic keyboard shortcut
> > switching to current editing context.
>
> What do you mean by that? Something other than associating modes with
> buffers and file types, I gather.
I'd mean something like "lexical scoped" keyboard shortcuts, if such a
thing would be possible.
It should work by automatically associating new meaning to
conventional keyboard shortcuts when entering a new mode and
restauring them when leaving and so on as you narrow more deeply
within inner modes. That way, no more complex 4-5 keycombos for
specific commands each time you enter a new mode. I'm thinking about
that complex sgml-mode requiring virtuoso pianists rather than
programmers. Shouldn't such a mode simply be easier to allow for CTRL
+f/b to mean "next/previous xml element", CTRL+u "up to the parent of
current node" and so on?
Of course, next question is: what if the user simply wants to move to
the next char? CTRL+f doesn't allow that anymore in this mode.
That's a tough decision, but I'd say if he wants normal editing
capabilities rather than xml editing capabilities, the logical answer
would be to break out of the xml mode and enter standard mode and back
and forth anytime he wants. I know, that begins to sound a bit like
vi. But to me it sounds a lot better than having anti-ergonomic
features just for the sake of history. Of course, such mode switching
should be as painless as possible, possibly using a single meta-
keycombo not possible of over-shadowing in any modes.
Daniel said EMACS would never gain traction among its original
audience were it not for it using familiar keycombos already standard
among users. This is the 2000's and familiar keycombos to most users
do not generally include regular alphabetic keys or sequences of 3 or
more chained keys.
I've come to somewhat appreciate Xah's take on the subject of
modernization of Emacs. It's either this or let it die once the
original 70s/80s users are dead. I believe Emacs needs to provide
standard familiar keybindings to nowadays users and a retro-
compatibility keybinding mode.
The "lexical scoped" keybinding switching mechanism described above
could also improve things for mode authors who should not worry
anymore with inventing new complex keybindings being careful not to
overwrite any important ones. Just use standard familiar keybindings
and let the user freely switch in and out between more specific inner
modes or more generic outer modes.
I hope some knowledgeable emacs coders hear it and at least give it
some thought.
William James
> ... the code he posts is often ...
> plain inelegant.
Like this?
> (defparameter *test-list*
> (make-list 1000 :initial-element "foo"))
>
> (defun join (list delimiter)
> (with-output-to-string (ret)
> (loop for (elt . next) on list
> do (progn (write-string elt ret)
> (when next
> (write-string delimiter ret))))))
>
> CL-USER> (time (progn (join *test-list* ":") (values)))
> Evaluation took:
> 0.002 seconds of real time
> 0.0 seconds of user run time
> 0.001376 seconds of system run
Is elegance possible when using Cobol Lisp?
Ruby:
require "benchmark"
test_list = Array.new(1000){'foo'}
Benchmark.bm{|x| x.report { test_list.join( ":" ) }}
user system total real
0.000000 0.000000 0.000000 ( 0.000000)
Javier
Anyway I don't actually understand the reason of having a killfile.
There is not an immense amount of traffic on c.l.l such as a filter is
needed...
And trolls are funny, too... just take in count, in my opinnion, some
brilliant posts here are responses to some flamewar or any other topic
routinely used by some or another troll.
Paul Donnelly
> On 14 out, 20:14, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>> namekuseijin <namekusei...@gmail.com> writes:
>> > It could certainly get better, like automatic keyboard shortcut
>> > switching to current editing context.
>>
>> What do you mean by that? Something other than associating modes with
>> buffers and file types, I gather.
>
> I'd mean something like "lexical scoped" keyboard shortcuts, if such a
> thing would be possible.
>
> It should work by automatically associating new meaning to
> conventional keyboard shortcuts when entering a new mode and
> restauring them when leaving and so on as you narrow more deeply
> within inner modes. That way, no more complex 4-5 keycombos for
> specific commands each time you enter a new mode. I'm thinking about
> that complex sgml-mode requiring virtuoso pianists rather than
> programmers. Shouldn't such a mode simply be easier to allow for CTRL
> +f/b to mean "next/previous xml element", CTRL+u "up to the parent of
> current node" and so on?
Isn't that pretty much how modes work? The designer of sgml-mode may not
have *chosen* those keys (and the M-f, b, p keys might be better
choices), but they could have.
> Of course, next question is: what if the user simply wants to move to
> the next char? CTRL+f doesn't allow that anymore in this mode.
> That's a tough decision, but I'd say if he wants normal editing
> capabilities rather than xml editing capabilities, the logical answer
> would be to break out of the xml mode and enter standard mode and back
> and forth anytime he wants. I know, that begins to sound a bit like
> vi. But to me it sounds a lot better than having anti-ergonomic
> features just for the sake of history. Of course, such mode switching
> should be as painless as possible, possibly using a single meta-
> keycombo not possible of over-shadowing in any modes.
>
> Daniel said EMACS would never gain traction among its original
> audience were it not for it using familiar keycombos already standard
> among users. This is the 2000's and familiar keycombos to most users
> do not generally include regular alphabetic keys or sequences of 3 or
> more chained keys.
>
> I've come to somewhat appreciate Xah's take on the subject of
> modernization of Emacs. It's either this or let it die once the
> original 70s/80s users are dead. I believe Emacs needs to provide
> standard familiar keybindings to nowadays users and a retro-
> compatibility keybinding mode.
Do you think Emacs is losing new users faster than it gains them? I'm
not so sure, but I do think it's time for Emacs to "die", phoenixlike. A
program like Emacs only makes sense when the environment outside of it
is so limited that it's easier to write applications inside a freaking
*text editor* than to write stand-alone apps. Back in the days of text
mode, when you didn't get windowing and stuff from the OS for free,
Emacs was a good move. But I think now that everybody gets graphics,
gets a mouse, gets windows from the WM, the time is ripe for Emacs to be
reinvented as something a little more UNIX and a little less GNU. Time
to reconsider what really needs to be in a programmable text editor,
what could be better implemented with a more specific program (a
structured editor for Lisp or SGML), and what should be something
entirely different (a newsreader, a spreadsheet).
Emacs, today, could be a better fit for the modern desktop if it dropped
the idea of managing its own windows, dropped most of the hotkeys
entirely, made M-x commands more approachable, dropped the idea that
every window was filled with text, and adopted the assumption that many
kinds of programs would be written in it. In other words, Emacs recast
as the desktop environment for people who appreciate visual minimalism,
consistency, and Lisp scripting (and the elisp dialect could really be
dropped in favor of CL).
Of course I realize it's a big job and probably will never happen unless
I do it myself in a fit of superhuman effort, but it's my position that
the specifics of keyboard shortcuts are the least of its problems
considering current users are used to them by now, and that it would not
be a bad thing if Emacs were allowed to "sunset", leaving room for an
entirely modern -macs.
Pascal J. Bourguignon
> Do you think Emacs is losing new users faster than it gains them? I'm
> not so sure, but I do think it's time for Emacs to "die", phoenixlike. A
> program like Emacs only makes sense when the environment outside of it
> is so limited that it's easier to write applications inside a freaking
> *text editor* than to write stand-alone apps. Back in the days of text
> mode, when you didn't get windowing and stuff from the OS for free,
> Emacs was a good move. But I think now that everybody gets graphics,
> gets a mouse, gets windows from the WM, the time is ripe for Emacs to be
> reinvented as something a little more UNIX and a little less GNU. Time
> to reconsider what really needs to be in a programmable text editor,
> what could be better implemented with a more specific program (a
> structured editor for Lisp or SGML), and what should be something
> entirely different (a newsreader, a spreadsheet).
End users cannot (usually) modify and program their GUI applications.
With a window manager such as StumpWM, end users can reprogram their
window managing code (at run-time), but still not the code of their
applications. Anyways, this stays theorical, SumpWM is a X window
manager, nothing like that is available on MacOSX or MS-Windows.
Therefore, users still need to use their favorite emacs editor to be
able to program/modify their "applications" and tools.
When Firefox will be modifiable at runtime in Common Lisp, then
perhaps we may be able to throw away emacs and w3...
> Emacs, today, could be a better fit for the modern desktop if it dropped
> the idea of managing its own windows, dropped most of the hotkeys
> entirely, made M-x commands more approachable, dropped the idea that
> every window was filled with text, and adopted the assumption that many
> kinds of programs would be written in it. In other words, Emacs recast
> as the desktop environment for people who appreciate visual minimalism,
> consistency, and Lisp scripting (and the elisp dialect could really be
> dropped in favor of CL).
The only OS/GUI where you would want to do that, apart from McCLIM, is
Oberon. There are a lot less Oberon installations than emacs ones.
--
__Pascal Bourguignon__
David Kastrup
> Do you think Emacs is losing new users faster than it gains them?
That's not actually possible. Before you lose a new user, you have to
gain her. So the number of lost new users will always be at most the
number of gained new users. The question is rather whether it is losing
old users faster than it gains new ones.
And that's not really pertinent to a project dying: it is the number of
developers. And if you take a look at XEmacs (which I consider pretty
much a dead project), my impression is that nobody uses it anymore. But
that does not keep the occasional new blood from appearing among the
developers. Fewer than old ones fading out, admittedly, but developers
are not really fazed by trends as easily as users.
> I'm not so sure, but I do think it's time for Emacs to "die",
> phoenixlike. A program like Emacs only makes sense when the
> environment outside of it is so limited that it's easier to write
> applications inside a freaking *text editor* than to write stand-alone
> apps.
Which is pretty much the reason why Emacs makes perfect sense. You have
just the APIs and functions to get the job done.
> Back in the days of text mode, when you didn't get windowing and stuff
> from the OS for free, Emacs was a good move.
But you don't get it for free. Far from it.
> But I think now that everybody gets graphics, gets a mouse, gets
> windows from the WM, the time is ripe for Emacs to be reinvented as
> something a little more UNIX and a little less GNU.
UNIX does not even _have_ graphics. You are thinking of X11. But naked
X11 is not something anybody uses anymore. They use things like GNOME,
and guess what, the G in GNOME stands for GNU. And indeed, Emacs offers
a perfectly working GNOME/Gtk+ look.
> Time to reconsider what really needs to be in a programmable text
> editor, what could be better implemented with a more specific program
> (a structured editor for Lisp or SGML), and what should be something
> entirely different (a newsreader, a spreadsheet).
Text is text.
> Emacs, today, could be a better fit for the modern desktop if it
> dropped the idea of managing its own windows, dropped most of the
> hotkeys entirely, made M-x commands more approachable, dropped the
> idea that every window was filled with text, and adopted the
> assumption that many kinds of programs would be written in it. In
> other words, Emacs recast as the desktop environment for people who
> appreciate visual minimalism, consistency, and Lisp scripting (and the
> elisp dialect could really be dropped in favor of CL).
>
> Of course I realize it's a big job and probably will never happen
> unless I do it myself in a fit of superhuman effort,
It rather sounds like you should get and install a modern version of
Emacs compiled for Gtk+. You are preaching to the choir, a choir that
has not only already seen the light but actually nailed it down long
ago. Ok, I get carried away on my analogies.
Ted Zlatanov
n> Yes, the main one being that the CTRL+C, CTRL+V ease of usage is only
n> achieved when you have so freaking few functionality available.
n> Notepad is immediately accessible, but it's only helpful for small,
n> simple tasks. Notepad and its cc,cv paradigm don't scale well to
n> more complex, larger editing tasks, where you can see the benefit of
n> macros, quick jumps through the text and back, autocomplete,
n> templated text insertion, last edits buffer etc. And when you need
n> much more functionality at your fingertips, you need far too many
n> keyboard shortcuts.
The benefit of CUA is in the standartization of the shortcuts, not in
their number or particular key strokes. Every application supports the
same ones. This is why I always use CUA mode in Emacs: I don't have to
remember to use different keys every time I switch editors. This
includes Ctrl-Left/Right/Up/Down, adding Shift to motion to select, etc.
n> It could certainly get better, like automatic keyboard shortcut
n> switching to current editing context.
Have you considered MuMaMo? I don't use it, but it allows mixing of
major modes in a buffer:
http://www.emacswiki.org/cgi-bin/wiki/MuMaMo
Ted
namekuseijin
Funky! Now please show us the implementation of join.
> user system total real
> 0.000000 0.000000 0.000000 ( 0.000000)
Nice troll. Specially comparing joining array and list elements on
different hardware. The pp also didn't compile join.
xah...@gmail.com
> Paul Donnelly <paul-donne...@sbcglobal.net> writes:
> > Do you think Emacs is losing new users faster than it gains them?
>
> That's not actually possible. Before you lose a new user, you have to
> gain her. So the number of lost new users will always be at most the
> number of gained new users. The question is rather whether it is losing
> old users faster than it gains new ones.
LOL. That's very silly. “losing new users” is perfectly sensible. It
means you don't gain users.
You try to pick the sentence with logic and came up with you own
phrasing. For example, you say: “The question is rather whether it is
losing old users faster than it gains new ones.” To pick a bone, you
are not likely to lose old users unless they die, and these old users
die very slowly. The “lose” part happens mostly when you don't gain
users.
But in anycase, either phrasing gets the idea across. But tech geekers
always nickpick and have no sense of the overall picture.
> And that's not really pertinent to a project dying: it is the number of
> developers. And if you take a look at XEmacs (which I consider pretty
> much a dead project), my impression is that nobody uses it anymore. But
> that does not keep the occasional new blood from appearing among the
> developers. Fewer than old ones fading out, admittedly, but developers
> are not really fazed by trends as easily as users.
Bad bad critical thinking skill here.
The number of users to a project is more critical than the number of
developers, with respect to the project's livelihood. Typically you
have users first, then they become developers. A project with lots
developers but little users will just die.
> UNIX does not even _have_ graphics. You are thinking of X11.
when i hear tech geekers talk, i find them quite stupid. When in
argument about unix usability, the fanatics will say unix support
graphics. But when in arguments about flaws of unix's components, they
say unix is just a kernel or such, so that file system problems is not
unix flaw, x11 problem is not unix flaw, shell stupidities is not unix
flaw, etc and so on, such that unix is so poweful that you can just
put in another component.
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
O, hello David!
Btw, David, come to Second Life. I've created a emacs group there.
(there's also a lisp group) We can have a voice debate party with tea
and biscuits. :D My name there is Xah Toll.
Xah
∑ http://xahlee.org/
☄
namekuseijin
> On Tue, 14 Oct 2008 14:03:14 -0700 (PDT) namekuseijin <namekusei...@gmail.com> wrote:
>
> n> Yes, the main one being that the CTRL+C, CTRL+V ease of usage is only
> n> achieved when you have so freaking few functionality available.
> n> Notepad is immediately accessible, but it's only helpful for small,
> n> simple tasks. Notepad and its cc,cv paradigm don't scale well to
> n> more complex, larger editing tasks, where you can see the benefit of
> n> macros, quick jumps through the text and back, autocomplete,
> n> templated text insertion, last edits buffer etc. And when you need
> n> much more functionality at your fingertips, you need far too many
> n> keyboard shortcuts.
>
> The benefit of CUA is in the standartization of the shortcuts, not in
> their number or particular key strokes. Every application supports the
> same ones. This is why I always use CUA mode in Emacs: I don't have to
> remember to use different keys every time I switch editors. This
> includes Ctrl-Left/Right/Up/Down, adding Shift to motion to select, etc.
Yes, but CUA mode only standardize on the poor choices available for
notepad and the likes, where you only have, for instance, motions for
char, word, line and page. Emacs (and most other advanced text
editors) allow for moving by sentences and paragraphs/blocks as well.
What are the CUA shortcuts for that?
Besides, my point is that, say, an xml mode could use CTRL+Left to go
to the next xml element rather than to the next word of plain text.
And if the user wants to go to the next word, just break out of xml
mode towards outer general text mode then gets back as they please,
and so forth.
> http://www.emacswiki.org/cgi-bin/wiki/MuMaMo
I'll take a look.
xah...@gmail.com
> "xah...@gmail.com" <xah...@gmail.com> writes:
> > I have the Tool Bar turned off, because it is not useful for people
> > already familiar with emacs, or those who doesn't need to use mouse to
> > do copy/pasting, opening files, saving files, etc.
>
> cut/copy/paste with the mouse works perfectly well in Emacs without
> reverting to any bar or the keyboard.
Thank you for the extra tip, i assume you meant it so others can
benefit. But let me add it too, that the cut/paste operation using
mouse in emacs is actually more convenient than standard UI. In
standard UI (used by Windows, Mac OS X, Linux), you hold down left
button and move mouse to select region, then right click to pop up a
contextual menu, then select Copy/Cut/Paste. In emacs, moving the
mouse to select is not necessary, nor moving the mouse to choose a
menu of copy/cut/paste. All these are done by simply clicking. You
click on the beginning position, then right click on the end position,
then right click to cut the region or middle click to paste it. (am
not sure if it can just do copy though, but of course one can cut then
paste right away to have the same effect)
btw, i didn't know or use this mouse copy/paste until only this year.
i started using emacs daily in 1998. From 1998 to 2005, i'm a Xemacs
user. Also, i use emacs exclusively in terminal in these years. I
don't even use the text-based menu. Typically i turn it off as the
first thing.
From about 2006 on, i started to use emacs in GUI. The primary impetus
that made me switch to GUI is because Mac is my main machine at home
and since about 2001 when OS X came out, its Terminal app does not let
one set the Cmd key as Meta. (still not possible today), and Meta at
Cmd position is important to me. The ohter reason is that i started to
need unicode for math symbols and Chinese. This is why i started to
look for solutions ... (xemacs does not have good unicode support out
of the box at the time (prob still not now) and unicode in Terminal is
sparsely supported at least in early 2000s)
The solution is either one of the pre-built GUI emacs for the mac
(there were several at the time, none are quite dominent as today's
Aquamacs or Carbon Emacs), or using emacs in X11 installed on OS X (at
the time, X11 for OS X isn't distributed by Apple) ... long story
short, i switched to emacs from Xemacs and adopted today the Carbon
Emacs (which is GUI based) as my main emacs.
So, only after 7 years of pure text based emacs, i began to know what
are the GUI menus in emacs starting in 2006. Even then, i still don't
use the mouse other than occationally pulling menus to see whats
there, or occational dragging pane separators to adjust split panes
size. Only in 2007 or 2008, i noticed that mouse buttons can be used
for copy/cut and is sometimes quite convenient when your hand is on
the mouse in a browsing mode (such as doing tasks that heavily involvs
browsing web), and i also started to use mouse wheel.
See also:
My Experience of Emacs vs Xemacs
http://xahlee.org/emacs/emacs_vs_xemacs.html
Xah
∑ http://xahlee.org/
☄
David Kastrup
> On Oct 15, 8:48 am, David Kastrup <d...@gnu.org> wrote:
>> Paul Donnelly <paul-donne...@sbcglobal.net> writes:
>> > Do you think Emacs is losing new users faster than it gains them?
>>
>> That's not actually possible. Before you lose a new user, you have to
>> gain her. So the number of lost new users will always be at most the
>> number of gained new users. The question is rather whether it is losing
>> old users faster than it gains new ones.
>
> LOL. That's very silly. “losing new users” is perfectly sensible. It
> means you don't gain users.
Please reread the sentence "Do you think Emacs is losing new users
faster than it gains them?" and then think again since you pride
yourself of thinking better than the rest of the world. If one
interprets the sentence in the manner you do, what possible sense would
the word "faster" make here?
"faster" can only make sense if there is some _sequence_ of gaining and
losing users implied.
>> And that's not really pertinent to a project dying: it is the number
>> of developers. And if you take a look at XEmacs (which I consider
>> pretty much a dead project), my impression is that nobody uses it
>> anymore. But that does not keep the occasional new blood from
>> appearing among the developers. Fewer than old ones fading out,
>> admittedly, but developers are not really fazed by trends as easily
>> as users.
>
> Bad bad critical thinking skill here.
>
> The number of users to a project is more critical than the number of
> developers, with respect to the project's livelihood. Typically you
> have users first, then they become developers.
Actually, that's nonsense. You can't use a product that has not yet
seen development. The number of users is not a value in itself: you
have to factor in how easy it is for them to actually become developers.
For proprietary products, it is close to impossible. For products
mainly extensible in C (like vim), it is rather hard.
For Emacs and Emacs Lisp, the threshold is very low. A lot of users at
one point of time start fiddling with Lisp forms.
> A project with lots developers but little users will just die.
You mean like Linux, an initially developers-only project did?
>> UNIX does not even _have_ graphics. You are thinking of X11.
>
> when i hear tech geekers talk, i find them quite stupid. When in
> argument about unix usability, the fanatics will say unix support
> graphics. But when in arguments about flaws of unix's components, they
> say unix is just a kernel or such, so that file system problems is not
> unix flaw, x11 problem is not unix flaw, shell stupidities is not unix
> flaw, etc and so on, such that unix is so poweful that you can just
> put in another component.
One of your problems is that you are not capable of perceiving different
people as different individuals. For you, there is just yourself, and
then everybody else. And you blame everybody for things just one person
said, and you berate people for their inconsistency when in fact
different people said different things. In particular when they do this
in the course of a single discussion.
> O, hello David!
>
> Btw, David, come to Second Life. I've created a emacs group there.
> (there's also a lisp group) We can have a voice debate party with tea
> and biscuits. :D My name there is Xah Toll.
I am still quite occupied with First Life currently. I'll give the
sequel a whirl once I am through with that.
--
Paul Donnelly
All very true. There is no such complete environment today. I'm saying
there are better projects to spend time on (such as a programmable
desktop) than dragging Emacs kicking and screaming into the 21st
century. Let the old (and prematurely old) farts have it.
Paul Donnelly
> Paul Donnelly <paul-d...@sbcglobal.net> writes:
>
>> Do you think Emacs is losing new users faster than it gains them?
>
> That's not actually possible. Before you lose a new user, you have to
> gain her. So the number of lost new users will always be at most the
> number of gained new users. The question is rather whether it is losing
> old users faster than it gains new ones.
Sure it is. Emacs could be gaining 20 users per month and losing 30
(probably to death -- once and Emacser, always an Emacser,
right?). Obviously that would not be sustainable, but that's the point.
> And that's not really pertinent to a project dying: it is the number of
> developers. And if you take a look at XEmacs (which I consider pretty
> much a dead project), my impression is that nobody uses it anymore. But
> that does not keep the occasional new blood from appearing among the
> developers. Fewer than old ones fading out, admittedly, but developers
> are not really fazed by trends as easily as users.
I don't think Emacs is dying in the first place. Not quickly at
least. It was just my impression that the topic was how to make Emacs
approachable "for the kids", and that part of the premise was that
attracting new users was the way to ensure continued life.
>> I'm not so sure, but I do think it's time for Emacs to "die",
>> phoenixlike. A program like Emacs only makes sense when the
>> environment outside of it is so limited that it's easier to write
>> applications inside a freaking *text editor* than to write stand-alone
>> apps.
>
> Which is pretty much the reason why Emacs makes perfect sense. You have
> just the APIs and functions to get the job done.
>
>> Back in the days of text mode, when you didn't get windowing and stuff
>> from the OS for free, Emacs was a good move.
>
> But you don't get it for free. Far from it.
I mean it graphics and multiple windows can be assumed to be provided by
the system, while that was not always the case.
>> But I think now that everybody gets graphics, gets a mouse, gets
>> windows from the WM, the time is ripe for Emacs to be reinvented as
>> something a little more UNIX and a little less GNU.
>
> UNIX does not even _have_ graphics. You are thinking of X11. But naked
> X11 is not something anybody uses anymore. They use things like GNOME,
> and guess what, the G in GNOME stands for GNU. And indeed, Emacs offers
> a perfectly working GNOME/Gtk+ look.
I'm thinking of any system in use as a desktop today. And by UNIX and
GNU I meant interoperability versus monoliths (which is perhaps being
too kind to UNIX and unfair to GNU).
>> Time to reconsider what really needs to be in a programmable text
>> editor, what could be better implemented with a more specific program
>> (a structured editor for Lisp or SGML), and what should be something
>> entirely different (a newsreader, a spreadsheet).
>
> Text is text.
Except when it's a tree of code, or a grid of spreadsheet cells, or any
number of other things that *can* be represented in text, but maybe
ought not to be. Don't get me wrong, Emacs provides a UI that can
present many good programs. I'm saying that while the concept behind
Emacs -- a text editor that's programmable enough to be a desktop -- the
specifics, such as a built-in window manager, elisp, and the notion that
a buffer holds primarily text, are getting long in the tooth.
>> Emacs, today, could be a better fit for the modern desktop if it
>> dropped the idea of managing its own windows, dropped most of the
>> hotkeys entirely, made M-x commands more approachable, dropped the
>> idea that every window was filled with text, and adopted the
>> assumption that many kinds of programs would be written in it. In
>> other words, Emacs recast as the desktop environment for people who
>> appreciate visual minimalism, consistency, and Lisp scripting (and the
>> elisp dialect could really be dropped in favor of CL).
>>
>> Of course I realize it's a big job and probably will never happen
>> unless I do it myself in a fit of superhuman effort,
>
> It rather sounds like you should get and install a modern version of
> Emacs compiled for Gtk+. You are preaching to the choir, a choir that
> has not only already seen the light but actually nailed it down long
> ago. Ok, I get carried away on my analogies.
What do I get out of that? A silly menu bar and a right-click buffer
menu that never lines up right because its formatting assumes a
fixed-width font? Emacs is built around such a specific interaction
paradigm that it would take a little more than that to leapfrog to the
forefront of UI design.
Ted Zlatanov
n> On Oct 15, 2:08 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
n> Yes, but CUA mode only standardize on the poor choices available for
n> notepad and the likes, where you only have, for instance, motions for
n> char, word, line and page. Emacs (and most other advanced text
n> editors) allow for moving by sentences and paragraphs/blocks as well.
n> What are the CUA shortcuts for that?
Ctrl-Up/Down goes by paragraph. Blocks and sentences are not handled by
CUA motion commands AFAIK. Plain text is the lowest common editing
denominator, I guess.
Ted
David Kastrup
> All very true. There is no such complete environment today. I'm saying
> there are better projects to spend time on (such as a programmable
> desktop) than dragging Emacs kicking and screaming into the 21st
> century. Let the old (and prematurely old) farts have it.
Few other editors have been dragged into the 21st century yet and can
properly deal with various single- and multibyte encodings. So if you
want to drag your users into the 21st century without all too much
kicking and screaming, Emacs remains an attractive option.
Unless you are talking right-to-left languages: Emacs is not yet there.
But then there are not many systems that are.
David Kastrup
> David Kastrup <d...@gnu.org> writes:
>>
>> It rather sounds like you should get and install a modern version of
>> Emacs compiled for Gtk+. You are preaching to the choir, a choir
>> that has not only already seen the light but actually nailed it down
>> long ago. Ok, I get carried away on my analogies.
>
> What do I get out of that? A silly menu bar and a right-click buffer
> menu that never lines up right because its formatting assumes a
> fixed-width font?
Right click marks a region end. I am not sure what you are thinking
about. Emacs deals pretty well with proportional fonts in general.
> Emacs is built around such a specific interaction paradigm that it
> would take a little more than that to leapfrog to the forefront of UI
> design.
Whatever. I can drag and drop picture files from typical image viewers
into my outgoing mail. Or into directory buffers. The desktop gets
saved when the GUI shuts down or when Emacs is told so by the session
manager. By now the development version of Emacs IIRC can be embedded
into other windows. I can browse directories using thumbnails and
stuff. How about explaining what particular shortcomings in "forefront
of UI design" hamper Emacs users?
Tim X
and as an old fart, I accept. What I don't understand with all these
arguments is that if it is so ancient and out of touch with what people
now want, how come so many threads pop up regarding how it can be
'fixed'. Surely if there are all these other wonderful specific purpose
modern programs out there that are now able to do the job better than
emacs, why isn't everyone using them and forgetting about emacs in the
same way most have forgotten about 'ed'
Personally, I think the anser is because emacs is so powerful and
configurable. I don't agree with Xah's 'modernisation' arguement because
I think he has missed the point. There are endless improvements that
could be made to emacs, but messing around on the superficial aspects of
terminology and keybindings are not among them. I understand Xah's
argument is based on his belief as to what discourages new uses and his
belief that if its not changed, emacs will die. I expect emacs will die
at some point, but I think the changes he proposes would only be
relevant to the types of users who are never going to actually
understand why emacs has significant advantages. The sort of people who
may find the learning curve easier after his changes are also the type
of users who would find other editors just as useful. They are more than
likely to use one of those other editors because they are smaller and
faster or just because they were already there/installed.
Those who find emacs very different and much more usable are also those
users who like to customize their environment to meet their needs rather
than changing their needs to fit in with the envrionment. These are
users who will readily change key bindings to suit their needs, will
customize modes to suit their needs and who will write elisp extensions
to meet thier needs (ironically, users like Xah!).
in the end, the only ones that really count are those who actually put
the effort into maintaining and extending the system. These are the
people who will keep emacs alive. If making it more 'modern' is not high
on their agenda, then its unlikely anything will change. So far, I think
the maintainers have been doing an excellent job. The addition of new
modes and functionality, such as org mode, easypgp, EUDC, GTK,
anti-aliased fonts, improved regexp features, support for dbus, etc are
exactly the improvements most long term users want.
I personally don't have any issue if someone decides to do the work and
things that Xah wants get changed, such as not having the scratch buffer
by default (though I do want to be able to customize it so that it does
happen by default because I find it v useful), changing keybindings
(again, I want to be able to keep the old ones I'm use to - I have no
problems with the defaults, changing the name from meta to alt (though I
still think the point that there is a difference bwtween the two has
been missed), etc. However, I would hav an issue if time spent doing
this work meant that other more relevant and important improvements are
put on hold (e.g. support for wider range of coding systems and
character sets, improvements in elisp performance, improvements in
display engine, improvements in bundled modes such as tramp or eudc
etc.
Likewise, if someone decides to develop a new editor that is more
in-line with the often transient ideas of what is modern which provides
all the same power I currently have with existing emacs, even if it uses
CL, guile or some other modern language from the lisp family, then I'll
probably switch to it if it looks like it will be more long-lasting and
if the development/maintenance of emacs begins to stall or it is unable
to meet my requirements as effectively.
Tim
--
tcross (at) rapttech dot com dot au
Tim X
> David Kastrup <d...@gnu.org> writes:
>
>> Paul Donnelly <paul-d...@sbcglobal.net> writes:
>>
>>> Do you think Emacs is losing new users faster than it gains them?
>>
>> That's not actually possible. Before you lose a new user, you have to
>> gain her. So the number of lost new users will always be at most the
>> number of gained new users. The question is rather whether it is losing
>> old users faster than it gains new ones.
>
> Sure it is. Emacs could be gaining 20 users per month and losing 30
> (probably to death -- once and Emacser, always an Emacser,
> right?). Obviously that would not be sustainable, but that's the point.
>
It seems not many get David's point. He is quite correct in what he is
saying based on the grammar of the sentence in question. The sentence
"Do you think Emacs is losing new users faster than it gains them?"
does not make sense because you can't lose soemthing faster than you
recieve it. To make it clear, the longer form of that sentence is
"Do you think Emacs is losing new users faster than it gains new users?"
What I think was actualy meant by the sentence is "Do you think emacs is losing
users faster than it gains new users", which means that its user base is
shrinking over time. The answer, as far as I'm concerned, is that we do
not know. Anyone who claims they do know is talking rubbish and trying
to sell subjective opinion as objective fact. What is known is that
emacs seems to be actively maintained and developed and has seen some
considerable enhancements over the past few years. this doesn't indicate
that it is going to die in the short-term. For the long-term, its just
guesswork either way.
tim
Tim X
> On Tue, 14 Oct 2008 14:03:14 -0700 (PDT) namekuseijin <nameku...@gmail.com> wrote:
>
> n> Yes, the main one being that the CTRL+C, CTRL+V ease of usage is only
> n> achieved when you have so freaking few functionality available.
> n> Notepad is immediately accessible, but it's only helpful for small,
> n> simple tasks. Notepad and its cc,cv paradigm don't scale well to
> n> more complex, larger editing tasks, where you can see the benefit of
> n> macros, quick jumps through the text and back, autocomplete,
> n> templated text insertion, last edits buffer etc. And when you need
> n> much more functionality at your fingertips, you need far too many
> n> keyboard shortcuts.
>
> The benefit of CUA is in the standartization of the shortcuts, not in
> their number or particular key strokes. Every application supports the
> same ones. This is why I always use CUA mode in Emacs: I don't have to
> remember to use different keys every time I switch editors. This
> includes Ctrl-Left/Right/Up/Down, adding Shift to motion to select, etc.
and as you say, Emacs has CUA mode and in latest emacs versions,
selecting it is as simple as clicking on the menu. So, there is not
any real issue as far as I can tell - if you like it, use it, if you
don't then don't. Not many editors provide that level of freedom!
> n> It could certainly get better, like automatic keyboard shortcut
> n> switching to current editing context.
>
> Have you considered MuMaMo? I don't use it, but it allows mixing of
> major modes in a buffer:
>
> http://www.emacswiki.org/cgi-bin/wiki/MuMaMo
>
Plus, if you use local-set-key rather than global-set-key for mode
specific configurations, you can get a lot of flexibility in what
shortcuts do depending on the mode your in. You can then switch between
sets of key bindings by switching the mode your in. Possibly not as
powerful as a system that could automatically do this based on some sort
of dynamic mode structure that changed based on the content of the
buffer. However, such a facility would be quite complex to develop - for
a start, emacs would need a much deeper 'knowledge' regarding what your
editing (which is sort of related to the work being done by the CEDET
with semantic et. al.). Sometimes, I think people overlook the fact that
while getting very sphisticated behavior in an editor dedicated to a
specific task may seem relatively striaght forward, doing so in a
generic manner is much more difficult. For example, I've seen people
complain that emacs' support for writing HTML isn't as good as editor X,
which was built specifically for that purpose. However, that same editor
probably really sucks at editing lisp, python or ruby compared to
emacs. There is always some level of trade-off.
Tim
Paul Donnelly
> Paul Donnelly <paul-d...@sbcglobal.net> writes:
>
>> David Kastrup <d...@gnu.org> writes:
>>>
>>> It rather sounds like you should get and install a modern version of
>>> Emacs compiled for Gtk+. You are preaching to the choir, a choir
>>> that has not only already seen the light but actually nailed it down
>>> long ago. Ok, I get carried away on my analogies.
>>
>> What do I get out of that? A silly menu bar and a right-click buffer
>> menu that never lines up right because its formatting assumes a
>> fixed-width font?
>
> Right click marks a region end. I am not sure what you are thinking
> about. Emacs deals pretty well with proportional fonts in general.
I was thinking of my own personal config, which binds mouse-3 to
'mouse-buffer-menu, which I like having, but which doesn't display well
at all due to using spaces or tabs or something for alignment. I never
use mouse regions much except for mouse-drag-region.
>> Emacs is built around such a specific interaction paradigm that it
>> would take a little more than that to leapfrog to the forefront of UI
>> design.
>
> Whatever. I can drag and drop picture files from typical image viewers
> into my outgoing mail. Or into directory buffers. The desktop gets
> saved when the GUI shuts down or when Emacs is told so by the session
> manager. By now the development version of Emacs IIRC can be embedded
> into other windows. I can browse directories using thumbnails and
> stuff. How about explaining what particular shortcomings in "forefront
> of UI design" hamper Emacs users?
I'm not recommending Emacs undergo a makeover just to look like another
widget pile. It can be better than that, and it is better than that, but
it can be yet better. It's not the best UI ever designed, and using Gtk+
to do the same old thing won't make it into that.
I think that Emacs could do better with regard to command
invocation. You've got two systems: C-whatever keystrokes, including
prefix commands, and M-x commands. Hotkeys are quick but hard to
remember due to sheer volume and how un-mnemonic they are. M-x commands
are as plentiful but easier to remember and look up, being made of
words.
IMO, it could do with regularization and simplification here. My own
leaning is to take a hint from Plan 9's Acme, providing the ability to
execute selected text as a command, as well as a special place to put a
few commands, and to eliminate most hotkeys altogether. The rationale
being that it's best to perform all command invocation with one system,
that words are easier to remember than hotkey sequences, and that the
pain of retyping or navigating the minibuffer history to repeat commands
could be alleviated. Something like this could be implemented in Emacs
as-is, probably. And perhaps it could be more than an ugly hack, in
which case Emacs wins again.
But I think that in addition to a different command invocation interface
it could be improved by:
1. Dropping the redundant window system.
2. Moving away from text as a window's assumed primary contents. Yes,
Emacs can display images, but (correct me if I'm wrong) they are used
similarly to bold text and must be associated with some text. It would
be better if it were the other way around, and text buffers were built
on top of a more flexible buffer type.
I do think Emacs has great points.
1. Programmable, to the point of being largely written in its scripting
language.
2. Identical mechanisms for invoking system-defined and user-defined
commands.
3. Lisp.
4. "Document first" interface. No toolbars or other clutter.
5. The quantity of software already written for it.
Sooo... Emacs is pretty good, except for all the ways it isn't, and I
don't think focusing on CUA is especially worthwhile, being only a
distraction from the real issues.
Paul Donnelly
> Paul Donnelly <paul-d...@sbcglobal.net> writes:
>
>> David Kastrup <d...@gnu.org> writes:
>>
>>> Paul Donnelly <paul-d...@sbcglobal.net> writes:
>>>
>>>> Do you think Emacs is losing new users faster than it gains them?
>>>
>>> That's not actually possible. Before you lose a new user, you have to
>>> gain her. So the number of lost new users will always be at most the
>>> number of gained new users. The question is rather whether it is losing
>>> old users faster than it gains new ones.
>>
>> Sure it is. Emacs could be gaining 20 users per month and losing 30
>> (probably to death -- once and Emacser, always an Emacser,
>> right?). Obviously that would not be sustainable, but that's the point.
>>
>
> It seems not many get David's point. He is quite correct in what he is
> saying based on the grammar of the sentence in question. The sentence
>
> "Do you think Emacs is losing new users faster than it gains them?"
>
> does not make sense because you can't lose soemthing faster than you
> recieve it. To make it clear, the longer form of that sentence is
>
> "Do you think Emacs is losing new users faster than it gains new users?"
You're right, I didn't even notice how garbled that was.
Alan Mackenzie
> namekuseijin <nameku...@gmail.com> writes:
>> On 14 out, 20:14, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>>> namekuseijin <namekusei...@gmail.com> writes:
>> Daniel said EMACS would never gain traction among its original
>> audience were it not for it using familiar keycombos already standard
>> among users. This is the 2000's and familiar keycombos to most users
>> do not generally include regular alphabetic keys or sequences of 3 or
>> more chained keys.
The keysequence to type "the" is three key presses long. Lots of users,
even nowadays, can manage this without difficulty. Some can even manage
the key sequences for multisyllabic words.
The length of the keysequences for commands varies with the logarithm of
the number of commands just as the length of words varies as log (number
of words). In Emacs, there are lots of commands.
>> I've come to somewhat appreciate Xah's take on the subject of
>> modernization of Emacs. It's either this or let it die once the
>> original 70s/80s users are dead. I believe Emacs needs to provide
>> standard familiar keybindings to nowadays users and a retro-
>> compatibility keybinding mode.
You can have "standard familar" keybindings or good ones. Sadly, you
can't have both together.
> Do you think Emacs is losing new users faster than it gains them? I'm
> not so sure, but I do think it's time for Emacs to "die", phoenixlike. A
> program like Emacs only makes sense when the environment outside of it
> is so limited that it's easier to write applications inside a freaking
> *text editor* than to write stand-alone apps.
> Back in the days of text mode, when you didn't get windowing and stuff
> from the OS for free, Emacs was a good move. But I think now that
> everybody gets graphics, gets a mouse, gets windows from the WM, the
> time is ripe for Emacs to be reinvented as something a little more
> UNIX and a little less GNU.
I use Emacs in pure text mode - on a Linux virtual terminal, to be
precise. When doing pure text work (programming, writing emails, ....)
it makes sense to have an environment optimised for text, not one which
is compromised by a need to do graphics. Any visitors who've seen my
Emacs have been impressed by its unclutteredness and clarity. Most
modern computer users have never used a pure text terminal.
Sadly, few applications now run in pure text mode any more.
> Emacs, today, could be a better fit for the modern desktop if it dropped
> the idea of managing its own windows, dropped most of the hotkeys
> entirely, made M-x commands more approachable, dropped the idea that
> every window was filled with text, and adopted the assumption that many
> kinds of programs would be written in it. In other words, Emacs recast
> as the desktop environment for people who appreciate visual minimalism,
> consistency, and Lisp scripting (and the elisp dialect could really be
> dropped in favor of CL).
Why should Emacs be made a better fit for the "modern desktop"?
> Of course I realize it's a big job and probably will never happen unless
> I do it myself in a fit of superhuman effort, but it's my position that
> the specifics of keyboard shortcuts are the least of its problems
> considering current users are used to them by now, and that it would not
> be a bad thing if Emacs were allowed to "sunset", leaving room for an
> entirely modern -macs.
Heh! You know what to expect here, so I'll say it - feel free to
implement such a beast. :-)
What would be so good about a "modern" -macs? The current one has had
over two decades to become optimised; "modern desktops" have a long way
to go before they reach Emacs's level of usability, but it would be nice
to see them getting there. What would/will kill off Emacs will be the
end of the keyboard as the preferred input/control device.
--
Alan Mackenzie (Nuremberg, Germany).
xah...@gmail.com
> In comp.emacs Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>
> > namekuseijin <namekusei...@gmail.com> writes:
> >> On 14 out, 20:14, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
> >>> namekuseijin <namekusei...@gmail.com> writes:
> >> Daniel said EMACS would never gain traction among its original
> >> audience were it not for it using familiar keycombos already standard
> >> among users. This is the 2000's and familiar keycombos to most users
> >> do not generally include regular alphabetic keys or sequences of 3 or
> >> more chained keys.
>
> The keysequence to type "the" is three key presses long. Lots of users,
> even nowadays, can manage this without difficulty. Some can even manage
> the key sequences for multisyllabic words.
The context is about shortcut keys involving multiple key combinations
or sequence of them. e.g. “Ctrl+x 5 2” to create a new window, “Ctrl+x
2” to split windows into 2 panes, “Alt+Shift+<” to move to beginning
of file, “Alt+Ctrl+↑” to move cursor upword a paren group, etc.
> >> I've come to somewhat appreciate Xah's take on the subject of
> >> modernization of Emacs. It's either this or let it die once the
> >> original 70s/80s users are dead. I believe Emacs needs to provide
> >> standard familiar keybindings to nowadays users and a retro-
> >> compatibility keybinding mode.
>
> You can have "standard familar" keybindings or good ones. Sadly, you
> can't have both together.
You can.
A Ergonomic Keyboard Shortcut Layout For Emacs
http://xahlee.org/emacs/ergonomic_emacs_keybinding.html
In this setup, you have the standard keybinding such as:
Standard name Key press Elisp command
Open New File Ctrl+n new-empty-buffer
Open Ctrl+o find-file
Close Ctrl+w close-current-buffer
Save Ctrl+s save-buffer
Save As Ctrl+Shift+s write-file
Print Ctrl+p print-buffer
Select All Ctrl+a mark-whole-buffer
Yet, the most frequently needed emacs commands now have easier to type
keybindings. For examples:
Reducing one or more keystrokes:
“Ctrl+x 2” → “Alt+2” (split window)
“Ctrl+x 1” → “Alt+1” (unsplit window)
“Ctrl+x o” → “Alt+o” (move cursor to other pane)
“Ctrl+Shift+_” → “Alt+z” (undo)
“Ctrl+x h” → “Ctrl+a” (select all)
Easier to type position:
“Ctrl+p” → “Alt+i” (move up)
“Ctrl+n” → “Alt+k” (move down)
“Ctrl+f” → “Alt+l” (move right)
“Ctrl+b” → “Alt+j” (move left)
“Ctrl+Backspace” → “Alt+e” (delete word backward)
“Alt+d” → “Alt+r” (delete word backward)
“Alt+x” → “Alt+a” (call emacs command)
> Heh! You know what to expect here, so I'll say it - feel free to
> implement such a beast. :-)
It already partially exist, for example, the ergonomic shortcut system
above, and Aquamacs, and EmacsW32 on Windows, as well as numerous
lesser known effort such as Easymacs.
The question is, whether you are willing to support it to become
default setup of GNU emacs for the benefit emacs community, or
actively keep naysaying about it and insist that emacs should remain
its 1980 UI and keyboard shortcuts.
Xah
∑ http://xahlee.org/
☄
Paul Donnelly
> In comp.emacs Paul Donnelly <paul-d...@sbcglobal.net> wrote:
>> namekuseijin <nameku...@gmail.com> writes:
>
>>> On 14 out, 20:14, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>>
>> Do you think Emacs is losing new users faster than it gains them? I'm
>> not so sure, but I do think it's time for Emacs to "die", phoenixlike. A
>> program like Emacs only makes sense when the environment outside of it
>> is so limited that it's easier to write applications inside a freaking
>> *text editor* than to write stand-alone apps.
>
>> Back in the days of text mode, when you didn't get windowing and stuff
>> from the OS for free, Emacs was a good move. But I think now that
>> everybody gets graphics, gets a mouse, gets windows from the WM, the
>> time is ripe for Emacs to be reinvented as something a little more
>> UNIX and a little less GNU.
>
> I use Emacs in pure text mode - on a Linux virtual terminal, to be
> precise. When doing pure text work (programming, writing emails, ....)
> it makes sense to have an environment optimised for text, not one which
> is compromised by a need to do graphics. Any visitors who've seen my
> Emacs have been impressed by its unclutteredness and clarity. Most
> modern computer users have never used a pure text terminal.
>
> Sadly, few applications now run in pure text mode any more.
Heh, as soon as I mentioned graphics, I knew someone using text mode
would come along. But you know what? I'm running Emacs in X, and aside
from using a light background and having a mouse cursor, my computer
screen looks just like yours. I appreciate your dislike of cluttered
interfaces, and I feel the same way. I still think that a bitmap
display, despite being frequently abused, is a good thing to have,
because it's flexible when you need it, and it's not like you lose the
ability to display text. Nothing is "compromised". It just demands a
little more control and a little less "OMG GRADIENTS" from the UI
designers. I'm also developing a fondness for proportional fonts.
>> Emacs, today, could be a better fit for the modern desktop if it dropped
>> the idea of managing its own windows, dropped most of the hotkeys
>> entirely, made M-x commands more approachable, dropped the idea that
>> every window was filled with text, and adopted the assumption that many
>> kinds of programs would be written in it. In other words, Emacs recast
>> as the desktop environment for people who appreciate visual minimalism,
>> consistency, and Lisp scripting (and the elisp dialect could really be
>> dropped in favor of CL).
>
> Why should Emacs be made a better fit for the "modern desktop"?
Because everything modern is better, of course. And because the modern
desktop provides a few things that the antique one* didn't, things which
could be put to good use.
* Please interpret "desktop" loosely.
>> Of course I realize it's a big job and probably will never happen unless
>> I do it myself in a fit of superhuman effort, but it's my position that
>> the specifics of keyboard shortcuts are the least of its problems
>> considering current users are used to them by now, and that it would not
>> be a bad thing if Emacs were allowed to "sunset", leaving room for an
>> entirely modern -macs.
>
> Heh! You know what to expect here, so I'll say it - feel free to
> implement such a beast. :-)
It's on the to-do list. :|
> What would be so good about a "modern" -macs? The current one has had
> over two decades to become optimised; "modern desktops" have a long way
> to go before they reach Emacs's level of usability, but it would be nice
> to see them getting there. What would/will kill off Emacs will be the
> end of the keyboard as the preferred input/control device.
I think it would be more usable if the pressure to cram everything into
a text buffer were eased. Like any Emacs user, I want to spend all my
time in Emacs, but I don't like the way programs generally end up when
they get shoehorned in -- a bunch more hotkeys and a bunch of
idiosyncratically-named commands.
I can think of several possible improvements having to do with making
commands more accessible to a person who doesn't remember which one they
wanted, making it possible to "cache" frequent commands for later
invocation, making multitasking and completion within Emacs more
graceful (should I be using more frames?), and a bunch of other little
niggles. And the question is whether hacking within Emacs is really the
best way to see the end product I'd like to see. I lean towards
"no". Not that zillions of lines of elisp code wouldn't disagree. Trying
to change Emacs "from within" would be learning a huge system just to
change it completely -- something which other Emacs devs would probably
not be interested in at all.
I don't see Emacs's future being much different from its past, but I'd
like *my* future of text editing to be.
Alan Mackenzie
In comp.emacs Paul Donnelly <paul-d...@sbcglobal.net> wrote:
> Alan Mackenzie <a...@muc.de> writes:
>> I use Emacs in pure text mode - on a Linux virtual terminal, to be
>> precise. When doing pure text work (programming, writing emails, ....)
>> it makes sense to have an environment optimised for text, not one which
>> is compromised by a need to do graphics. Any visitors who've seen my
>> Emacs have been impressed by its unclutteredness and clarity. Most
>> modern computer users have never used a pure text terminal.
>> Sadly, few applications now run in pure text mode any more.
> Heh, as soon as I mentioned graphics, I knew someone using text mode
> would come along. But you know what? I'm running Emacs in X, and aside
> from using a light background and having a mouse cursor, my computer
> screen looks just like yours.
Ratpoison?
> I appreciate your dislike of cluttered interfaces, and I feel the same
> way. I still think that a bitmap display, despite being frequently
> abused, is a good thing to have, because it's flexible when you need
> it, and it's not like you lose the ability to display text. Nothing is
> "compromised".
Well, scrolling is somewhat slower, it takes more effort to set up
right, and you lose some key sequences to the Window Manager - sometimes
prime ones like <Ctrl>-<arrows>.
> It just demands a little more control and a little less "OMG GRADIENTS"
> from the UI designers. I'm also developing a fondness for proportional
> fonts.
Ah. OK. I'll use a proportional font if it passes the "Legal||Illegal"
test. (Just try that with Microsoft's Ariel :-() My fixed font
displays it pretty legibly.
>>> Emacs, today, could be a better fit for the modern desktop if it dropped
>>> the idea of managing its own windows, dropped most of the hotkeys
>>> entirely, made M-x commands more approachable, dropped the idea that
>>> every window was filled with text, and adopted the assumption that many
>>> kinds of programs would be written in it. In other words, Emacs recast
>>> as the desktop environment for people who appreciate visual minimalism,
>>> consistency, and Lisp scripting (and the elisp dialect could really be
>>> dropped in favor of CL).
>> Why should Emacs be made a better fit for the "modern desktop"?
> Because everything modern is better, of course.
Yes, of course it is. Sorry. I forgot.
> And because the modern desktop provides a few things that the antique
> one* didn't, things which could be put to good use.
> * Please interpret "desktop" loosely.
Well, a desktop is a horizontal surface, a computer screen is a vertical
one. Is that enough looseness?
>>> Of course I realize it's a big job and probably will never happen unless
>>> I do it myself in a fit of superhuman effort, but it's my position that
>>> the specifics of keyboard shortcuts are the least of its problems
>>> considering current users are used to them by now, and that it would not
>>> be a bad thing if Emacs were allowed to "sunset", leaving room for an
>>> entirely modern -macs.
>> Heh! You know what to expect here, so I'll say it - feel free to
>> implement such a beast. :-)
> It's on the to-do list. :|
Excellent. ;-)
>> What would be so good about a "modern" -macs? The current one has had
>> over two decades to become optimised; "modern desktops" have a long way
>> to go before they reach Emacs's level of usability, but it would be nice
>> to see them getting there. What would/will kill off Emacs will be the
>> end of the keyboard as the preferred input/control device.
> I think it would be more usable if the pressure to cram everything into
> a text buffer were eased. Like any Emacs user, I want to spend all my
> time in Emacs, but I don't like the way programs generally end up when
> they get shoehorned in -- a bunch more hotkeys and a bunch of
> idiosyncratically-named commands.
Yes. I do CVS operations, email and usenet outside of Emacs. And most
of my command line stuff, too.
> I can think of several possible improvements having to do with making
> commands more accessible to a person who doesn't remember which one they
> wanted, making it possible to "cache" frequent commands for later
> invocation, making multitasking and completion within Emacs more
> graceful (should I be using more frames?), and a bunch of other little
> niggles. And the question is whether hacking within Emacs is really the
> best way to see the end product I'd like to see. I lean towards
> "no". Not that zillions of lines of elisp code wouldn't disagree. Trying
> to change Emacs "from within" would be learning a huge system just to
> change it completely -- something which other Emacs devs would probably
> not be interested in at all.
> I don't see Emacs's future being much different from its past, but I'd
> like *my* future of text editing to be.
OK. What I miss from Emacs is code-browsing, but that's partly because
I've been too lazy to install ECB. The intention is to make ECB part of
the default distribution quite soon.