what's emacs's "fundamental value"?

On Jun 29, 12:25 am, Marc Mientki wrote:
> Am 28.06.2010 20:20, schrieb Xah Lee:
> > if you have the right fonts installed, then all the chars on that page
> > shows in latest versions of Google Chrome, Firefox, Opera.
> > they all show in emacs, of course.
> Not in my Emacs (23.2.1 on windows XP)

you need to install the cited fonts first.


> Sorry, but slowly I find your posts as spam.

to the best of your intentions, you probably meant to say you find my views unorthodox.

> Many of your
> proposals look strange for me. This starts with your indentation
> and typography of Lisp codes and use of CamelCase,

this has been discussed in comp.emacs and or gnu.emacs.help newsgroups several times in the past about 4 years.

to repeat my point of view:

• i don't care much about code-formatting style in the sense people should sting others just because their code isn't formatted in a particular way, or in a way comformant to whatever lose guides the language's official documentation may advice. In fact, i consider the habit of thinking about code formatting being a major time drain, and inhibit progress in computer languages. You can ready many articles on my site that discuss this, under the formatting section here: http://xahlee.org/Periodic_dosage_dir/comp_lang.html

• i often use camelCase in my elisp code because i find it easier to distinguish my own variables from emacs lisp's built-in ones. In particular, due to the fact that the emacs-lisp-mode does not do syntax color fully. See:

• Emacs Lisp Mode Syntax Coloring Problem

> and ends
> with your very strange criticism of fundamental values of Emacs.

Right. Thanks for your opinion. It is controversial. I'll nitpick your phrasing a bit. My criticism really isn't about “fundamental values” of emacs, but mostly about its interface. You might think that emacs's interface being its fundamental value... but to me the fundamental value of emacs goes far more than its interface, in fact i consider its interface has little value today. Perhaps that's where we disagree.

• Emacs Modernization

to discuss on emacs further, perhaps we can narrow the cross posting to just comp.emacs.

∑ http://xahlee.org/


lisp machine history, Richard Stallman's mis-information

just discovered a blog written by a old lisper Dan Weinreb, refuting on a story on Lisp Machine companies as told by Richard Stallman.

“Rebuttal to Stallman’s Story About The Formation of Symbolics and LMI” (2007-11), by Dan Weinreb. At

From my experience, and extensive reading about Richard Stallman since late 1990s, that i would believe Dan Weinreb on this more than Richard Stallman.

I find Richard Stallman's writings, are often biased, and in many of his writings and lectures i've seen, he's even intentionally mis-infom people for his point of view on the philosophy of software licensing. (see http://xahlee.org/UnixResource_dir/writ2/FSF_philosophy.html )

Dan Weinreb's blog article probably has been mentioned here before, but i felt it be announced again.

∑ http://xahlee.org/


emacs cua mode


On Jun 19, 2:06 pm, Evans Winner wrote:
> ,------ const451 wrote ------
> |   Is there a plugin that uses standard key shortcuts for
> |   text manipulation such as Ctrl-C, Ctrl-V, Ctrl-Z, etc.?
> |   I think they are faster to use than the default
> |   shortcuts in emacs.
> Do you think they are faster to use than the default
> bindings in Emacs, or do you mean that they are faster for
> you to use at the moment because they are what you are used
> to?
> In any case,
>     M-x cua-mode RET

> -- will probably do more or less what you want.  CUA stands
> for Common User Interface and was designed by IBM in the
> 1980s[1].  cua-mode changes some default Emacs bindings to
> match CUA standards.

Emacs's cua-mode, is named after the IBM's Common User Accesss
standard. However, according to Wikipedia
the IBM CUA standard does not say cut/copy/paste are X C V keys. Quote:

The Cut command is ⇧ Shift+Del; Copy is Ctrl+Ins; Paste is ⇧ Shift+Ins;

The Z X C V keys for undo/cut/copy/paste is popularized by Apple starting in mid 1980s.

As a side note, emacs's naming of cua-mode is very bad. Because:

• very few people today knows what CUA is. Among all people who makes a living by coding, i'd say less than 0.1% knew what CUA means.

• emacs's cua-mode's behavior is not IBM's CUA standard at all. All it does is basically just the X C V keys, and these may not even be part of IBM's CUA.

