Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun <cthun_117@qmail.net.au>]

On 23/02/2011 6:54 PM, Jason Earl wrote:
> On Wed, Feb 23 2011, Cthun wrote:
>
>> 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.