>> On 23/02/2011 2:22 PM, Jason Earl wrote: >>> On Wed, Feb 23 2011, Cthun wrote: >>>> This runs into trouble if you do something drastic you later want to >>>> undo.
>>> Actually, Emacs warns you before it makes drastic changes to an autosave >>> file. This at least gives you the opportunity to do something about it.
>> Oh, wonderful.
>> Do you know what I'd do if I was in the middle of typing some stuff >> into a text editor after just having deleted a bunch of stuff and then >> suddenly a box popped up saying something about autosaving and drastic >> changes and yadda yadda yadda but I didn't have time to read it before >> one of my enter keypresses (intended for the actual document I was >> typing into when the box interrupted me) triggers one of the dialog's >> buttons (which?) and it disappears again (and does who knows what to >> my hard drive?).
>> I'd delete that editor and go get a new one, that's what. :)
> So would I, but, of course, that's not what Emacs does. It just turns > off auto-save and warns you in the mini-buffer.
In other words, instead of actually warning you, autosave just quietly and unobtrusively stops working and unless you look in a particular spot on the screen for some reason you won't know about it. Hardly a good alternative, Earl. In fact, if the popup's default button was Cancel, Earl, at least the popup scenario would cause you to realize that *something* had happened.
In the modern age we have something nifty and newfangled called tray notification, Earl. Also these amazing new gadgets called "sound cards". It is possible to alert a user to a status change without stealing the input focus, Earl. All too few application designers take advantage of that to both ensure that a message gets the user's attention and avoid undesired focus theft, though, Earl.
> And, like all things Emacs, if you do not like the default you can > change it easily.
For values of "easily" that might make sense to a quantum physicist, Earl.
>>> The solution, of course, is to manually save *before* the fork.
>> Yes, but the reality is that people will sometimes forget to do so, or >> in that order.
> It would seem to me that you would basically have to be the sort of > person that *relies* on the auto-save feature to do things in any other > order.
What does your classic erroneous presupposition have to do with Lisp, Earl?
> If I am manually going fork a file then it seems like I would > want to make sure that I forked from a known good spot.
You might think of it only after making a large selection and beginning to type over it, Earl, if the drastic alteration that occurred to you was a spur-of-the-moment thing. Not everyone takes a careful, measured, chess-game-like approach to text editing, Earl.
> I used to work on a help desk and my experience says that most people > don't even know that their editor has an auto-save (or how to get the > auto-save files it creates) until something tragic happens.
Precisely one of my points, Earl.
> They certainly don't expect their editor to magically save the correct > state of a file that they didn't manually save.
Precisely my *original* point, Earl. Thus manual save should be easy and painless, Earl. Thus manual save should be bound to ctrl-S, Earl.
>>> I real life I don't think that this is much of a problem, especially >>> with Emacs which has infinite undo
>> Infinite undo? On what planet? When I experimented with it, back in >> college, I found the undo to just toggle undo/redo like Windows >> Notepad's. (I ended up experimenting also with LSD and mescaline and >> decided on none of the above.)
> I thought it was infinite undo, but according to the manual the default > limit is 12,000,000 bytes. Needless to say, I have never actually ran > out of undo information.
When the actual behavior is to just toggle between the two most recent document states, Earl, you'd have to be deleting most of a massive log file to hit that limit.
>>> What's more, Emacs is flexible enough that you can easily set up >>> whatever sort of auto-save functionality that you think you want.
>> If you're a computer programmer with time to spare reprogramming the >> editor instead of actually doing your job, perhaps.
> I'm just saying that, if you care about auto-save as much as you seem to > care about auto-save, that Emacs gives you options that other tools do > not.
Options a quantum physicist might manage to successfully use, Earl.
> Personally, other than changing where Emacs saves its auto-save > files I just stick with the defaults.
Since you are indubitably not a quantum physicist, this is probably a wise course, Earl. Of course, "not using emacs" would probably be a wiser one.
> I personally think that Emacs' superior auto-save features would be a > strange reason for choosing Emacs, but who am I to judge.
What does your classic erroneous presupposition have to do with Lisp, Earl?
>>> Emacs can do that. It has an auto-save-hook that you can add code to
>> and ten million ways to subtly or drastically-but-irrecoverably fuck >> things up if you make some subtle mistake doing so, no doubt.
>> Thanks, but no thanks.
> Obviously any time you are writing code you have the opportunity to code > something that doesn't work.
This is why most of us prefer our applications' developers to have done that work for us, Earl, instead of leaving the job incomplete and us to finish the last little bit of it. That way the whole user base gets the benefit of one developer's work and testing and debugging, Earl, instead of each one separately reinventing the wheel and many coming up with a square one.
> On the other hand, computers are far less likely to "forget" a step > than you or I are. Automation is generally a good thing.
A good argument against not leaving features missing that your users will have to either work around or use your application's internal scripting language to implement, Earl.
>>>> Sequences of numbered files used to risk filling up the filesystem, >>>> too, but not with text files in this day and age.
>>> On the bright side Emacs can be made to do whatever makes you the >>> happiest.
>> Can it be made to cut itself, scream like a thing tortured, and then >> die? ;)
> That seems like an odd thing to want from a text editor, but yes, you > can teach emacs to do that. I even tested it.
A text editor inbuilt scripting language is not going to have sound card APIs, Earl, so this statement is highly implausible.
> (defun scream () > (message "Arrgggh!"))
Hardly a real scream, Earl.
>>> Very few other programs have anywhere near that sort of flexibility.
>> If I want that much flexibility I'll look at that Russian mail-order >> catalog. There *is* something to be said for structure and stability >> in fundamental, daily-use tools. And standards-adherence.
> Emacs has been adhering to the same standards almost as long as I have > been alive.
What does your classic unsubstantiated and erroneous claim have to do with Lisp, Earl? Emacs adheres to no standards; it is an iconoclast in virtually every way.
>>> For most folks, however, the defaults are what they want.
>> Wait a minute. I thought you just said that the Emacs defaults are >> what most people want. But that's clearly impossible, so I can only >> presume that your post got garbled in transit. Care to repost whatever >> you'd said at this point?
> Emacs' defaults for auto-save are what most people want.
Emacs itself is not what most people want, Earl, or Emacs would have market share to rival that of Windows. This is clearly not actually the case, though, Earl.
On Wed, Feb 23, 2011 at 7:13 AM, Cthun <cthun_...@qmail.net.au> wrote: > The other option is auto-save to some temporary file, or a sequence of > numbered files. Of course if you have a power outage or something now you > have to go hunting for where the darn thing saved these. Depending, they may
More likely, the editor will just ask you if you want to recover the auto-saved version the next time you open the file. (Or do what Emacs does, which is open the file normally but display a message suggesting you execute "M-x recover-this-file".)
> even be vulnerable to being erased by an automatic temp file cleanup script > before you get to them.
If you choose to run such a script, I would recommend using one that only deletes files that are several days old.
> Sequences of numbered files used to risk filling up the filesystem, too, but > not with text files in this day and age.
If you're concerned about that, customize kept-old-versions and/or kept-new-versions to manage the number of backup versions that are saved.
> I'll let you judge whether I qualify as "Emacs power user", but I use > the mouse and the arrow keys fairly heavily.
Interesting input.
There are a few Ctrl key combinations that are note easy to type for example C-b so overtime I have got used to using the arrow keys and the trackpad quite a bit.
On Feb 23, 12:15 pm, Rafe Kettler <rafe.kett...@gmail.com> wrote:
> You must be a Windows user. You must also not be an Emacs power user, > because you think it's acceptable to use the arrow keys as cursors. If > you don't, please use C-b, C-f, C-p, and C-n in place of the arrow > keys. It dramatically improves speed.
Don't go down that path: "vi" has a way-better key binding for cursor movement!!
Stefan Monnier <monn...@iro.umontreal.ca> writes: >> You must be a Windows user. You must also not be an Emacs power user, >> because you think it's acceptable to use the arrow keys as cursors. If >> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow >> keys. It dramatically improves speed.
> I'll let you judge whether I qualify as "Emacs power user", but I use > the mouse and the arrow keys fairly heavily.
Ditto with regard to the arrows. Most people I know who use emacs all use the arrows keys too.
On Feb 24, 6:43 am, fortunatus <daniel.elia...@excite.com> wrote:
> On Feb 23, 12:15 pm, Rafe Kettler <rafe.kett...@gmail.com> wrote:
> > You must be a Windows user. You must also not be an Emacs power user, > > because you think it's acceptable to use the arrow keys as cursors. If > > you don't, please use C-b, C-f, C-p, and C-n in place of the arrow > > keys. It dramatically improves speed.
> Don't go down that path: "vi" has a way-better key binding for cursor > movement!!
it should be noted, that vi's jkl; is not optimal. Better is ijkl in inverted T shape.
also, note that vi's Esc is FAST route to RSI. See:
also note, emacs keys and vi keys, are not out of much conscious design. Like unix tool bags, they are piled on over the years without much thinking. It was good enough, at the time. In fact, most things in life are like that. They are not anywhere close to optimal in any sense.
The following is a quote from Daniel Weinreb (danweinreb.org) , 2008-06-01, on comp.emacs newsgroup. Source.
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.
This design by evolution applies to Keyboard hardware itself. As it is, it's the worst shit possible. It was good enough in the 1970s, where there are just a handful of programers in the world. And today, but vast majority of people (mom & pop, who occasionally chat online or write email), it's good enough! Even for most programers, who's finger actually dance on keyboard perhaps no more than accumulated 3 hours a day, it's good enough! But for data entry clerks, or programers who seriously type a lot or write docs all day, it's hello RSI. That's why we have so many problems on keybinding debates, radical input device designs, dvorak advocacy, and RSI is a serious medical problem. See:
this also applies to key layouts. e.g. we all know the story of qwerty and dvorak. But in my study, i found that it's just not that. Most international layout are ergonomic garbage. See:
the emacs's keybinding, in my assessment, of all possible keybinding systems one could devise, with the PC keyboard as given constraint, i rate it near the bottom. Better than random assignment, but not much.
One thing damaging is that GNU Emacs has a tendency to refuse change, much like most unix-bag. Emacs's keybinding today is pretty much identical to emacs of 1970s. But, the landscape of computing has changed tremendously in past 30 years.
why most emacs people don't see this but in fact advocates emacs keybinding? My guess is that most people have not studied the issue. There are tens of thousands of things in life, we learned and use daily by habit, but never thought about it seriously. If you are interested, i think if you actually start to study keybinding, say, in the next 30 days, your job is to research keybinding design 8 hours a day for 30 days, i think you'll have a changed view. (no, i don't mean to brag about how many hundreds of software you've used in past n decades. Me too bro. I mean: stop dead and spend 8 hours a day for the next 30 days to do nothing but study keybindings. Yours truely have done so.)
Richard Riley <rile...@googlemail.com> writes: > Stefan Monnier <monn...@iro.umontreal.ca> writes:
>>> You must be a Windows user. You must also not be an Emacs power user, >>> because you think it's acceptable to use the arrow keys as cursors. If >>> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow >>> keys. It dramatically improves speed.
>> I'll let you judge whether I qualify as "Emacs power user", but I use >> the mouse and the arrow keys fairly heavily.
> Ditto with regard to the arrows. Most people I know who use emacs all > use the arrows keys too.
Glad to hear it. I was starting to think I was doing something wrong.
Sure I have to move my hand to find the arrow keys, but the keys are easy to find without looking.
More important, every once in a while I actually use a program other than Emacs. (There I admitted it.) My mind is too feeble to adapt to using different keystrokes for the same thing.
I just read your "modernizing Emacs" page [1] and I wonder, have you looked at the "Emacs Starter Kit" [2] (or /shameless-plug/ my literate version of the same [3]). I think that by being distributed as a configuration for GNU emacs such `starter-kits' could serve as a good place to test and/or prove the utility of eventual changes to GNU emacs.
Have you considered wrapping your modernization suggestions up into such a starter kit? It seems that if such a kit gained popularity it would raise the chances of general Emacs adoption.
Also, more pursuant to the points in your previous email, I wonder if you can recommend a good set of key-bindings for common commands such as cursor movement, file save-open-close, buffer-movement etc...
Cheers -- Eric
as a side note, I've been using Emacs for ~5 years, and over the last year have developed hand pains which were greatly relieved by using a Kinesis keyboard.
> On Feb 23, 12:15 pm, Rafe Kettler<rafe.kett...@gmail.com> wrote: >> You must be a Windows user. You must also not be an Emacs power user, >> because you think it's acceptable to use the arrow keys as cursors. If >> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow >> keys. It dramatically improves speed.
> Don't go down that path: "vi" has a way-better key binding for cursor > movement!!
DUCK AND COVER!
Goggles on, NOW!
Do NOT look directly into the flash!
-- In <iijn58$cc...@news.albasani.net>, Lew admitted: > The JLS is obfuscatory in parts
> Also, more pursuant to the points in your previous email, I wonder if > you can recommend a good set of key-bindings for common commands such as > cursor movement, file save-open-close, buffer-movement etc...
Is there something wrong with arrows, ctrl-S/ctrl-O, pageup, pagedn, etc.?
> On Wed, Feb 23, 2011 at 7:13 AM, Cthun <cthun_...@qmail.net.au> wrote:
>> The other option is auto-save to some temporary file, or a sequence of >> numbered files. Of course if you have a power outage or something now you >> have to go hunting for where the darn thing saved these. Depending, they may
> More likely, the editor will just ask you if you want to recover the > auto-saved version the next time you open the file. (Or do what Emacs > does, which is open the file normally but display a message suggesting > you execute "M-x recover-this-file".)
>> even be vulnerable to being erased by an automatic temp file cleanup script >> before you get to them.
> If you choose to run such a script, I would recommend using one that > only deletes files that are several days old.
>> Sequences of numbered files used to risk filling up the filesystem, too, but >> not with text files in this day and age.
> If you're concerned about that, customize kept-old-versions and/or > kept-new-versions to manage the number of backup versions that are > saved.
> On Feb 23, 12:15 pm, Rafe Kettler <rafe.kett...@gmail.com> wrote: >> You must be a Windows user. You must also not be an Emacs power user, >> because you think it's acceptable to use the arrow keys as cursors. If >> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow >> keys. It dramatically improves speed.
> Don't go down that path: "vi" has a way-better key binding for cursor > movement!!
Possibly, assuming you're in "normal mode" or whatever they call it. And assuming that you use QWERTY.
> I just read your "modernizing Emacs" page [1] and I wonder, have you > looked at the "Emacs Starter Kit" [2] (or /shameless-plug/ my literate > version of the same [3]). I think that by being distributed as a > configuration for GNU emacs such `starter-kits' could serve as a good > place to test and/or prove the utility of eventual changes to GNU emacs.
> Have you considered wrapping your modernization suggestions up into such > a starter kit? It seems that if such a kit gained popularity it would > raise the chances of general Emacs adoption.
> Also, more pursuant to the points in your previous email, I wonder if > you can recommend a good set of key-bindings for common commands such as > cursor movement, file save-open-close, buffer-movement etc...
> Cheers -- Eric
> as a side note, I've been using Emacs for ~5 years, and over the last > year have developed hand pains which were greatly relieved by using a > Kinesis keyboard.
i think several alt emacs distributions all does that.
Lennart's EmacsW32+Emacs does that for Windows.
my humble ErgoEmacs does it.
David Reitter's AquamacEmacs does it.
all these by default have keybindings that's radically different from GNU Emacs. (in Lennart's EmacsW32 you have to turn it on.) They also add various UI improvements, and lots of other packages to make it more easier to use or more powerful.
i know that EmacsW32 and AquamacsEmacs are quite popular too. (my guess is that their combined user is more than the number of GNU emacs users counting all from linux distros.)
from what i've seen in GNU emacs mailing list, any little suggestion about incorporating any UI change into GNU Emacs is met with major resistance and debate. Almost everytime, giant fireball blows up in the list. I don't know if that's good or bad, for FSF or for the world, but that's what i've seen. (both Lennart and Reitter are on the list as accepted contributors)
... Nice going with Kinesis. I'd love one too.
i haven't looked into what's in emacs starter kit much...
> all these by default have keybindings that's radically different from > GNU Emacs. (in Lennart's EmacsW32 you have to turn it on.) They also > add various UI improvements
I'd be more impressed by that claim if it were actually difficult to do. But making emacs segfault on startup would qualify as a UI improvement, so ...
> from what i've seen in GNU emacs mailing list, any little suggestion > about incorporating any UI change into GNU Emacs is met with major > resistance and debate. Almost everytime, giant fireball blows up in > the list.
The correlation between emacs and flamewars is well known by now.
-- In <iijn58$cc...@news.albasani.net>, Lew admitted: > The JLS is obfuscatory in parts
> from what i've seen in GNU emacs mailing list, any little suggestion > about incorporating any UI change into GNU Emacs is met with major > resistance and debate. Almost everytime, giant fireball blows up in the > list. I don't know if that's good or bad, for FSF or for the world, but > that's what i've seen. (both Lennart and Reitter are on the list as > accepted contributors)
For what it's worth, it's not personal. A giant fireball blows up when _anybody_ suggests UI changes in Emacs. The UI is an important part of what Emacs is, so it's bound to give rise to discussion when anybody wants to change it.
On Feb 25, 12:16 pm, Alan Mackenzie <a...@muc.de> wrote:
> For what it's worth, it's not personal. A giant fireball blows up when > _anybody_ suggests UI changes in Emacs. The UI is an important part of > what Emacs is, so it's bound to give rise to discussion when anybody > wants to change it.
Hi Alan.
I remember you suggesting some time an idea that you called 'emacsicality' -- basically a grain of customizability larger than individual key/function binding or even major mode. [Subsequently I tried to look it up but my google-fu failed me]
Do you remember what this suggestion was?
In any case do you realize that this statement of yours suggests that *fact* of emacs encrustation is opposed to the *philosophy* of infinite customizability?
Tim X <t...@nospam.dev.null> writes: > Cthun <cthun_...@qmail.net.au> writes:
>> On 22/02/2011 2:47 PM, Alan Mackenzie wrote: >>> There seems to be a contradiction between those last two paragraphs. >>> Saving buffers and finding files are relatively rare operations which >>> thus shouldn't be given very easy to press key sequences like C-s and >>> C-o.
>> Where do you live where software never crashes and the electricity never goes >> out? Most of us learn to save very frequently to limit how much we'll have to >> do over again if the power goes out or whatever.
> Most of us use smart editors that auto-save regularly and free the user > form having to do this manually all the time. Compared to other > operations, saving files and opening files are less frequent operations > and do not need to be as convenient keystrokes as other more frequent > editing operations.
Anything I'm working on that would be expensive to lose goes under version control anyway.
> On Feb 25, 12:16?pm, Alan Mackenzie <a...@muc.de> wrote: >> For what it's worth, it's not personal. ?A giant fireball blows up >> when _anybody_ suggests UI changes in Emacs. ?The UI is an important >> part of what Emacs is, so it's bound to give rise to discussion when >> anybody wants to change it. > Hi Alan. > I remember you suggesting some time an idea that you called > 'emacsicality' -- basically a grain of customizability larger than > individual key/function binding or even major mode. [Subsequently I > tried to look it up but my google-fu failed me] > Do you remember what this suggestion was?
I don't remember using "emacsicality" (but it's the sort of "word" I would use). An idea I once had was "Emacs personalities" - there'd be classic Emacs, CUA Emacs, possibly Ergo Emacs each callable from the command line as its own command. So you might start the editor with the command % cua-emacs . The commands would all be aliases (or the W32 equivalent, whatever that is) of the plain emacs command. It would be implemented by a "personality" configuration file, loaded before site-start.el.
The idea would be to allow newbies, who might otherwise be overwhelmed by configuration, to get a taste of the variety possible under Emacs.
I think the idea came up when the making of transient-mark-mode on by default was being discussed on the Emacs development list. That discussion was more like a supernova than a fireball. ;-)
> In any case do you realize that this statement of yours suggests that > *fact* of emacs encrustation is opposed to the *philosophy* of infinite > customizability?
:-). I don't really think so. More precisely, discussions about UI are nearly always about the _defaults_, and the wisdom, or otherwise, of changing them. Pretty much any new UI feature is welcome, provided it is an option which is disabled by default. The stability of the default features doesn't in any way contradict the philosophy of infinite customisability.
My view is that the defaults should remain very stable indeed, (but not totally frozen). At the same time I have an extensive .emacs.
On Feb 25, 11:54 pm, Alan Mackenzie <a...@muc.de> wrote:
> My view is that the defaults should remain very stable indeed, (but not > totally frozen). At the same time I have an extensive .emacs.
Maybe one basic/generic kind of personality/emacsicality would be say for emacs 23 to 'become' emacs 22 or 21 etc. IOW the 'totally frozen' should be an available option. I say this because recently there was a fireball (supernova?) with Mark Crispin getting upset with visual- line-mode changing basic newline behavior. On the one hand the new is generally accepted to be better behavior, on the other it broke old code. Maybe being able to say:
$ emacs23 --emacsicality=emacs22 ...
would be good to have?
[I personally would like more progress even at the cost of more breakage a la Xah. Just exploring if a win-win is possible...]
Heres a possible list of emacsicalities: emacs22, emacs21 cua dvorak xemacs?
It strikes me that a novel would probably benefit more from version control than a program. A lost piece of prose seems like it would be harder to re-implement than a lost piece of functionality. And plenty of prose gets deleted and mashed around during rewrites and editing.
>> Anything I'm working on that would be expensive to lose goes under >> version control anyway. > Then woe betide you if you ever work on, say, a novel rather > than a computer program.
Don't know about novels, but at least revision control works very well for academic publications.