Emacs's developers named it cua-mode probably because of a ergo/cult problem. They needed a name for this widely needed mode, but naming it anyhing that might relate to Microsoft Windows or Apple is a political problem to FSF/GNU. (note: Richard Stallman HATES Microsoft and also HATES Apple. GNU's stance against Microsoft is well known, from GNU/Richard's writings especially in 1980s and 1990s. Throughout 1990s, GNU boycotted Apple partly becuase Apple sued Microsoft for copying Apple's GUI interface. This boycot was officially withdrawn in i think early 2000s.)

The cua-mode is probably better named XCV-mode or copy-paste-key-mode, and the menu name should be “XCV keys for Cut/Copy/Paste”. The mode name change is probably too late, but the menu name change can still be done. The name “XCV keys for Cut/Copy/Paste” does not relate any commercial organization, and is easy for people to understand what it means, and it more accurately describe what cua-mode do.

also, the cua-mode has a major problem in that it supports XCV but not Z for undo, which is also widely asked for, and standard across Microsoft/Mac/Linuxes today.

> CUA does not scale very well, but is
> popular because it is implemented to some degree on
> Microsoft operating systems and many people first learned
> the idea of doing things with the keyboard in that context.
> People tend to stay with what they learn first.

CUA does not scale very well? Please provide detail on this when saying this kinda things.

> By the way, and just for your information, Emacs users
> typically do not call Emacs Lisp packages "plugins."  More
> often they call them libraries or packages.

Calling it plugin is not emacs convention but i think is very good terminology. It is intuitive, and widely used. For example, browsers used the term plugins since 15 years ago. Mathematica, a programing language calls its extra packages/libraries plugins or add-ons. Firefox also clarified a bit in their terminology of plugin vs add-on starting about 1 or 2 years ago. e.g. plugin are those like java or flash engine, while addon often are little user oriented utilities.

plug-in and add-on are intuitive terms that anyone can easily understand what they mean just by the word itself. While, package, library, module, is more oriented to software engineering in a technical context.

> If the code
> implements a major or minor mode, they typically call it a
> "mode."  They also usually don't use the term "shortcut,"
> possibly because that seems to imply some other manner of
> input that is privileged over use of the keyboard.  The
> phrase "key binding" is more often used, because that is
> what you do: you bind a function to a key or key
> combination.

Similar to the library/package/module vs plug-in/add-on argument, same applies here. The term “Keyboard shortcut” or “hotkey” is suitable in the context of users using a software application, while keybinding is suitable for programing and software engineering.

“keybinding” is in fact logically incorrect in the user context of pressing a key. When you press a key to invoke a command, you are not binding a key. You are using a KEY that has a keybinding.

These distinctions are important.

I'm writing this because it is common in emacs community to sting new users about these kinda things... and i think it's very harmful to emacs's health. It just turns away users and keep brewing the emacs cult.

∑ http://xahlee.org/


swap caps lock and control

On Jun 15, 4:31 pm, Thad Floryan wrote:
> On 6/15/2010 3:45 PM, Xah Lee wrote:
> > On Jun 15, 3:27 pm, Thad Floryan wrote:
> >> On 6/15/2010 1:42 AM, Uday S Reddy wrote:
> >>> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
> >>>> Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
> >>>> cursor reaches the column you want, you don't even need to count
> >>>> 76.  And keep C-n pressed until the cursor reaches the line you want.
> >>> Except that pressing control-key for that long with your pinky is a
> >>> health risk!
> >>> [...]
> >> That's why remapping the [Caps Lock] to be a [Ctrl] is very useful.
> > swapping Caps Lock with Ctrl is not good.
> > • Why You Should Not Swap Caps Lock With Control
> >  http://xahlee.org/emacs/swap_CapsLock_Ctrl.html
> > [...]
> Your opinion which neither I nor 100,000s of others share -- you stand alone.

if we actually do a poll anywhere near scientific, i think majority will find my opinion the better on, as given in my essay.

> A [Ctrl] to the left of [A] is natural and what I've been using since the
> mid-1960s with absolutely NO problems or RSI whatsoever beginning with a
> TTY ASR33 and continuing with a Datapoint 3300, DEC VT100, Datamedia DT80
> and others along the way to today.

Right, another anecdote from a old man.

The question is not whether you have RSI problem. As i detailed in my essay, you can be a programer for 40 years coding daily, and never had RSI problems, yet you can't even touch type. In fact, many programers can't touch type. Am curious what's a rough percentage. I think actually more than 50% of those who makes a living by coding cann't touch type.

> Mapping and using the [Caps Lock] as a [Ctrl] to the immediate left of [A]
> is no different than the ["] to the immediate right of [;] re: pinkies.

The question is not whether it is that bad or not that bad. As i pointed out in my essay, the keyboard itself is badly designed, and much worse is its precursor the typewriter. Yet, people lived with typerwriter for generations.

> The (dumb) PC standard of a [Ctrl] key at the lower-left of a keyboard is
> ridiculous and WILL cause pinky problems if one uses Emacs as an editor and
> bash as a shell.

The question, is whether Swapping Ctrl and Caps Lock key is better with respect to ergonomics, on a average PC keyboard for the general public. I've given detailed reasons why i believe that it is worse, in my essay. To argue fruitfully, you might counter my points.

from my years of experience on this and my observation from the arguments, i think that actually only a minority really propose that swapping Caps Lock and Control is a good thing, even that we hear them online often. It is this minority that keeps spreading baseless info. Also, i think this minority tends to be older people, say, had computing career at least as early as back in 1980s or early 1990s.

i think mostly the reason these minority have such view is because in those days, it is not unusual to find keyboards with Control key on the Caps Lock position. These people “grew up” with that. The habit stuck.

As i have said in my essay, there's a very simple test anyone can do to see which is better. Let me repeat here:

Now, type the following, but on every 3rd letter hold down Caps Lock key as if it is Control.

a b c d e f g h i j k l m n o p q r s t u v w x y z

Do this 100 times or 20 minutes. Really. Do it.

Now, take a break. When you are ready, do it again, but each 3rd letter press the Control key at the either corners of your keyboard, and follow my methods described in my esssay.

You can easily determine, which is less tiring or faster.

This simple test can be varied easily. For example, instead of typing the alphabets in order, you can just grab any sentence. Instead of holding the modifier every 3rd letter, you can easily create a test so that it's every nth letter with n being random from 3 to 5. To prepare the test, YoU caN cAp The letTER tHAt yOu neEd to pReSs thE ModiFier liKE In thIs senTenCe.


aside from the ergonomic matter, i've noticed in my study of keyboarding, that the choices of many shortcuts in many apps are adopted to the many aspects of the keyboard hardware of the time in use by the community. For example, i am quite absolutely certain, that emacs's keybindings are not simply based on the first letter of commands, but the qwerty layout's key positions have significant influence on it. This also applies to the letter choice of unix's shell commands. Much of this influences of design are unconcious.

i've studied keyboarding quite a lot. Wrote some 40 articles in the
past 10 years from my 20 years of using keyboards, 10 or so keyboard macros softwares across linux mac classic, os x, Windows;
(resedit keymap, QuicKey, QuickSilver, keybinding.dict, AutoHotKey, IntelliType, xmodmap, ...), studied key systems in oses (mac classic, x11, mac os x), mastered shortcuts in tens of apps across oses and their capabilities at user level settings, touch
type at professional speed in qwerty and dvorak layouts, studied
chinese input systems, studied shortcut notations and key
notations and key macro language notations, studied keyboard soft layouts (qwerty, dvorak, and international ones), studied keyboard hardware key layouts,... you can see them here:

• All About Keyboards, Keyboard Layouts, Shortcuts, Macros

if keyboard freaks of the world would gather, i think i'd be a high ranking officer. LOL

∑ http://xahlee.org/


emacs espresso mode vs js2-mode screwup

On Jun 15, 1:42 am, Uday S Reddy wrote:
> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
> > Well, C-f C-n is all you need.  I mean, keep C-f pressed until the
> > cursor reaches the column you want, you don't even need to count
> > 76.  And keep C-n pressed until the cursor reaches the line you want.
> Except that pressing control-key for that long with your pinky is a health risk!
> But I feel this discussion is tangential.  Most of us accept that visual line
> movement is a /good/ idea and we find it useful in lots of contexts.  We are
> grateful for Stefan & co for thinking of it and implementing it.
> The question is really whether it should have been made the default.
> Every time I narrowed down to that issue in this thread, the participants have
> fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
> himself).  I guess there is no good answer to it.

i find it great that line-move-visual defaults to t. And i find it good that nothing else is changed about Ctrl+n, with the result that it just move lines visually in emacs 23.x. All things considered. I thought about it for a while when you presented a perspective of what we are arguing about. But the more i think about it, the more the conclusion above.

i find many discussions here silly... writing here takes a lot time. Typically, just 2 posts take out the whole day. Same as elsewhere in mailing lists or private communication with co-workers in a company... Answering a few emails or exchanging opinions takes out the whole day...

i find it silly that Mark Crispin insists this is so bad or breaks backward compatibility or his attacks on commercial software and opinions on certain “FOSS” or “FUD” jargons ... etc. It'd be endless flame war to argue one way or another. Usually fruitless.

but i enjoyed the thread anyway. I enjoyed having to cite my essays, enjoyed knowing about Mark Crispin, enjoyed to have learned who contributed the code for the line-move-visual feature. (in fact spent a hour or two to link to home pages of all i found who contributed major features in 23.x) If i have more time at leisure, i'd sure enjoy throwing flames to annoy Mark and few of you acquaintances. LOL.

maybe we can start another flamewar of a diff subject. I'm quite annoyed that emacs 23.2 has chosen the trivial espresso mode as the javascript mode and screwed Steve Yegg's far much ambitious, talented, and revolutionary and modern and WORKING js mode the js2-mode that includes a on-the-fly js language parser. I attribute it to the now bureaucratic inefficiency of gnu.org management... i was on the gnu dev list when this thread was discussed, was rather pissed that the espresso mode author young 20 something bigshot talking shit about how emacs font lock myth this or that. I can write a espresso mode myself in a day. But i doubt most who have coded elisp for 10 years can pull off Steve's js2-mode. Not me.

∑ http://xahlee.org/


emacs, unix, line truncation, move by screen line


On Jun 4, 6:39 am, brendan.hal...@ul.ie (Brendan Halpin) wrote:
> Attempted thread-jack: why use visual-line-mode instead of
> longlines-mode?

longlines-mode has serious bugs, i believe still so even i haven't used it since emacs 23.1 a year or 2 ago.

basically, whenever large chunk of text is inserted or removed in a buffer (either manually, or sometimes automatically by commands such as patch and version control etc), then the text will be screwed up... missing parts or something i forgot.

there are 1 or more bug reports of it in emacs bug track. If i recall correctly, the situation is that it's hard to fix, because longlines-mode was a hack for lack of visual line move, and i think it is done by basically just inserting line-breaks in the background but display and save it otherwise. (i haven't actually looked at the code though)

the visual line move feature is a critical feature in emacs. Before
emacs 23, there are a few packages or code that tries to introduce the
visual line move feature (see emacswiki), and longlines-mode is one of
them. However, because it is such a fundamental feature, it is hard
for a 3rd-party elisp package to get it correct. They all have major

i think Emacs 23.2's move by visual line feature is great because:

• it fixed a frequently asked feature. (e.g. i think ALL editors/IDEs after mid 1990s, move by visual line )

• it fixed a issue that 3rd party elisp packages cannot address well.

Btw, who actually coded the visual line mode? I can't find the info. I like to document it in my emacs pages.


Personally, i find moving by visual line is not just a good feature, but a critical one, with consequences that effect the evolution of language design and thinking, long term. The hard-coded lines is fundamentally introduced by unix and C gang, and brain damaged a whole generation of coders.

I've written about 7 essays addressing this point in the past 10 years. See:

• Xah on Programing Languages

See the articles under the Formatting section.

Each of these is written in a different context, but they essentially discuss the same thing. That is, the importance of separating appearance/formatting from semantic or logical structure.

Here's a synapses on how each article relates to the line move visual issue.


• The Harm of Hard-wrapping Lines

A introduction. (written as a diatribe )


• Tabs versus Spaces in Source Code

introduces the idea as semantic based formatting vs hard-coded formatting.


• Plain-Text Email Fetish

• Unix, RFC, and Line Truncation

Shows some connection of the hard-coded habit from unix.


• A Simple Lisp Code Formatter

A example of what actually can happen when hard-coded formatting hasn't become the conventional thought.


• A Text Editor Feature: Extend Selection By Semantic Unit

Another example of what could happen if unix didn't made people to think about hard-coded short lines.


• Fundamental Problems of Lisp

Half of the essay, discuss the above issues with respect to lisp the language, and consequences.

∑ http://xahlee.org/

hi Mark Crispin,

On Jun 4, 11:18 am, Mark Crispin wrote:
> This is why UNIX and C accomplish things.  They were based upon
> accomplishing something useful rather than promoting an ideology.

maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix, and the whole lisp culture and thinking is contrary to unix and C.

> It sounds like Microsoft Word is more suitable for the sort of work that
> you do.  Perhaps you ought to use Word instead of seeking to make emacs
> become more like Word.

speaking of Microsoft Word, i wait for dinosaurs like u to die. The question is, can we recruit enough new generation of coders to emacs fast enough before emacs extinguishes.


∑ http://xahlee.org/


emacs extension language, pymacs, ejacs


On May 31, 5:57 am, Bernardo Barros wrote:
> I was reading about this topic on the group homepage. One thing I
> though was how Emacs is really great because of Emacs Lisp, since it
> is a real programming language and an text editor at the same time.
> But maybe one of the reasons that Emacs is not so popular nowadays is
> that Lisp itself is also not so popular anymore either. Someone told
> something about less than 1%.
> I have just checked the Pymacs project [http://www.emacswiki.org/emacs/
> PyMacs] and I though to myself: "oh, that's a nice one, I could use
> Python instead of elisp to extend Emacs, I would like that a lot!".
> I'm a young guy and I don't work with lisp languages at all except
> when I use Emacs and Lilypond (a music notation program).
> But it seems to me that PyMacs is not a mature project yet, I would
> like to see this as a major version of Emacs. Maybe this is the way
> for Emacs 24 or 25? :-)

Yeah, i think having multiple language support is a good thing, but i think practically that's just not feasible, for emacs being started in the 1980s.

Note that the PyMacs guy switched to vi, and wrote a big article about it.

here's the pymacs home page:

here's his rant, i think it used to be named something like “why i switched to vi”

note the date there 2003.

∑ http://xahlee.org/


LanX [2010-06-01 01:33+0200] writes:
I really enjoyed reading this blog on ejacs

On Jun 1, 3:28 am, Helmut Eller wrote:
«Why didn't he write the Javascript interpreter in Javascript?  Or why did he write a Javascript interpreter at all?»

Gah. Apparently you haven't spend much time reading the article.

Steve created it because he's creating a javascript mode for emacs, with the goal of it being a full IDE beating any other javascript IDEs.

That mode eventually became js2-mode. The js interpreter engine was a discarded by-product, because he ends up writing another engine. The name “ejacs” was attached to it later, and became a separate project, currently of little practical use.

Steve has hinted in his blog, that he has the goal of making js a alternative to elisp for extending emacs.

> The only interesting
> place to run and debug Javascript is inside a browser with complete DOM
> access anyway.

yes but not really. JS as a scripting lang is used in lots of applications, in Flash, and lots others. (see wikipedia for full list) Basically, it has became practically what Scheme used to be or envisioned to be in academia, and replaced what perl, tcl, tried to be in the industry in the 1990s.

Personally i think that's very good.


• Proliferation of Computing Languages

∑ http://xahlee.org/

emacs text selection highlighting and transient-mark-mode


On Jun 2, 11:00 am, abashere wrote:
> I find the new always-on transient mark is causing more repair time
> than coding time.
> - turn off Active Region Highlighting in the Options and in the .emacs
> ( '(transient-mark-mode nil) )
> - highlight line 25 of the file , with mouse left button. release
> button.
> - scroll down 400 lines with the editor scroll bar (left|right mouse
> button pressed)
> - release mouse on scroll bar, move to file and then paste with middle
> mouse in new position.
> -WRONG !!
> For 15 years this was no problem. But now, using the scroll bar to
> move the visible portion of the file OVER_RIDES my selection of NO
> TRANSIENT-MARK! and turns it back 'on', selects the intervening 400
> lines and pastes those into the file.

maybe you should leave the transient-mark-mode on and stop using a mouse?

note that emacs behaves differently if you use the mouse.

For example, turn text selection highlighting on, then select a text, then, pressing delete key will not delete the text if you used keyboard to made the text selection, but will if the text selection is made with a mouse.

this is in my opinion a bad feature, as it makes things more complex.

better would be simply to always make the delete key delete text selection, or typing over it. (which is done by having “(delete-selection-mode 1)”.)

> Can I remove the Transient-mark function entirely? Make the first
> action of the function a return? Obviously, the option is meaningless
> now.

i don't think there's a easy way, and it doesn't really make sense to “remove the function”. Emacs's transient mode system is builtin in lots of commands and functions. (see the var transient-mark-mode) If you don't really like it, turning it off should be all you need, like this:

(transient-mark-mode 0)

Note that “(transient-mark-mode nil)” is incorrect.

it's not clear from your post whether you are making a complaint or asking a question. The following articles perhaps might be of interest:

• Emacs: What's Region, Active Region, transient-mark-mode?

• New Features in Emacs 23

∑ http://xahlee.org/