A wish, a plea

A wish, a plea

[Hacksaw]

Maybe this is the wrong place for this, but I'm kind of upset.

See, I use Emacs to write (duh!), and I do a lot of it. If I get an 
idea, I write it down quickly, so I can develop it at my leisure.

Mostly I write fiction.

This is important becuase if I'm writing C or Python, I think about the 
file name first.

When I'm writing fiction, I'm thinking about the story.

So I started writing, and I wrote for quite a while, it was really 
flowing well, and I thought, hey, I should save, because I don't want to 
lose this, but in my reverie, I hit the ^X^C first.

And I was writing in the scratch buffer.

I bet if we took a poll, the number of emacs users who actually use the 
scratch buffer for it's intended usage is very, very low. Most either 
find a file, or open a new one.

But I wasn't in programming mode, so I was in scratch, and lost 
everything I was writing, because scratch isn't backed up by anything.

I'd be happy with a lisp snippet that made it so that scratch never 
showed up again. I can make a lisp-interactive mode file if I want it. 
In fact, when I do anything with lisp, I make a test file, and turn it 
to lisp interactive.

But my real wish is that *scratch* would just go away. IMHO, it's 
usefulness is limited. And the chances that something important gets 
lost because of a careless keystroke is too high.

Please help a poor writer?

Re: A wish, a plea

[Davis Herring]

> But I wasn't in programming mode, so I was in scratch, and lost
> everything I was writing, because scratch isn't backed up by anything.

The simple answer here is M-x auto-save-mode.  You can of course put
(auto-save-mode 1) in .emacs, since *scratch* is current when it runs. 
Actually getting rid of *scratch* is somewhat harder.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: A wish, a plea

[Stefan Monnier]

>> But I wasn't in programming mode, so I was in scratch, and lost
>> everything I was writing, because scratch isn't backed up by anything.

> The simple answer here is M-x auto-save-mode.  You can of course put
> (auto-save-mode 1) in .emacs, since *scratch* is current when it runs.

It may work.

> Actually getting rid of *scratch* is somewhat harder.

Maybe an alternative is to make it read-only.
Or maybe add a first-change-hook that requests a file name from the user?


        Stefan

Re: A wish, a plea

[Davis Herring]

>> The simple answer here is M-x auto-save-mode.  You can of course put
>> (auto-save-mode 1) in .emacs, since *scratch* is current when it runs.
>
> It may work.

Does for me as the only line in .emacs, if you were doubting.

>> Actually getting rid of *scratch* is somewhat harder.
>
> Maybe an alternative is to make it read-only.
> Or maybe add a first-change-hook that requests a file name from the user?

That's a neat idea, the hook.  Perhaps:

(defun set-buffer-file-name (name)
  "Set the current buffer's file name, prompting interactively."
  (interactive "FNew file name: ")
  (setq buffer-file-name name))
(defun guarantee-buffer-file-name ()
  "Prompt the user for a file name for the current buffer.
Do nothing if that buffer has a file name already or is in a special mode."
  (unless (or buffer-file-name (eq (get major-mode 'mode-class) 'special))
    (call-interactively 'set-buffer-file-name)))
(add-hook 'first-change-hook 'guarantee-buffer-file-name)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: A wish, a plea

[Richard Stallman]

I do not like the idea of asking for a file name when the user enters
a character in *scratch*.  However, to make a warning if the user puts
more than a little text in *scratch* and does not evaluate any of it
as Lisp expressions would be better.  The warning could pop up in a
window and say, "Don't use *scratch* to enter text you want to save in
a file.  If you have already started doing that, save it in a file now
with C-x C-w FILENAME RET."

Re: A wish, a plea

[Lennart Borgman (gmail)]

Hacksaw wrote:
> But my real wish is that *scratch* would just go away. IMHO, it's 
> usefulness is limited. And the chances that something important gets 
> lost because of a careless keystroke is too high.
> 
> Please help a poor writer?


No need to change Emacs. Just put something like this in your .emacs:

   (let ((b (get-buffer "*scratch*")))
     (when b
       (kill-buffer b)))

Happy writing, Hacksaw!

Re: A wish, a plea

[Karl Fogel]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> Hacksaw wrote:
>> But my real wish is that *scratch* would just go away. IMHO, it's
>> usefulness is limited. And the chances that something important gets
>> lost because of a careless keystroke is too high.
>>
>> Please help a poor writer?
>
>
> No need to change Emacs. Just put something like this in your .emacs:
>
>   (let ((b (get-buffer "*scratch*")))
>     (when b
>       (kill-buffer b)))
>
> Happy writing, Hacksaw!

I don't think Hacksaw was writing to ask us for help in solving his
problem.  He was writing to ask us to help future users *avoid* what
happened to him.

Emacs gives the user total control, but that does not diminish the
importance of choosing reasonable defaults.  The current *scratch*
buffer is a punitive default; Hacksaw is suggesting that we choose
another default.

-Karl

Re: A wish, a plea

[Lennart Borgman (gmail)]

Karl Fogel wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> Hacksaw wrote:
>>> But my real wish is that *scratch* would just go away. IMHO, it's
>>> usefulness is limited. And the chances that something important gets
>>> lost because of a careless keystroke is too high.
>>>
>>> Please help a poor writer?
>>
>> No need to change Emacs. Just put something like this in your .emacs:
>>
>>   (let ((b (get-buffer "*scratch*")))
>>     (when b
>>       (kill-buffer b)))
>>
>> Happy writing, Hacksaw!
> 
> I don't think Hacksaw was writing to ask us for help in solving his
> problem.  He was writing to ask us to help future users *avoid* what
> happened to him.
> 
> Emacs gives the user total control, but that does not diminish the
> importance of choosing reasonable defaults.  The current *scratch*
> buffer is a punitive default; Hacksaw is suggesting that we choose
> another default.

Ah, yes, you are right. Sorry. I myself use to hate to get the kind of 
response I gave to Hacksaw ...

Re: A wish, a plea

[Nic James Ferrier]

Karl Fogel <kfogel@red-bean.com> writes:

> Emacs gives the user total control, but that does not diminish the
> importance of choosing reasonable defaults.  The current *scratch*
> buffer is a punitive default; Hacksaw is suggesting that we choose
> another default.

I agree.

I don't use it as a default.

I really do use *scratch* for all sorts of things. But it shouldn't be
the default.

Maybe a ~/notes or ~/.emacs.d/notes ?

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[Frank Schmitt]

Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:

>> Emacs gives the user total control, but that does not diminish the
>> importance of choosing reasonable defaults.  The current *scratch*
>> buffer is a punitive default; Hacksaw is suggesting that we choose
>> another default.
>
> I agree.
>
> I don't use it as a default.
>
> I really do use *scratch* for all sorts of things. But it shouldn't be
> the default.
>
> Maybe a ~/notes or ~/.emacs.d/notes ?

That's a very good idea IMO.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: A wish, a plea

[Taylor Venable]

Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>> Emacs gives the user total control, but that does not diminish the
>> importance of choosing reasonable defaults.  The current *scratch*
>> buffer is a punitive default; Hacksaw is suggesting that we choose
>> another default.
>
> I agree.
>
> I don't use it as a default.
>
> I really do use *scratch* for all sorts of things. But it shouldn't be
> the default.
>
> Maybe a ~/notes or ~/.emacs.d/notes ?

As far as ~/notes goes, what if it already exists?  And doesn't have
anything to do with Emacs?  If I started Emacs for the first time and
saw some seemingly random text file, I'd be confused.

An empty buffer, on the other hand, may not be a bad idea.  Maybe in
fundamental mode.

I actually don't have a problem with *scratch* because I see it as
kind of a starting area.  Emacs isn't second-guessing what I want to
do, it's very close to having a blank slate.  In fact, it's a lot like
booting your computer -- once it loads you've got the whole command
set available to you.  If you want to write a file, read your email,
or play Tetris, it's up to you to input the command to do so.  And
besides, I do use *scratch* frequently to work on various smaller
Emacs customizations.

My counter-wish (and plea) would be that if any changes are made to
the default behavior, that an option be added to ensure that my
*scratch* is dutifully created each time I load Emacs.

Best regards.

-- 
Taylor Venable
taylor@metasyntax.net
http://www.metasyntax.net/

Re: A wish, a plea

[Juanma Barranquero]

On 6/22/07, Karl Fogel <kfogel@red-bean.com> wrote:

> Emacs gives the user total control, but that does not diminish the
> importance of choosing reasonable defaults.  The current *scratch*
> buffer is a punitive default; Hacksaw is suggesting that we choose
> another default.

Which is as simple as setting `buffer-offer-save' to t in *scratch*
when it is first created. That's what I've been doing for years
because, *yes*, the default is unhelpful, to say the least.

             Juanma

Re: A wish, a plea

[Karl Fogel]

Hacksaw <hacksaw@hacksaw.org> writes:
> So I started writing, and I wrote for quite a while, it was really
> flowing well, and I thought, hey, I should save, because I don't want
> to lose this, but in my reverie, I hit the ^X^C first.
>
> And I was writing in the scratch buffer.
>
> I bet if we took a poll, the number of emacs users who actually use
> the scratch buffer for it's intended usage is very, very low. Most
> either find a file, or open a new one.
>
> But I wasn't in programming mode, so I was in scratch, and lost
> everything I was writing, because scratch isn't backed up by anything.

I agree, this should be changed.

When Emacs is invoked with no file arguments, there's no point the
default buffer be a Lisp interaction buffer.  After all, most users
don't know what to do in such a buffer -- and those who *do* know are
much more likely to know how to customize Emacs to start with a Lisp
Interaction buffer anyway, if they really to!

Meanwhile, a "*scratch*" buffer that were set to trigger a
save-to-file query (if modified) on exit would prevent data-loss
events like the one Hacksaw describes.  

It seems like an obvious win; am I missing something?

Two points:

   - I tested with latest "emacs -q" to see if stuff I typed in
     *scratch* would get saved in tmpfile (~/#*scratch*# or
     something), but as far as I can tell, my text was simply lost on
     exit.

   - It's true that "*scratch*" today opens with this message in it:

       ;; This buffer is for notes you don't want to save, and for
       ;; Lisp evaluation.  If you want to create a file, visit that
       ;; file with C-x C-f, then enter the text in that file's own
       ;; buffer.

     But users don't read stuff, we all know that (heck, I'm a user
     who's also a programmer, and I still don't read stuff).  I think
     of that notice as a workaround to a real solution: offering to
     save what the user has typed.

-Karl

Re: A wish, a plea

[Jason Rumney]

Karl Fogel wrote:
>    - It's true that "*scratch*" today opens with this message in it:
>
>        ;; This buffer is for notes you don't want to save, and for
>        ;; Lisp evaluation.  If you want to create a file, visit that
>        ;; file with C-x C-f, then enter the text in that file's own
>        ;; buffer.
>
>      But users don't read stuff, we all know that

Sorry, but I just don't find that argument compelling. It clearly states
that the *scratch* buffer is NOT intended for the use that you and the
original poster are complaining it is not suited for. The fact that you
choose to wilfully ignore that message does not make it a bug.

Re: A wish, a plea

[Karl Fogel]

Jason Rumney <jasonr@gnu.org> writes:
> Karl Fogel wrote:
>>    - It's true that "*scratch*" today opens with this message in it:
>>
>>        ;; This buffer is for notes you don't want to save, and for
>>        ;; Lisp evaluation.  If you want to create a file, visit that
>>        ;; file with C-x C-f, then enter the text in that file's own
>>        ;; buffer.
>>
>>      But users don't read stuff, we all know that
>
> Sorry, but I just don't find that argument compelling. It clearly states
> that the *scratch* buffer is NOT intended for the use that you and the
> original poster are complaining it is not suited for. The fact that you
> choose to wilfully ignore that message does not make it a bug.

I agree that it is the user's fault.

But so what?  Why should that affect UI decisions?  A Lisp Interaction
buffer that doesn't even prompt to save on exit is a pointless default
for the vast majority of Emacs's users.  Putting that message in it
doesn't make it any more useful, it just allows us to transfer blame.

Furthermore, the failure mode of the status quo is much more severe
than the failure mode of being asked to save scratch work that you
don't want to save.  In the first case you lose data; in the second,
you may get annoyed with a question, but you don't lose any data.

-Karl

Re: A wish, a plea

[Nic James Ferrier]

Karl Fogel <kfogel@red-bean.com> writes:

> Furthermore, the failure mode of the status quo is much more severe
> than the failure mode of being asked to save scratch work that you
> don't want to save.  In the first case you lose data; in the second,
> you may get annoyed with a question, but you don't lose any data.

Why do we need to alter *scratch* in this way?

Why can't we just change Emacs so that *scratch* is not the default
buffer for an unconfigured Emacs?


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[Richard Stallman]

    But so what?  Why should that affect UI decisions?  A Lisp Interaction
    buffer that doesn't even prompt to save on exit is a pointless default
    for the vast majority of Emacs's users.  Putting that message in it
    doesn't make it any more useful, it just allows us to transfer blame.

I agree with that approach to the issue.

The reason for the note in *scratch* is to help users avoid lossage.
It isn't meant as a way for us to escape blame.  This isn't a question
of blame anyway.  The question is how to make Emacs better for users.

Some users do use *scratch* as intended, so we should not get rid of it.

We can't get rid of the problem by changing the initial buffer.  Emacs
normally starts up with no files visited, and it has to have some
current buffer.  Whatever that buffer is, it will raise the same issue.

So I think we should do these things:

1. Arrange to set buffer-offer-save to t in *scratch*
if it is ever changed.

2. Turn on auto-saving for it.  (Just how Emacs should check for an
auto-save file for *scratch* could take some fine tuning.)

3. Maybe also start it out read-only.

4. Maybe also pop up a warning if the user types more than 500
self-inserting characters in *scratch* without ever doing Lisp
evaluation.

Re: A wish, a plea

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> We can't get rid of the problem by changing the initial buffer.  Emacs
> normally starts up with no files visited, and it has to have some
> current buffer.  Whatever that buffer is, it will raise the same issue.
>
> So I think we should do these things:
>
> 1. Arrange to set buffer-offer-save to t in *scratch*
> if it is ever changed.

If a buffer starts out unchanged, and is never changed, then
buffer-offer-save won't cause the user to be prompted to save on exit,
right?  (IOW, I think the above is equivalent to just "set
buffer-offer-save to t".)  If we have our own initial text in the
buffer, we can just initialize buffer-modified-p to nil.

> 2. Turn on auto-saving for it.  (Just how Emacs should check for an
> auto-save file for *scratch* could take some fine tuning.)

Yes, for whatever initial selected buffer we have ("*unnamed*" or
"*scratch*" or whatever).

> 3. Maybe also start it out read-only.

What would this solve?

(I've seen a lot of new users flail around with vi, wondering why they
can't just start typing when they open it.)

> 4. Maybe also pop up a warning if the user types more than 500
> self-inserting characters in *scratch* without ever doing Lisp
> evaluation.

As long as we're autosaving, I'm not sure that's necessary.  (I'm
assuming that proposal applies to any default-selected buffer, whether
"*scratch*" or some other name.)

-Karl

Re: A wish, a plea

[Richard Stallman]

    > 3. Maybe also start it out read-only.

    What would this solve?

People would have to type C-x C-q if they really want to put text in
the *scratch* buffer, and that will mean they have to think about
whether they really want to do that.

I am not sure this is a good idea, on the balance, but it certainly
addresses the problem.

    > 4. Maybe also pop up a warning if the user types more than 500
    > self-inserting characters in *scratch* without ever doing Lisp
    > evaluation.

    As long as we're autosaving, I'm not sure that's necessary.  (I'm
    assuming that proposal applies to any default-selected buffer, whether
    "*scratch*" or some other name.)

It could at least in theory.

Re: A wish, a plea

[Sascha Wilde]

Karl Fogel <kfogel@red-bean.com> wrote:

> Hacksaw <hacksaw@hacksaw.org> writes:
>> So I started writing, and I wrote for quite a while, it was really
>> flowing well, and I thought, hey, I should save, because I don't want
>> to lose this, but in my reverie, I hit the ^X^C first.
[...]
>> But I wasn't in programming mode, so I was in scratch, and lost
>> everything I was writing, because scratch isn't backed up by anything.
>
> I agree, this should be changed.

FWIW I object.

I'm actually using *scratch* quite often, as a scratch pad for stuff I
don't want to save (and don't want to be asked, if I want to save them
on exit), as well as for ad-hoc elisp stuff.

I like the feature of having *scratch* at hand from the beginning in
every emacs session, and I would miss it...

[...]
>    - It's true that "*scratch*" today opens with this message in it:
>
>        ;; This buffer is for notes you don't want to save, and for
>        ;; Lisp evaluation.  If you want to create a file, visit that
>        ;; file with C-x C-f, then enter the text in that file's own
>        ;; buffer.

Yes, and this makes absolutely clear what to expect from the *scratch*
buffer -- in fact, for content you actually want to keep you will have
to delete this text first, so don't whine when you ignored it.

>      But users don't read stuff, we all know that (heck, I'm a user
>      who's also a programmer, and I still don't read stuff).

Yeah, there is much truth in that, and I often fail to read stuff my
self -- but if something goes wrong I don't blame others for my fault.
Especially if the text in question is so short, clear and easy to
notice as this comments in the *scratch* buffer. 

>      I think
>      of that notice as a workaround to a real solution: offering to
>      save what the user has typed.

No "real solution" needed, as *scratch* does exactly what it is
intended to, and it states it's intention loud and clearly.

Please leave *scratch* alone.

cheers
sascha
-- 
"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web 
page appears to be yearning for the bad old days, before the Web, when you had 
very little chance of reading a document written on another computer, another 
word processor, or another network." -- Tim Berners-Lee, July 1996

Re: A wish, a plea

[Nic James Ferrier]

Sascha Wilde <wilde@sha-bang.de> writes:

> I'm actually using *scratch* quite often, as a scratch pad for stuff I
> don't want to save (and don't want to be asked, if I want to save them
> on exit), as well as for ad-hoc elisp stuff.
>
> I like the feature of having *scratch* at hand from the beginning in
> every emacs session, and I would miss it...

Yes.

I like it and use it too. But we don't need it to be the default
buffer when you start an unconfigured Emacs.


> Yeah, there is much truth in that, and I often fail to read stuff my
> self -- but if something goes wrong I don't blame others for my fault.
> Especially if the text in question is so short, clear and easy to
> notice as this comments in the *scratch* buffer. 

It's the fact that it's the default buffer for an unconfigured emacs
that is the problem.

If we can help people out by changing the default then we should.



> Please leave *scratch* alone.

*scratch* doesn't need to be changed. Emacs needs to change so that
 *scratch* is not the default buffer for an unconfigured Emacs.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[Karl Fogel]

Sascha Wilde <wilde@sha-bang.de> writes:
> I'm actually using *scratch* quite often, as a scratch pad for stuff I
> don't want to save (and don't want to be asked, if I want to save them
> on exit), as well as for ad-hoc elisp stuff.

Unlike most users, you know how to change any default anyway.

> I like the feature of having *scratch* at hand from the beginning in
> every emacs session, and I would miss it...

We don't need to get rid of the *scratch* buffer.  (I wasn't actually
suggesting that, although I guess I wouldn't object to it either.)

We could retain it, but make one of these changes as well:

   a) the initial selected buffer be a Fundamental Mode or Text Mode
      buffer ("scratch", "notes", whatever), with buffer-offer-save
      turned on by default.

       -or-

   b) if we just want to retain *scratch* as-is, that we at least
      default to buffer-offer-save in that buffer, in stock Emacs.

Do you object to both (a) and (b)?

I prefer (a), my reasoning being that *scratch* is only useful to
people who know a bit of Elisp, and those people can easily figure out
how to change any default we set anyway.

We can keep the *scratch* buffer, if we must, but are you really
saying that it should also be the default selected buffer, and it
should not offer to save on exit by default?

I mean, step back for a moment: we have here a text editor that when
you open it, gives you a scratch space that's not really set up for
editing text, and that won't offer to save when you exit.

How can that be the best thing for most users? :-)

-Karl

Re: A wish, a plea

[Jason Rumney]

How about if Emacs left the splash screen as the active buffer if there
were no files listed on the command-line, until the user deliberately
switches buffers (either with C-x C-f to edit a new file, or C-x b to
*scratch*)

RE: A wish, a plea

[Drew Adams]

> How about if Emacs left the splash screen as the active buffer if there
> were no files listed on the command-line, until the user deliberately
> switches buffers (either with C-x C-f to edit a new file, or C-x b to
> *scratch*)

Some text editors start with no document open, as you suggest. Some others
start with a new document open (sometimes named "new.txt") in a text mode.

Personally, I usually start Emacs with Dired. That too might be a
possibility: start in `~/'. That gives users flexibility in terms of opening
existing files or new ones, and they can see what files are available.
Another possibility is to have an explicit option for the startup directory
(default `~/'). Just a thought.

Re: A wish, a plea

[csant]

On Fri, 22 Jun 2007 01:04:58 +0200, Drew Adams <drew.adams@oracle.com>  
wrote:

> That too might be a possibility: start in `~/'

Rather: in $PWD .

Just 2 cents as a user:  It has been repeatedly suggested to use *scratch*  
as a buffer to take quick notes.  Major drawback is that there is only one  
*scratch*, you take notes, at some point write that temporary buffer to a  
final location - and lost your scratchpad.  Personally, I liked the idea  
of ~/.emacs.d/notes/

/c

Re: A wish, a plea

[Richard Stallman]

    Personally, I usually start Emacs with Dired. That too might be a
    possibility: start in `~/'. That gives users flexibility in terms of opening
    existing files or new ones, and they can see what files are available.
    Another possibility is to have an explicit option for the startup directory
    (default `~/'). Just a thought.

That might be a good idea.  The only drawback would be when
the home dir is so large that this is very slow.

I find it a pain in the neck to start the file dialogs of many GUI apps
because they insist on reading my whole homedir before letting me
specify a file.  Bad design!

RE: A wish, a plea

[Drew Adams]

>     Personally, I usually start Emacs with Dired. That too might be a
>     possibility: start in `~/'. That gives users flexibility in
>     terms of opening existing files or new ones, and they can see
>     what files are available. Another possibility is to have an
>     explicit option for the startup directory
>     (default `~/'). Just a thought.
>
> That might be a good idea.  The only drawback would be when
> the home dir is so large that this is very slow.
>
> I find it a pain in the neck to start the file dialogs of many GUI apps
> because they insist on reading my whole homedir before letting me
> specify a file.  Bad design!

Good point. But what about the `visit-on-startup' option suggestion? It
would _default_ to `~/', but you could specify anything. It wouldn't need to
be a directory, but could be an existing file or even a new file. The
definition could be something like this:

(defcustom visit-on-startup "~/"
  "File or directory to visit when Emacs is started."
  :type 'file :group 'emacs)

The :type is not (file :must-match t) here, so if you used the name of a
non-existent file, then the behavior would be similar to the "*unnamed*",
"new", or "Document 1" startup buffer of some text editors (create a new
file buffer at the specified location), which some others have suggested
using. As always, `auto-mode-alist' would determine the mode to use.

We could either try to require an absolute file name or else default the
location to some reasonable directory (e.g. ~/), to define
`default-directory'. I'm not sure how we could _require_ an absolute value,
however. Today, the `default-directory' seems to default to the location of
`runemacs', at least on Windows (~/ seems preferable to that location, to
me).

As an alternative, the :type could be a choice between what is shown above
and simply showing the splash screen (no startup file or directory), as some
people suggested. That way, a user could get any of the behaviors that
people have discussed so far in this thread. For example, a value of nil or
perhaps the symbol `splash-screen' could mean to use only the splash screen.
For example:

(defcustom visit-on-startup "~/"
  "File or directory to visit when Emacs is started."
  :type '(choice (const :tag "Splash screen only" nil)
                 (file  :tag "Visit file or directory" :value "~/"))
  :group 'emacs)

I'd vote for the default value being `~/', but deciding on the default value
is a different issue than deciding to let users customize the startup
behavior.

Re: A wish, a plea

[Richard Stallman]

    Good point. But what about the `visit-on-startup' option suggestion? It
    would _default_ to `~/', but you could specify anything. It wouldn't need to
    be a directory, but could be an existing file or even a new file. The
    definition could be something like this:

    (defcustom visit-on-startup "~/"
      "File or directory to visit when Emacs is started."
      :type 'file :group 'emacs)

It is a nice feature, as long as it can be nil meaning don't.

Re: A wish, a plea

[Juri Linkov]

> (defcustom visit-on-startup "~/"
>   "File or directory to visit when Emacs is started."
>   :type '(choice (const :tag "Splash screen only" nil)
>                  (file  :tag "Visit file or directory" :value "~/"))
>   :group 'emacs)
>
> I'd vote for the default value being `~/', but deciding on the default value
> is a different issue than deciding to let users customize the startup
> behavior.

You forgot the option for displaying *scratch* on startup.  Perhaps nil
should do that, and I think it should be the default value.

FWIW, I have as the last line of .emacs:

  (dired "~")

that allows me immediately after startup navigate to the necessary
directory and to open/create files in it.  And *scratch* still exists,
coming up after pressing `q' in the initial dired buffer.  So I welcome
a new option to customize this.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: A wish, a plea

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> (defcustom visit-on-startup "~/"
>>   "File or directory to visit when Emacs is started."
>>   :type '(choice (const :tag "Splash screen only" nil)
>>                  (file  :tag "Visit file or directory" :value "~/"))
>>   :group 'emacs)
>>
>> I'd vote for the default value being `~/', but deciding on the default value
>> is a different issue than deciding to let users customize the startup
>> behavior.
>
> You forgot the option for displaying *scratch* on startup.  Perhaps
> nil should do that, and I think it should be the default value.

I think that is special-casing *scratch* too much.  Maybe
visit-on-startup can evaluate to a buffer and be something like
(get-buffer-create "*scratch*")
(find-file "~/")
and the special value "nil" is reserved for not mapping an initial
frame at all (namely, waiting for a call of emacsclient).

Or something like that.  I'll readily admit that this might not be the
final solution.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: A wish, a plea

[Drew Adams]

> > You forgot the option for displaying *scratch* on startup.  Perhaps
> > nil should do that, and I think it should be the default value.
>
> I think that is special-casing *scratch* too much.  Maybe
> visit-on-startup can evaluate to a buffer and be something like
> (get-buffer-create "*scratch*")
> (find-file "~/")
> and the special value "nil" is reserved for not mapping an initial
> frame at all (namely, waiting for a call of emacsclient).
>
> Or something like that.  I'll readily admit that this might not be the
> final solution.

I think we're (at least the 3 of us) thinking along similar lines. The
important thing is for others to agree to have a `visit-on-startup' option.

I think that the definition of `visit-on-startup' could probably be as
simple as I suggested (see my reply to Juri), but I might be wrong and we
would need to add a separate `choice' for a buffer to visit.

RE: A wish, a plea

[Drew Adams]

> > (defcustom visit-on-startup "~/"
> >   "File or directory to visit when Emacs is started."
> >   :type '(choice (const :tag "Splash screen only" nil)
> >                  (file  :tag "Visit file or directory" :value "~/"))
> >   :group 'emacs)
> >
> > I'd vote for the default value being `~/', but deciding on the
> > default value is a different issue than deciding to let users
> > customize the startup behavior.
>
> You forgot the option for displaying *scratch* on startup.

No I didn't (it did occur to me), but I might not have considered all the
angles.

Just set the value to "*scratch*". It will open a buffer visiting new "file"
*scratch* (or possibly *scratch*<2>, if *scratch* pre-exists). Maybe the
user option :tags should make such a possibility more clear. And we might
need to configure a visit of *scratch* to use the right mode, but it should
work OK. That was/is my thinking.

That is, visiting buffer *scratch* is not essentially different from
visiting a new file buffer named *scratch*, provided the right mode is in
effect.

If this is not effective enough, then, yes, we can add a buffer to the :type
`choice'.

> Perhaps nil should do that, and I think it should be the default value.

My vote for the default behavior is still Dired. But which default to use is
a different question from deciding to have a `visit-on-startup' option that
users can customize.

> FWIW, I have as the last line of .emacs:
>
>   (dired "~")
>
> that allows me immediately after startup navigate to the necessary
> directory and to open/create files in it.  And *scratch* still exists,
> coming up after pressing `q' in the initial dired buffer.  So I welcome
> a new option to customize this.

You would get exactly that behavior if you just do nothing, in my proposal,
I believe (IIUYC). By default, Dired would be opened to `~/', and hitting
`q' in Dired will give you *scratch*. That's exactly my own preference too.
Currently, I just provide the directory as an argument to `runemacs', but
the effect is the same.

Re: A wish, a plea

[Sascha Wilde]

Jason Rumney <jasonr@gnu.org> wrote:

> How about if Emacs left the splash screen as the active buffer if there
> were no files listed on the command-line, until the user deliberately
> switches buffers (either with C-x C-f to edit a new file, or C-x b to
> *scratch*)

Please don't.  There is nothing more useless than a splash screen --
there is a good reason, that we have inhibit-splash-screen.

Btw. it might be a good idea to separate inhibiting the splash screen
from inhibiting the initial message in *scratch*...

sascha
-- 
Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)

Re: A wish, a plea

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> Jason Rumney <jasonr@gnu.org> wrote:
>
>> How about if Emacs left the splash screen as the active buffer if there
>> were no files listed on the command-line, until the user deliberately
>> switches buffers (either with C-x C-f to edit a new file, or C-x b to
>> *scratch*)
>
> Please don't.  There is nothing more useless than a splash screen --
> there is a good reason, that we have inhibit-splash-screen.

By the way: I think that our choice of having the splash screen
displayed by default even when Emacs is called with a file name is a
mistake.  Even more so if the same happens when using emacsclient.

Is there _anybody_ who does not find this behavior annoying?  When
Emacs is called with a filename, one has a task to do and wants to
move forward.

> Btw. it might be a good idea to separate inhibiting the splash
> screen from inhibiting the initial message in *scratch*...

As for the default buffer to use: how about using a buffer *unnamed*
that will be in text-mode, that will ask for being saved when one
kills Emacs, and that will ask for a filename when being saved (the
file name becoming then the base for the buffer name)?

Retain *scratch* including the initial message.

-- 
David Kastrup

Re: A wish, a plea

[Nic James Ferrier]

David Kastrup <dak@gnu.org> writes:

> By the way: I think that our choice of having the splash screen
> displayed by default even when Emacs is called with a file name is a
> mistake.  Even more so if the same happens when using emacsclient.
>
> Is there _anybody_ who does not find this behavior annoying?  When
> Emacs is called with a filename, one has a task to do and wants to
> move forward.

I'm fine with it as a default.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
> As for the default buffer to use: how about using a buffer *unnamed*
> that will be in text-mode, that will ask for being saved when one
> kills Emacs, and that will ask for a filename when being saved (the
> file name becoming then the base for the buffer name)?
>
> Retain *scratch* including the initial message.

This all sounds great to me!

Re: A wish, a plea

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 22 Jun 2007 01:33:42 -0700
> Cc: Sascha Wilde <wilde@sha-bang.de>, Hacksaw <hacksaw@hacksaw.org>,
> 	emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
> 
> David Kastrup <dak@gnu.org> writes:
> > As for the default buffer to use: how about using a buffer *unnamed*
> > that will be in text-mode, that will ask for being saved when one
> > kills Emacs, and that will ask for a filename when being saved (the
> > file name becoming then the base for the buffer name)?
> >
> > Retain *scratch* including the initial message.
> 
> This all sounds great to me!

It sounds awful to me.  It reminds me Notepad and Word with their
pesky UNNAMED and DOCUMENT1 defaults.

Did anyone in this longish thread suggest to simply turn on auto-save
in *scratch*, like we do in *mail* buffers?  If not, would that solve
the OP's problem without any significant nasty side effects?

Re: A wish, a plea

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Fri, 22 Jun 2007 01:33:42 -0700
>> Cc: Sascha Wilde <wilde@sha-bang.de>, Hacksaw <hacksaw@hacksaw.org>,
>> 	emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
>> 
>> David Kastrup <dak@gnu.org> writes:
>> > As for the default buffer to use: how about using a buffer *unnamed*
>> > that will be in text-mode, that will ask for being saved when one
>> > kills Emacs, and that will ask for a filename when being saved (the
>> > file name becoming then the base for the buffer name)?
>> >
>> > Retain *scratch* including the initial message.
>> 
>> This all sounds great to me!
>
> It sounds awful to me.  It reminds me Notepad and Word with their
> pesky UNNAMED and DOCUMENT1 defaults.

Being reminded of Notepad and Word is not in itself good or bad.
Could you explain where the peskiness lies?

> Did anyone in this longish thread suggest to simply turn on
> auto-save in *scratch*, like we do in *mail* buffers?  If not, would
> that solve the OP's problem without any significant nasty side
> effects?

Uh, it has the nasty side effect of starting to write to my disk
without asking my confirmation.  If I have started several Emacs
instances, I don't want them complaining about file locks and similar
nonsense just because I use the *scratch* buffer in both.

I don't really think that *scratch* should usually be associated with
any file.

-- 
David Kastrup

Re: A wish, a plea

[Jason Rumney]

David Kastrup wrote:
> Being reminded of Notepad and Word is not in itself good or bad.
> Could you explain where the peskiness lies?
>   

You came up with one good source of peskiness yourself:

> Uh, it has the nasty side effect of starting to write to my disk
> without asking my confirmation.  If I have started several Emacs
> instances, I don't want them complaining about file locks and similar
> nonsense just because I use the *scratch* buffer in both.
>   

Re: A wish, a plea

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> Being reminded of Notepad and Word is not in itself good or bad.
>> Could you explain where the peskiness lies?
>>   
>
> You came up with one good source of peskiness yourself:
>
>> Uh, it has the nasty side effect of starting to write to my disk
>> without asking my confirmation.  If I have started several Emacs
>> instances, I don't want them complaining about file locks and similar
>> nonsense just because I use the *scratch* buffer in both.

I never argued for abolishing the *scratch* buffer (not auto-saved).
And I find it quite appropriate that two instances of modified
*unnamed* buffers (auto-saved) will complain eventually.

That's inherent in the design if we want to offer buffers that are not
volatile but still basically anonymous.

-- 
David Kastrup

Re: A wish, a plea

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> David Kastrup wrote:
>>> Being reminded of Notepad and Word is not in itself good or bad.
>>> Could you explain where the peskiness lies?
>>>   
>>
>> You came up with one good source of peskiness yourself:
>>
>>> Uh, it has the nasty side effect of starting to write to my disk
>>> without asking my confirmation.  If I have started several Emacs
>>> instances, I don't want them complaining about file locks and similar
>>> nonsense just because I use the *scratch* buffer in both.
>
> I never argued for abolishing the *scratch* buffer (not auto-saved).
> And I find it quite appropriate that two instances of modified
> *unnamed* buffers (auto-saved) will complain eventually.
>
> That's inherent in the design if we want to offer buffers that are not
> volatile but still basically anonymous.

Just noticed that auto-save will disambiguate auto-save files for
anonymous buffers.

-- 
David Kastrup

Re: A wish, a plea

[Eli Zaretskii]

> Cc: Karl Fogel <kfogel@red-bean.com>, wilde@sha-bang.de, emacs-devel@gnu.org,
>         hacksaw@hacksaw.org
> From: David Kastrup <dak@gnu.org>
> Date: Fri, 22 Jun 2007 14:43:52 +0200
> 
> > It sounds awful to me.  It reminds me Notepad and Word with their
> > pesky UNNAMED and DOCUMENT1 defaults.
> 
> Being reminded of Notepad and Word is not in itself good or bad.
> Could you explain where the peskiness lies?

I don't like software that decides for me whether I do or don't want
to write a document, and on top of that decides what would be the name
of that file.

> > Did anyone in this longish thread suggest to simply turn on
> > auto-save in *scratch*, like we do in *mail* buffers?  If not, would
> > that solve the OP's problem without any significant nasty side
> > effects?
> 
> Uh, it has the nasty side effect of starting to write to my disk
> without asking my confirmation.

The same happens in *mail* buffers.  How is this case different?

> If I have started several Emacs
> instances, I don't want them complaining about file locks and similar
> nonsense just because I use the *scratch* buffer in both.

Did you actually try that in *scratch*?  I don't think there will be
any locks, since I didn't suggest to give the buffer an associated
file, just to turn on auto-save in it.  That's a different thing.

> I don't really think that *scratch* should usually be associated with
> any file.

That's not what I suggested.  I suggested the equivalent of

  (auto-save-mode 1)

Re: A wish, a plea

[Glenn Morris]

Eli Zaretskii wrote:

> Did anyone in this longish thread suggest to simply turn on
> auto-save in *scratch*, like we do in *mail* buffers?

This seems a simple, sensible suggestion [1]. I think
buffer-offer-save would be good too, as per Karl's very clear initial
diagnosis (I use both these settings myself already). It would be easy
to implement, easy to customize (new vars scratch-auto-save,
scratch-offer-save, defaulting to t), and similar to how other
editors/word processors behave.

[1] I therefore doubt it will get approval. Awaiting the next 50
messages on what colour this feature should be...

Re: A wish, a plea

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
> [1] I therefore doubt it will get approval. Awaiting the next 50
> messages on what colour this feature should be...

  http://pink.bikeshed.com/

(Sorry, couldn't resist :-) ).

Re: A wish, a plea

[Glenn Morris]

Karl Fogel wrote:

>   http://pink.bikeshed.com/
>
> (Sorry, couldn't resist :-) ).

That's the reference I had in mind, from previous exposure on this list. :)

Re: A wish, a plea

[Lennart Borgman (gmail)]

Glenn Morris wrote:
> Karl Fogel wrote:
> 
>>   http://pink.bikeshed.com/
>>
>> (Sorry, couldn't resist :-) ).
> 
> That's the reference I had in mind, from previous exposure on this list. :)


I hardly dare to comment on this one ;-)

Though there is one litte thing I would like to add. I have seen that 
mostly in more sensitive mailing lists than this kind of list:

- Let there always be at least one answer if it seems like the poster 
wants that.
- No need to a lot of answers just for that.

Initial splash screen (was Re: A wish, a plea)

[Stephen Berman]

On Fri, 22 Jun 2007 10:11:07 +0200 David Kastrup <dak@gnu.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> Jason Rumney <jasonr@gnu.org> wrote:
>>
>>> How about if Emacs left the splash screen as the active buffer if there
>>> were no files listed on the command-line, until the user deliberately
>>> switches buffers (either with C-x C-f to edit a new file, or C-x b to
>>> *scratch*)
>>
>> Please don't.  There is nothing more useless than a splash screen --
>> there is a good reason, that we have inhibit-splash-screen.
>
> By the way: I think that our choice of having the splash screen
> displayed by default even when Emacs is called with a file name is a
> mistake.  Even more so if the same happens when using emacsclient.

This may have been suggested before (I haven't searched the archives
for it), but since the issue has been raised again, what about this:
show the splash screen the first time the user invokes Emacs (even
with a file name) and ask whether to show it on the next invocation.
Lot of programs do something similar, usually with popup windows
displaying a tip of the day, and the information in the splash screen
is partly like a TOTD.  Having users answer the question has two
advantages: it forces them to take notice of the splash screen at
least the first time they invoke Emacs, and it provides them with the
immediate opportunity to disable it on future invocations.

Steve Berman

Re: Initial splash screen

[David Kastrup]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> On Fri, 22 Jun 2007 10:11:07 +0200 David Kastrup <dak@gnu.org> wrote:
>
>> Sascha Wilde <wilde@sha-bang.de> writes:
>>
>>> Jason Rumney <jasonr@gnu.org> wrote:
>>>
>>>> How about if Emacs left the splash screen as the active buffer if there
>>>> were no files listed on the command-line, until the user deliberately
>>>> switches buffers (either with C-x C-f to edit a new file, or C-x b to
>>>> *scratch*)
>>>
>>> Please don't.  There is nothing more useless than a splash screen --
>>> there is a good reason, that we have inhibit-splash-screen.
>>
>> By the way: I think that our choice of having the splash screen
>> displayed by default even when Emacs is called with a file name is a
>> mistake.  Even more so if the same happens when using emacsclient.
>
> This may have been suggested before (I haven't searched the archives
> for it), but since the issue has been raised again, what about this:
> show the splash screen the first time the user invokes Emacs (even
> with a file name) and ask whether to show it on the next invocation.

This is a bad idea since the splash screen contains quite a bit of
_useful_ information, and starting Emacs without a filename gives us a
frame where nothing useful can be displayed yet.

So there is no point in not showing the splash screen indefinitely if
we are called without file name.

But _with_ a file name, the situation is different, and we should
cater for it differently.

The same, incidentally, would hold in my opinion when using desktop.el
to restore a desktop: again, we have then a buffer displaying useful
information.

-- 
David Kastrup

Re: Initial splash screen

[Stephen Berman]

On Fri, 22 Jun 2007 13:43:01 +0200 David Kastrup <dak@gnu.org> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
[...]
>> This may have been suggested before (I haven't searched the archives
>> for it), but since the issue has been raised again, what about this:
>> show the splash screen the first time the user invokes Emacs (even
>> with a file name) and ask whether to show it on the next invocation.
>
> This is a bad idea since the splash screen contains quite a bit of
> _useful_ information,

Indeed, but once the user has learned that information, she may not
wish to be reminded of it at each invocation; my proposal amounts to
letting users set inhibit-splash-screen to t, but in the immediate
context of being presented with the useful information they should
know, effectively making them decide that they know the information.

>                       and starting Emacs without a filename gives us a
> frame where nothing useful can be displayed yet.

Well, that's what being debated in the thread I forked off of; many
people do find an initial *scratch* buffer useful.

> So there is no point in not showing the splash screen indefinitely if
> we are called without file name.

If by `indefinitely' you mean upon every invocation, again, the point
is the same as the reason for having inhibit-splash-screen, whose
effect is not constrained to starting Emacs with a file name.

> But _with_ a file name, the situation is different, and we should
> cater for it differently.

I don't see such a difference: the information in the splash screen
should be learned even if a user always starts Emacs with a file name
(and once the information is learned, the splash screen need not
appear any more, even if you start Emacs without a file name).

Steve Berman

Re: Initial splash screen

[David Kastrup]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> On Fri, 22 Jun 2007 13:43:01 +0200 David Kastrup <dak@gnu.org> wrote:
>
>>                       and starting Emacs without a filename gives
>> us a frame where nothing useful can be displayed yet.
>
> Well, that's what being debated in the thread I forked off of; many
> people do find an initial *scratch* buffer useful.

The initial *scratch* buffer is useful for _writing_ (which will
obliterate the splash screen just fine).  An initial _file_ buffer in
contrast, is supposed to be useful for _reading_, and one can't start
reading as long as the splash screen is blocking the reading.

>> So there is no point in not showing the splash screen indefinitely
>> if we are called without file name.
>
> If by `indefinitely' you mean upon every invocation, again, the
> point is the same as the reason for having inhibit-splash-screen,
> whose effect is not constrained to starting Emacs with a file name.

Which is a mistake in my book: people have reported the habit of just
starting another Emacs without file name if they find themselves in
want of reading up on the splash screen.  Having inhibit-splash-screen
not able to discriminate between the with-file and without-file
invocation takes away this expedience.

>> But _with_ a file name, the situation is different, and we should
>> cater for it differently.
>
> I don't see such a difference: the information in the splash screen
> should be learned even if a user always starts Emacs with a file
> name (and once the information is learned, the splash screen need
> not appear any more, even if you start Emacs without a file name).

You are assuming a perfect memory.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Initial splash screen

[Stephen Berman]

On Fri, 22 Jun 2007 22:09:29 +0200 David Kastrup <dak@gnu.org> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> On Fri, 22 Jun 2007 13:43:01 +0200 David Kastrup <dak@gnu.org> wrote:
>>
>>>                       and starting Emacs without a filename gives
>>> us a frame where nothing useful can be displayed yet.
>>
>> Well, that's what being debated in the thread I forked off of; many
>> people do find an initial *scratch* buffer useful.
>
> The initial *scratch* buffer is useful for _writing_ (which will
> obliterate the splash screen just fine).  An initial _file_ buffer in
> contrast, is supposed to be useful for _reading_, and one can't start
> reading as long as the splash screen is blocking the reading.

Well, it does go away automatically.  Anyway, that's what
inhibit-splash-screen is for (in the current design, i.e.,
notwithstanding the reservations you express below).  All my
suggestion adds is the opportunity to immediately set the inhibition
for future invocations.

>>> So there is no point in not showing the splash screen indefinitely
>>> if we are called without file name.
>>
>> If by `indefinitely' you mean upon every invocation, again, the
>> point is the same as the reason for having inhibit-splash-screen,
>> whose effect is not constrained to starting Emacs with a file name.
>
> Which is a mistake in my book: people have reported the habit of just
> starting another Emacs without file name if they find themselves in
> want of reading up on the splash screen.  Having inhibit-splash-screen
> not able to discriminate between the with-file and without-file
> invocation takes away this expedience.

Emacs 22 does away with the need for such expedience; the user just
has to learn to do Help->About Emacs.

>>> But _with_ a file name, the situation is different, and we should
>>> cater for it differently.
>>
>> I don't see such a difference: the information in the splash screen
>> should be learned even if a user always starts Emacs with a file
>> name (and once the information is learned, the splash screen need
>> not appear any more, even if you start Emacs without a file name).
>
> You are assuming a perfect memory.

I don't think I'm assuming any more than what inhibit-splash-screen
assumes.  And again, now there's always Help->About Emacs.

Steve Berman

Re: Initial splash screen (was Re: A wish, a plea)

[Richard Stallman]

    This may have been suggested before (I haven't searched the archives
    for it), but since the issue has been raised again, what about this:
    show the splash screen the first time the user invokes Emacs (even
    with a file name) and ask whether to show it on the next invocation.

I won't reject this, but I am not sure if it is really more
convenient.  To have to answer the question may be more inconvenient
than to be shown the splash screen.  People will say "turn it off"
because they don't want to be asked the question, not because of the
splash screen itself.

It might be better to make the splash screen mention
a command to set inhibit-splash-screen.  That will make
it easier to turn it off, without annoying anyone.

Re: Initial splash screen (was Re: A wish, a plea)

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     This may have been suggested before (I haven't searched the archives
>     for it), but since the issue has been raised again, what about this:
>     show the splash screen the first time the user invokes Emacs (even
>     with a file name) and ask whether to show it on the next invocation.
> 
> I won't reject this, but I am not sure if it is really more
> convenient.  To have to answer the question may be more inconvenient
> than to be shown the splash screen.  People will say "turn it off"
> because they don't want to be asked the question, not because of the
> splash screen itself.

The normal way to ask such questions in most GUI apps is to have three 
alternatives, were the third alternative is just "Do not ask me again".

Re: Initial splash screen (was Re: A wish, a plea)

[Richard Stallman]

    The normal way to ask such questions in most GUI apps is to have three 
    alternatives, were the third alternative is just "Do not ask me again".

MAYBE that would lead to good results, if it leads people to read the
splash screen more.  But it could also backfire.  I don't feel confident
we can tell which one it would be.  Perhaps we could do an experiment,
but it won't be an easy experiment to do.

Re: Initial splash screen

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The normal way to ask such questions in most GUI apps is to have
>     three alternatives, were the third alternative is just "Do not
>     ask me again".
>
> MAYBE that would lead to good results, if it leads people to read
> the splash screen more.

In my experience, it usually leads to people turning off the nag
screen.  For the use case of "emacs filename", I really think we
should default to just
(message "The menu \"Help/About Emacs\" points out some help sources.")
It does not keep people from working on files.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Initial splash screen (was Re: A wish, a plea)

[Stephen Berman]

On Fri, 22 Jun 2007 17:53:29 -0400 Richard Stallman <rms@gnu.org> wrote:

>     This may have been suggested before (I haven't searched the archives
>     for it), but since the issue has been raised again, what about this:
>     show the splash screen the first time the user invokes Emacs (even
>     with a file name) and ask whether to show it on the next invocation.
>
> I won't reject this, but I am not sure if it is really more
> convenient.  To have to answer the question may be more inconvenient
> than to be shown the splash screen.  People will say "turn it off"
> because they don't want to be asked the question, not because of the
> splash screen itself.

You may be right; I don't know.  But at least the question can force
them to take notice of the splash screen.  My suggestion is based on
the assumption that newbies often overlook the information in the
splash screen, precisely because it appears on each invocation and
automatically disappears, like the typically uninformative splash
screens of most GUI programs.  I don't have data to support this
assumption, but it doesn't seem too farfetched.

> It might be better to make the splash screen mention
> a command to set inhibit-splash-screen.  That will make
> it easier to turn it off, without annoying anyone.

Assuming they in fact read it.

Steve Berman

Re: Initial splash screen

[David Kastrup]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> On Fri, 22 Jun 2007 17:53:29 -0400 Richard Stallman <rms@gnu.org> wrote:
>
>> I won't reject this, but I am not sure if it is really more
>> convenient.  To have to answer the question may be more
>> inconvenient than to be shown the splash screen.  People will say
>> "turn it off" because they don't want to be asked the question, not
>> because of the splash screen itself.
>
> You may be right; I don't know.  But at least the question can force
> them to take notice of the splash screen.

There is a name for an interface forcibly stopping people from
starting to work before they have presumably perused something: it is
"nagware".  We should focus on making Emacs convenient for people, not
making people convenient for Emacs.  The latter does not work, anyway.

Personally, I'd use
(message "Check the \"Help/About Emacs\" menu entry for basic usage pointers.")
when Emacs is started with file names on the command line.

That does not interfere with work since the frame can already display
the final layout (apart from the message area).  And its message is
simple enough to remember the gist of what it was about.  You don't
have a chance to remember what the complex splash screen was about, in
contrast, when your priority was to get it out of your face and be
able to start working (and starting Emacs with file names very much
implies that you intend to start it for the purpose of doing some
work).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Initial splash screen

[Stephen Berman]

On Sat, 23 Jun 2007 08:42:10 +0200 David Kastrup <dak@gnu.org> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> On Fri, 22 Jun 2007 17:53:29 -0400 Richard Stallman <rms@gnu.org> wrote:
>>
>>> I won't reject this, but I am not sure if it is really more
>>> convenient.  To have to answer the question may be more
>>> inconvenient than to be shown the splash screen.  People will say
>>> "turn it off" because they don't want to be asked the question, not
>>> because of the splash screen itself.
>>
>> You may be right; I don't know.  But at least the question can force
>> them to take notice of the splash screen.
>
> There is a name for an interface forcibly stopping people from
> starting to work before they have presumably perused something: it is
> "nagware".  We should focus on making Emacs convenient for people, not
> making people convenient for Emacs.  The latter does not work, anyway.

You may be right that it doesn't work, I don't know; but I don't think
this form of nagging is any (or at least notably) worse than others
set by default in Emacs but that can be turned off by users.  And
again (and for the last time!), I am suggesting that the opportunity
to turn this off be immediately provided, and in the context of
showing the important information.  However, ...

> Personally, I'd use (message "Check the \"Help/About Emacs\" menu
> entry for basic usage pointers.")  when Emacs is started with file
> names on the command line.

... this is a good idea, and I agree better than showing the splash
screen (at least after the first invocation by a user).  Whether the
message gets shown should also be configurable.

Steve Berman

Re: Initial splash screen

[Richard Stallman]

    Personally, I'd use
    (message "Check the \"Help/About Emacs\" menu entry for basic usage pointers.")
    when Emacs is started with file names on the command line.

I won't do that because it is not sufficient for the purpose of
informing users about GNU.

Emacs will continue to show the splash screen every time it starts.

Re: Initial splash screen

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Personally, I'd use
>     (message "Check the \"Help/About Emacs\" menu entry for basic usage pointers.")
>     when Emacs is started with file names on the command line.
>
> I won't do that because it is not sufficient for the purpose of
> informing users about GNU.

I don't see how.  Information will only be ingested when the user is
actually perusing the page.  When he is starting Emacs with a
filename, the page (as opposed to the message) is getting in his way
and so will get clicked away before it can register.

Anyway, the only information displayed in that regard is
"GNU Emacs is one component of the GNU/Linux operating system."

It implies that there is just one GNU/Linux operating system, and it
implies that GNU has no existence outside of Linux.  In particular
when running Emacs under Cygwin or similar, this message is weird, to
say the least.

I also find that neither the splash screen nor the extensive HELP menu
provides _any_ pointer to the GNU project: `describe-project' is not
in the help menus or mentioned on the splash screen.

We do an excellent job of hiding relevant info; and making the splash
screen for calling Emacs with filenames annoying achieves about as
much in that category as annoying air passengers by confiscating nail
clippers helps security.

> Emacs will continue to show the splash screen every time it starts.

Shrug.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Initial splash screen

[Richard Stallman]

    It implies that there is just one GNU/Linux operating system, and it
    implies that GNU has no existence outside of Linux.

It doesn't say or imply anything of the kind.

    I also find that neither the splash screen nor the extensive HELP menu
    provides _any_ pointer to the GNU project: `describe-project' is not
    in the help menus or mentioned on the splash screen.

Thanks for calling my attention to that.  I will do something about
that presently.

Re: Initial splash screen

[Mathias Dahl]

>    It implies that there is just one GNU/Linux operating system, and it
>    implies that GNU has no existence outside of Linux.

For the discussion, on Windows it says:

  GNU Emacs is one component of the GNU operating system

Which I think sounds good.

Then, after one enters *scratch*, it says in the echo area:

  For information about the GNU Project and its goals, type C-h C-p.

Also quite informative, but maybe there should be a link to GNU.org or
FSF somewhere in the Help menu.

Re: Initial splash screen

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>>    It implies that there is just one GNU/Linux operating system, and it
>>    implies that GNU has no existence outside of Linux.
>
> For the discussion, on Windows it says:
>
>  GNU Emacs is one component of the GNU operating system
>
> Which I think sounds good.
>
> Then, after one enters *scratch*, it says in the echo area:
>
>  For information about the GNU Project and its goals, type C-h C-p.

Sort of amusing that the scratch screen has a better pointer than the
splash screen.

-- 
David Kastrup

Re: A wish, a plea

[Richard Stallman]

    By the way: I think that our choice of having the splash screen
    displayed by default even when Emacs is called with a file name is a
    mistake.  Even more so if the same happens when using emacsclient.

I decided to do this because I want beginning users to see the info in
the splash screen.  Many of them specify a file name by habit carried
from other editors.

This is important for the GNU Project, so I will not change the decision.

Re: A wish, a plea

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     By the way: I think that our choice of having the splash screen
>     displayed by default even when Emacs is called with a file name is a
>     mistake.  Even more so if the same happens when using emacsclient.
>
> I decided to do this because I want beginning users to see the info in
> the splash screen.  Many of them specify a file name by habit carried
> from other editors.

Beginners would hardly be using emacsclient.  Restricting the splash
screen to once per Emacs session is quite enough.

Anyway, _beginners_ would be clicking some icon to start Emacs, not
use a command line.

> This is important for the GNU Project, so I will not change the
> decision.

The GNU project should be fine with once a session.  Having
emacsclient frames for something like commit messages triggered from
C-x v v show the splash screen is plainly disruptive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A wish, a plea

[Richard Stallman]

    > I decided to do this because I want beginning users to see the info in
    > the splash screen.  Many of them specify a file name by habit carried
    > from other editors.

    Beginners would hardly be using emacsclient.  Restricting the splash
    screen to once per Emacs session is quite enough.

What does emacsclient have to do with this?  As far as I know,
the splash screen appears just at the start of the Emacs session.

Re: A wish, a plea

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > I decided to do this because I want beginning users to see the info in
>     > the splash screen.  Many of them specify a file name by habit carried
>     > from other editors.
>
>     Beginners would hardly be using emacsclient.  Restricting the splash
>     screen to once per Emacs session is quite enough.
>
> What does emacsclient have to do with this?  As far as I know,
> the splash screen appears just at the start of the Emacs session.

That seems to concern the multi-tty branch currently where emacsclient
defaults to opening a new frame/session/terminal/whatever.

This new frame will show the splash screen again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A wish, a plea

[Stefan Monnier]

> That seems to concern the multi-tty branch currently where emacsclient
> defaults to opening a new frame/session/terminal/whatever.

> This new frame will show the splash screen again.

That's a completely separate issue.  The current emacsclient does no such
thing, so it's a change in multi-tty, so we'll cross that bridge when we
get there.


        Stefan

Re: A wish, a plea

[Richard Stallman]

    That seems to concern the multi-tty branch currently where emacsclient
    defaults to opening a new frame/session/terminal/whatever.

    This new frame will show the splash screen again.

Why does it do that?  Anyway, I don't insist it should.
I'm satisfied with showing it when Emacs starts.

Re: A wish, a plea

[Ryan Yeske]

David Kastrup <dak@gnu.org> writes:

> Is there _anybody_ who does not find this behavior annoying?  When
> Emacs is called with a filename, one has a task to do and wants to
> move forward.

I rarely start emacs this way, but at least one time when I did, I was
confused by seeing the splash screen and not the file I needed to
edit.  

I don't think the splash screen should show up when specifying a file
on startup.

-- 
Ryan

Re: A wish, a plea

[Davis Herring]

> As for the default buffer to use: how about using a buffer *unnamed*
> that will be in text-mode, that will ask for being saved when one
> kills Emacs, and that will ask for a filename when being saved (the
> file name becoming then the base for the buffer name)?

Very minor point: the standard word is "untitled" here.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: A wish, a plea

[Richard Stallman]

    How about if Emacs left the splash screen as the active buffer if there
    were no files listed on the command-line, until the user deliberately
    switches buffers (either with C-x C-f to edit a new file, or C-x b to
    *scratch*)

Would that really change anything?  People could still insert text
into that buffer.  Why would this not be an opportunity for the same
problem that occurs occasionally with *scratch*?

Re: A wish, a plea

[Jason Rumney]

Richard Stallman wrote:
>     How about if Emacs left the splash screen as the active buffer if there
>     were no files listed on the command-line, until the user deliberately
>     switches buffers (either with C-x C-f to edit a new file, or C-x b to
>     *scratch*)
>
> Would that really change anything?  People could still insert text
> into that buffer.
The splash-screen is read-only, so they couldn't insert text there.

Re: A wish, a plea

[Richard Stallman]

    > Would that really change anything?  People could still insert text
    > into that buffer.
    The splash-screen is read-only, so they couldn't insert text there.

If we want the initial buffer to be read-only, we can make it read-only
whichever buffer it is.

Re: A wish, a plea

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > Would that really change anything?  People could still insert text
>     > into that buffer.
>     The splash-screen is read-only, so they couldn't insert text there.
>
> If we want the initial buffer to be read-only, we can make it read-only
> whichever buffer it is.

Making *scratch* or even something like *unnamed* readonly would
pretty much defeat its intent.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A wish, a plea

[Richard Stallman]

    Making *scratch* or even something like *unnamed* readonly would
    pretty much defeat its intent.

The principal intent of *scratch* is to be the current buffer when
Emacs starts up.  Secondarily, it provides a place to enter notes you
don't want to save, and eval Lisp expressions.  Making it read-only,
so you need to type C-x C-q before inserting anything, would not spoil
the principal intent.  It would slightly inconvenience the secondary
intent, but that MIGHT be worth while in exchange for making it less
likely to lose data.

I am not sure this change is a good idea, but it isn't ridiculous.

Re: A wish, a plea

[Alfred M. Szmidt]

       Making *scratch* or even something like *unnamed* readonly would
       pretty much defeat its intent.

   The principal intent of *scratch* is to be the current buffer when
   Emacs starts up.  Secondarily, it provides a place to enter notes you
   don't want to save, and eval Lisp expressions.  Making it read-only,
   so you need to type C-x C-q before inserting anything, would not spoil
   the principal intent.  It would slightly inconvenience the secondary
   intent, but that MIGHT be worth while in exchange for making it less
   likely to lose data.

Wouldn't it be smarter to make the initial splash screen the current
buffer when Emacs starts instead?  It would make sense for that to be
read-only, and when one does C-x C-q, it could for example clear it
and toggle the read-only status of the buffer (with a brief note in
the initial splash screen that one can do C-x C-q to convert it into a
"scratch" buffer).

Currently the initial splash screen vanishes really quickly, if you
try to do anything it will vanish.  You cannot copy the URL to the
guided Emacs tour, for example.  If it was the current buffer that
didn't vanish (like *scratch*), then this wouldn't happen.

Re: A wish, a plea

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Making *scratch* or even something like *unnamed* readonly would
>     pretty much defeat its intent.
>
> The principal intent of *scratch* is to be the current buffer when
> Emacs starts up.

Then it should be named "*initial*" or "*startup*" and not
"*scratch*".  Using a name not corresponding to its principal intent
is misleading.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A wish, a plea

[Richard Stallman]

    Then it should be named "*initial*" or "*startup*" and not
    "*scratch*".

Maybe, but I'm not sure it is wrong to choose the name based on the
secondary intent.  The fact that it is initial is self-evident,
so maybe it need not be explicitly stated.

Re: A wish, a plea

[Hacksaw]

Richard Stallman wrote:
>     Making *scratch* or even something like *unnamed* readonly would
>     pretty much defeat its intent.
>
> The principal intent of *scratch* is to be the current buffer when
> Emacs starts up.  Secondarily, it provides a place to enter notes you
> don't want to save, and eval Lisp expressions.  Making it read-only,
> so you need to type C-x C-q before inserting anything, would not spoil
> the principal intent.  It would slightly inconvenience the secondary
> intent, but that MIGHT be worth while in exchange for making it less
> likely to lose data.
>
> I am not sure this change is a good idea, but it isn't ridiculous.
>   

I don't mind the idea that *scratch* would be the first thing I see. My 
only concern is that the editor not get in the way of whatever I have to 
do. (This is one of the reason I don't care for vi: I can't just start 
typing, I have to figure out what mode I'm in.)

My preference would be for scratch to actually save everything. Don't 
treat it like mere workspace to be tossed when you figure something out, 
treat it as a fairly limitless notebook in which you can record your 
ideas, try out things, and hopefully never lose anything you didn't 
explicitly erase. I would make it autosave fairly often, like after an 
eval, as well as after 250 characters, and such, assuming the cost of 
appending to a huge file isn't crazy. (Even then it's easy to imagine a 
scheme with files stitched together to make a feeling of being a single 
file.)

Think about a future where you can mark a section of the *scratch* as 
being C or Python or whatever, and emacs will do it's best to evaluate 
that chunk and insert the results as it does with Lisp Interactive mode.

After all, disk space is crazily cheap.

Thanks for everyone's thoughts on this matter, by the way.

Re: A wish, a plea

[Sascha Wilde]

Hacksaw <hacksaw@hacksaw.org> wrote:
>
> My preference would be for scratch to actually save everything. Don't
> treat it like mere workspace to be tossed when you figure something
> out, treat it as a fairly limitless notebook in which you can record
> your ideas, try out things, and hopefully never lose anything you
> didn't explicitly erase. I would make it autosave fairly often, like
> after an eval, as well as after 250 characters, and such
[...]

If I understand your idea right, that would mean making no changes to
the semantics of *scratch* at all, with the one exception of
preserving the content of *scratch* between Emacs sessions?

I like that idea very much!  

And I think it should make everybody happy: those who are worried,
that they might write something important in *scratch* and exit Emacs
without saving could simply restart Emacs again without having lost
anything -- and people like me could keep using *scratch* like they
are used to, without being annoyed by questions about saving changed
content of *scratch*.  The only change for folks like me would be,
that they would want to discard the content of *scratch* from time to
time, but C-x h C-w isn't that hard to type...  (or it could be
arranged in .emacs for those, who want the exact current behavior
back).

sascha
-- 
Sascha Wilde  :  "I heard that if you play the Windows CD backward, you
              :  get a satanic message. But that's nothing compared to
              :  when you play it forward: It installs Windows...." 
              :  -- G. R. Gaudreau

Re: A wish, a plea

[Hacksaw]

Sascha Wilde wrote:
> Hacksaw <hacksaw@hacksaw.org> wrote:
>   
>> My preference would be for scratch to actually save everything. Don't
>> treat it like mere workspace to be tossed when you figure something
>> out, treat it as a fairly limitless notebook in which you can record
>> your ideas, try out things, and hopefully never lose anything you
>> didn't explicitly erase. I would make it autosave fairly often, like
>> after an eval, as well as after 250 characters, and such
>>     
> [...]
>
> If I understand your idea right, that would mean making no changes to
> the semantics of *scratch* at all, with the one exception of
> preserving the content of *scratch* between Emacs sessions?
>
> I like that idea very much!
>   

You have it right. :-)
> And I think it should make everybody happy: those who are worried,
> that they might write something important in *scratch* and exit Emacs
> without saving could simply restart Emacs again without having lost
> anything -- and people like me could keep using *scratch* like they
> are used to, without being annoyed by questions about saving changed
> content of *scratch*.  The only change for folks like me would be,
> that they would want to discard the content of *scratch* from time to
> time, but C-x h C-w isn't that hard to type...  (or it could be
> arranged in .emacs for those, who want the exact current behavior
> back).
>   

Right, and even if people are surprised by the new behavior, it doesn't 
cause them loss.

Re: A wish, a plea

[Richard Stallman]

One way to preserve the contents of *scratch* is to (1) enable
autosave in it, and (2) on start-up, check for an auto-save file from
*scratch*, and if there is one, offer to reload it.

Would someone like to implement this?

(Also it should set buffer-offer-save.)

Re: A wish, a plea

[Sascha Wilde]

Richard Stallman <rms@gnu.org> wrote:

> (Also it should set buffer-offer-save.)

Please don't.  As written before: I think this would be a constant
source of annoyance, wouldn't it be sufficient to ensure, that
*scratch* is always autosaved when exiting emacs?  (I'm not sure if
this isn't part of regular autosave anyway...)

sascha
-- 
Sascha Wilde : "Der Nicht-Denkende glaubt, dass niemand denkt,
             : der Denkende weiss es!"
             : (Gabriel Laub)

Re: A wish, a plea

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> I mean, step back for a moment: we have here a text editor

Emacs is not a text editor, Emacs is a religion.  Be enlightened.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A wish, a plea

[Sascha Wilde]

Karl Fogel <kfogel@red-bean.com> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>> I'm actually using *scratch* quite often, as a scratch pad for stuff I
>> don't want to save (and don't want to be asked, if I want to save them
>> on exit), as well as for ad-hoc elisp stuff.
>
> Unlike most users, you know how to change any default anyway.

True, and I will if I have to.

But the defaults define the first impression a new user gets from
Emacs, and back when I chose Emacs, I liked the impression of a
powerful hackertool with defaults suiting my needs.  *scratch* is not
the one big killer feature, but it's one piece in the puzzle -- and
yes I admit, I'm selfish and I love and want to retain this "written
by hackers for hackers" kind of software.  :-)

> We could retain it, but make one of these changes as well:
>
>    a) the initial selected buffer be a Fundamental Mode or Text Mode
>       buffer ("scratch", "notes", whatever), with buffer-offer-save
>       turned on by default.
>
>        -or-
>
>    b) if we just want to retain *scratch* as-is, that we at least
>       default to buffer-offer-save in that buffer, in stock Emacs.
>
> Do you object to both (a) and (b)?

I strongly object to (b) as it is against the idea behind *scratch*.
I could live with (a) given that:

1. The new default buffer is not called *scratch*
2. *scratch* will be still available after starting Emacs (though not
   being switched to by default)
3. The old behavior could be easily restored by setting 
   i-am-an-old-school-hacker-and-want-my-scratch-buffer-back to t (or
   something like that).  ;-)

> We can keep the *scratch* buffer, if we must, but are you really
> saying that it should also be the default selected buffer,

I like it that way, but as said, it can be made optional, if people
insist on that change...

> and it should not offer to save on exit by default?

Yes!  This is an important part of the concept of *scratch*.

sascha
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.

Re: A wish, a plea

[Karl Fogel]

Sascha Wilde <wilde@sha-bang.de> writes:
> I strongly object to (b) as it is against the idea behind *scratch*.
> I could live with (a) given that:
>
> 1. The new default buffer is not called *scratch*
> 2. *scratch* will be still available after starting Emacs (though not
>    being switched to by default)

Sure, sounds good.  Nearly everyone seems okay with that solution.
Not sure when I'll actually have time to *do* it, but maybe someone
else will beat me to it...

> 3. The old behavior could be easily restored by setting 
>    i-am-an-old-school-hacker-and-want-my-scratch-buffer-back to t (or
>    something like that).  ;-)

Well, hackers don't need help with that; you have the source code :-).

-Karl

Re: A wish, a plea

[Juanma Barranquero]

On 6/22/07, Sascha Wilde <wilde@sha-bang.de> wrote:

> > and it should not offer to save on exit by default?
>
> Yes!  This is an important part of the concept of *scratch*.

IMO "scratch" carries the meaning of a storage area for work in
progress. I don't see why that should also mean "that you will loss if
you exit Emacs while a bit distracted".

We can simply add a customize option to set buffer-offer-save in
*scratch*. It's easier and more flexible to add the four or five lines
of a defcustom than another special file/buffer and the documentation
and cognitive load (for new users) that comes with it.

             Juanma

Re: A wish, a plea

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/22/07, Sascha Wilde <wilde@sha-bang.de> wrote:
>
>> > and it should not offer to save on exit by default?
>>
>> Yes!  This is an important part of the concept of *scratch*.
>
> IMO "scratch" carries the meaning of a storage area for work in
> progress.

Huh?  The principal meaning of "Scratch that." is to throw something
away.

-- 
David Kastrup

Re: A wish, a plea

[Juanma Barranquero]

On 6/22/07, David Kastrup <dak@gnu.org> wrote:

> Huh?  The principal meaning of "Scratch that." is to throw something
> away.

Throw away. As a voluntary act. Not lose by accident. That's what
we're discussing here.

             Juanma

Re: A wish, a plea

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/22/07, David Kastrup <dak@gnu.org> wrote:
>
>> Huh?  The principal meaning of "Scratch that." is to throw something
>> away.
>
> Throw away. As a voluntary act. Not lose by accident. That's what
> we're discussing here.

That sounds to me as sensible as putting the cat habitually in a
garbage bin temporarily, then complaining that the garbage men do not
even take a look at what they are taking away, since garbage should be
declared to be garbage by virtue of a voluntary act, not just by
sitting in the garbage bin.

I strongly object to "*scratch*" getting semantics that make it
useless as a scratch pad by asking for confirmation and similar stuff.

If people use *scratch* for creating documents, lisp-interaction-mode
is the wrong mode, anyway.

I'll readily agree to have a default buffer "*unnamed*" in text mode
selected when Emacs is called without filenames (or when other buffers
have been deleted), a buffer which asks to be saved when changed,
prompting for a file name, but I certainly want to keep *scratch*
around with its current semantics.

It would also be ok with me if the _emergency_ recreated buffer when
all buffers have been deleted would be "*unnamed*".  But I think it
important that *scratch* is available as a bottom level buffer from
the start (so that people may notice it), and that it is recreated in
Lisp Interaction Mode, including the warning at its top, when I switch
to "*scratch*" and it does not exist.

-- 
David Kastrup

Re: A wish, a plea

[Juanma Barranquero]

On 6/22/07, David Kastrup <dak@gnu.org> wrote:

> That sounds to me as sensible as putting the cat habitually in a
> garbage bin temporarily, then complaining that the garbage men do not
> even take a look at what they are taking away, since garbage should be
> declared to be garbage by virtue of a voluntary act, not just by
> sitting in the garbage bin.

Irrelevant, I think. I don't know anyone who puts the cat in the
garbage bin. I know people who lost data (code, in fact) because he
forgot that had been hacking around in *scratch*. David, this is
Juanma. Juanma, David. Nice to meet you.

I think Karl said it best: "[...] the failure mode of the status quo
is much more severe than the failure mode of being asked to save
scratch work that you don't want to save."

> If people use *scratch* for creating documents, lisp-interaction-mode
> is the wrong mode, anyway.

I don't often create documents in *scratch*, but I do hack code that
I'm unsure whether to add to some package (or my .emacs) or not. That
seems a sensible use of *scratch*. You insist on talking about
erroneous uses of *scratch*, while I think the issue is accidental
exiting of Emacs even when you're using *scratch* for its intended
goal.

             Juanma

Re: A wish, a plea

[Kim F. Storm]

Hacksaw <hacksaw@hacksaw.org> writes:

> So I started writing, and I wrote for quite a while, it was really
> flowing well, and I thought, hey, I should save, because I don't want
> to lose this, but in my reverie, I hit the ^X^C first.

Since both C-x and C-c are prefix keys, and thus used a lot in
sequence with other keys, C-x C-c has always seemed like a
particularly dangerous binding to me.

One of the first things I changed when I started to use Emacs was
to change the "kill-emacs" binding to C-x C-c C-x

(global-set-key "\C-x\C-c"	'nil)
(global-set-key "\C-x\C-c\C-x"	'save-buffers-kill-emacs)

C-x C-c C-x works really well (it is still easy to type, and I've
never hit it accidentally).


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: A wish, a plea

[Jason Rumney]

Kim F. Storm wrote:
> One of the first things I changed when I started to use Emacs was
> to change the "kill-emacs" binding to C-x C-c C-x
>   

I just disable it completely and use M-x kill-emacs on the rare cases I
want to quit emacs. But I can see its use if you are on a text terminal
(and not familiar with suspending and resuming programs).

Re: A wish, a plea

[Nick Roberts]

 > Since both C-x and C-c are prefix keys, and thus used a lot in
 > sequence with other keys, C-x C-c has always seemed like a
 > particularly dangerous binding to me.

Add to that the fact that C is next to X and if you miss-hit the X key slightly
you can press X then C in quick succession.  I've exited a few sessions
prematurely that way.

 > One of the first things I changed when I started to use Emacs was
 > to change the "kill-emacs" binding to C-x C-c C-x
 > 
 > (global-set-key "\C-x\C-c"	'nil)
 > (global-set-key "\C-x\C-c\C-x"	'save-buffers-kill-emacs)
 > 
 > C-x C-c C-x works really well (it is still easy to type, and I've
 > never hit it accidentally).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: A wish, a plea

[David House]

Nick Roberts writes:
 > Add to that the fact that C is next to X and if you miss-hit the X key
 > slightly you can press X then C in quick succession. I've exited a few
 > sessions prematurely that way.

Me too, it was always an annoying binding for me. 

Personally I always use Emacs in X, so I just use Alt+F4 to quit, like I do in
every other application. I've also unbound C-z, which is pretty useless in a
graphical system, and forces me to use the mouse to un-minimise the frame again.

-- 
-David House, dmhouse@gmail.com

Re: A wish, a plea

[Nic James Ferrier]

storm@cua.dk (Kim F. Storm) writes:

> One of the first things I changed when I started to use Emacs was
> to change the "kill-emacs" binding to C-x C-c C-x
>
> (global-set-key "\C-x\C-c"	'nil)
> (global-set-key "\C-x\C-c\C-x"	'save-buffers-kill-emacs)
>
> C-x C-c C-x works really well (it is still easy to type, and I've
> never hit it accidentally).

I agree with this as well, I use F12 and I never hit it by accident
anymore. I used to quit emacs accidentally about 3 times a week.


But I suspect that there's likely to be a barrage of people claiming
that it is vital to their usage of Emacs that C-x C-c always be quit.

(just joking, those people, don't shout at me)

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

RE: A wish, a plea

[Drew Adams]

> > C-x C-c C-x works really well (it is still easy to type, and I've
> > never hit it accidentally).
>
> I agree with this as well, I use F12 and I never hit it by accident
> anymore. I used to quit emacs accidentally about 3 times a week.

If some who are quite used to Emacs hit that key sequence by accident 3
times a week (if you start Emacs once a day, that's a lot!), then perhaps
the default binding should be changed.

Any key binding can be hit accidentally, especially one with repetition such
as C-x C-c C-x. If response is slow for some reason, a user might hit the
same key again, thinking it wasn't received. If we're going to opt for a
3-stroke exit, then why not `C-x C-c y'? That is, why not show the user a
message asking whether to exit?

I use a `kill-emacs-query-functions' y-or-n-p confirmation:
(add-hook 'kill-emacs-query-functions
          (lambda () (y-or-n-p "Do you really want to exit Emacs? "))
          'append)

Re: A wish, a plea

[Nic James Ferrier]

"Drew Adams" <drew.adams@oracle.com> writes:

> If some who are quite used to Emacs hit that key sequence by accident 3
> times a week (if you start Emacs once a day, that's a lot!), then perhaps
> the default binding should be changed.

I'm not just quite used to Emacs. I've used it for several hours a
day, everyday for more than 10 years. I code in it, I write in it, I
read my email in it, etc...

And still I couldn't train myself to not kill Emacs that way.



> Any key binding can be hit accidentally, especially one with repetition such
> as C-x C-c C-x. If response is slow for some reason, a user might hit the
> same key again, thinking it wasn't received. If we're going to opt for a
> 3-stroke exit, then why not `C-x C-c y'? That is, why not show the user a
> message asking whether to exit?
>
> I use a `kill-emacs-query-functions' y-or-n-p confirmation:
> (add-hook 'kill-emacs-query-functions
>           (lambda () (y-or-n-p "Do you really want to exit Emacs? "))
>           'append)

As I said on an earlier thread. My brain just trained me to answer
whatever was the quickest way to get myself into trouble.

The problem didn't go away for me until I unbound kill-emacs from any
kind of "normal Emacs" key combo. I like somebody's suggestion of
Alt+F4... but I use F12 bound inside Emacs.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> Any key binding can be hit accidentally, especially one with repetition such
> as C-x C-c C-x.

In my experience, you just wont hit that specific sequence by accident
-- ok, maybe I did hit it once or twice since 1985, but once every 10
year is tolerable :-)

BTW, with current bindings, you won't usually know you used that sequence...
Emacs already quitted when you hit the second key :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: A wish, a plea

[Nic James Ferrier]

storm@cua.dk (Kim F. Storm) writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> Any key binding can be hit accidentally, especially one with repetition such
>> as C-x C-c C-x.
>
> In my experience, you just wont hit that specific sequence by accident
> -- ok, maybe I did hit it once or twice since 1985, but once every 10
> year is tolerable :-)

What about if you mistype something else as C-x C-c and then type C-x.

I can see myself doing it.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[David House]

Nic James Ferrier writes:
 > What about if you mistype something else as C-x C-c and then type C-x.
 > 
 > I can see myself doing it.

Well those people who are using that sequence right now say they don't hit
accidentally. Experience trumps hypotheticals.

That's no reason not to strive for an even better key sequence, though. Perhaps
we could make C-x C-c a prefix key, with C-x C-c k killing Emacs, C-x C-c s
killing Emacs but asking to save each buffer first (save-buffers-kill-emacs),
and C-x C-c z being iconify-or-deiconify-frame?

-- 
-David House, dmhouse@gmail.com

RE: A wish, a plea

[Drew Adams]

> > Any key binding can be hit accidentally, especially one with
> > repetition such as C-x C-c C-x.
>
> In my experience, you just wont hit that specific sequence by accident
> -- ok, maybe I did hit it once or twice since 1985, but once every 10
> year is tolerable :-)

It was just an example. The point was to not only make the binding more
difficult to type accidentally, but to also display a confirmation message
that points out what's happening, which can be important in case of a typing
mistake.

The number of keystrokes is the same (3) in those two examples:

 C-x C-c C-x
 C-x C-c y

But in the second case you at least see a confirmation message. In practice,
this has served me well many times: If I really intend to exit, then I type
`C-x C-c y' all at once, but if I accidentally hit `C-x C-c' then I see the
message and hit `n' or C-g. Also, `C-x C-c y' requires me to use both hands
(I use both hands to type), since `y' is on the right hand, and that makes
it even more unlikely that I would accidentally type `C-x C-c y'.

Use of `kill-emacs-query-functions' with `y-or-n-p' isn't tied to `C-x C-c',
of course. This suggestion is independent of suggestions by others to use a
different binding than `C-x C-c'. (`C-x C-c' is OK by me, though.)

I propose that we add such a function to `kill-emacs-query-functions' by
default. Any experienced user can always use `remove-hook' to get rid of it,
if desired.

Re: A wish, a plea

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> I use a `kill-emacs-query-functions' y-or-n-p confirmation:

,----[ C-h v confirm-kill-emacs RET ]
| confirm-kill-emacs is a variable defined in `files.el'.
| Its value is y-or-n-p
| 
| 
| Documentation:
| How to ask for confirmation when leaving Emacs.
| If nil, the default, don't ask at all.  If the value is non-nil, it should
| be a predicate function such as `yes-or-no-p'.
| 
| You can customize this variable.
`----

RE: A wish, a plea

[Drew Adams]

> > I use a `kill-emacs-query-functions' y-or-n-p confirmation:
>
> confirm-kill-emacs is a variable defined in `files.el'

You're right. Thanks, I forgot about that option. (I use Emacs 20 most of
the time - no such option.)

I change my proposal from this:

> add such a function to `kill-emacs-query-functions' by default.

to this:

 Change the default value of `confirm-kill-emacs' to `y-or-n-p'.

Re: A wish, a plea

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > I use a `kill-emacs-query-functions' y-or-n-p confirmation:
>>
>> confirm-kill-emacs is a variable defined in `files.el'
>
> You're right. Thanks, I forgot about that option. (I use Emacs 20 most of
> the time - no such option.)

Considering the amount of proposals you make for Emacs 22+, maybe you
should actually use a more recent Emacs regularly: it might help
focusing on relevant issues.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: A wish, a plea

[Drew Adams]

> >> > I use a `kill-emacs-query-functions' y-or-n-p confirmation:
> >>
> >> confirm-kill-emacs is a variable defined in `files.el'
> >
> > You're right. Thanks, I forgot about that option. (I use Emacs
> > 20 most of the time - no such option.)
>
> Considering the amount of proposals you make for Emacs 22+, maybe you
> should actually use a more recent Emacs regularly: it might help
> focusing on relevant issues.

Maybe you shouldn't worry about what I choose to use, and judge my
contributions on their technical merits. Maybe you should provide concrete
arguments to back up your insinuation that I need help focusing on relevant
issues.

FYI, my contributions to this thread were 100% relevant, regardless of my
having forgotten about that user option:

1. I proposed a new `visit-on-startup' option for startup, which covers all
of the behaviors discussed so far. I proposed that the default value be
`~/'.

2. I mentioned that a better solution (than bindings such as `C-x C-c C-x')
to the accidental exit problem is to use a confirmation message for
`save-buffers-kill-emacs'.

How to implement that solution is secondary to the discussion. I use an
implementation that works on multiple Emacs versions because I use multiple
versions and I write code for multiple versions. Emacs 22+ can use
`confirm-kill-emacs'.

Maybe _you_ should focus on relevant issues instead of caustic, unsolicited
personal advice.

(BTW, it's "number" of proposals, not "amount" of proposals.)

Re: A wish, a plea

[Juanma Barranquero]

On 6/24/07, Drew Adams <drew.adams@oracle.com> wrote:

> 2. I mentioned that a better solution (than bindings such as `C-x C-c C-x')
> to the accidental exit problem is to use a confirmation message for
> `save-buffers-kill-emacs'.

It's not better just because you like it. There are people who don't
want to be asked, and also don't want to exit Emacs by accident.

> (BTW, it's "number" of proposals, not "amount" of proposals.)

Why? Who says so?

             Juanma

RE: A wish, a plea

[Drew Adams]

> > 2. I mentioned that a better solution (than bindings such as 
> >    `C-x C-c C-x') to the accidental exit problem is to use a
> >    confirmation message for `save-buffers-kill-emacs'.
> 
> It's not better just because you like it.

Nor did anyone claim that. I did not even claim in #2 that what I mentioned is a better solution. #2 says that _I mentioned that_ a better solution is.... That is, #2 says that I claimed _previously_ that a better solution is....

No, of course my proposal is not better _because_ I like it. I gave reasons why it is better. #2 is the summary, not the argument.

The point was that my proposals were pertinent to the discussion. Whether or not #2 refers to the best proposal of its kind, and whether or not Juanma likes it, are irrelevant to pointing out that the proposal was relevant to the discussion.

> There are people who don't want to be asked, and also don't want
> to exit Emacs by accident.

Yes, of course there are. They can customize `confirm-kill-emacs'.

The default value of `confirm-kill-emacs' should be non-nil (I vote for `y-or-n-p'), to help newbies (as well as some of us oldies) protect against accidental loss of data (work). (Yes, that "should" is _IMO_. No, I don't claim that Juanma agrees with me.) 

> > (BTW, it's "number" of proposals, not "amount" of proposals.)
> 
> Why? Who says so?

(It's only a parenthetic "BTW", FYI, FWIW.) 

Why? Because proposals are countable.

Who says so? Current English usage, as always (there is no ruling English Academy). Here are the top Google hits ("amount number grammar"). Carry on further down the hit list if the top entries are not to your liking.

http://www.drgrammar.org/faqs/#5

http://www.bbc.co.uk/worldservice/learningenglish/grammar/learnit/learnitv129.shtml

http://www.grammar-monster.com/lessons/singular_lessons.htm

http://wwwnew.towson.edu/ows/exerciseamount.htm

http://wwwnew.towson.edu/ows/amount.htm

When English usage changes this grammar rule (in, say, 25, 50, 100, or 200 years), Google and I will reflect that ;-).

Re: A wish, a plea

[Juanma Barranquero]

On 6/24/07, Drew Adams <drew.adams@oracle.com> wrote:

> No, of course my proposal is not better _because_ I like it. I gave reasons why it is better. #2 is the summary, not the argument.

So it's not better. You just have arguments that make *you* think that
it is better. So in discussing your contributions to this thread with
David, it does not add information that you said that this fix is
better. We're likely to suppose you think so of your own proposals.

> Whether or not #2 refers to the best proposal of its kind, and
> whether or not Juanma likes it, are irrelevant to pointing out
> that the proposal was relevant to the discussion.

I don't think you know anything about what I like or not about your proposal.

> Why? Because proposals are countable.

Then David was right. Your proposals are not countable.

             Juanma

Re: A wish, a plea

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/24/07, Drew Adams <drew.adams@oracle.com> wrote:
>
>> No, of course my proposal is not better _because_ I like it. I gave
>> reasons why it is better. #2 is the summary, not the argument.
>
> So it's not better.

[...]

>> Why? Because proposals are countable.
>
> Then David was right. Your proposals are not countable.

While there is a certain amusement value to it, we are at the moment
bitching about bitching when we could be bitching about Emacs.  Or
even work on it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A wish, a plea

[Juri Linkov]

> ,----[ C-h v confirm-kill-emacs RET ]
> | confirm-kill-emacs is a variable defined in `files.el'.
> | Its value is y-or-n-p

I customized this option to the same value long ago since this key
combination is easy to mistype.  But I guess changing its default value to
always ask confirmation will be undesirable for users who rebound it to
another key which is not easy to mistype.  Also this is undesirable when
exiting is invoked from the menu.

Maybe there should exist a new function (for putting it to confirm-kill-emacs),
and it should check if it was called by `C-x C-c' and ask confirmation
only in this case?

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: A wish, a plea

[Drew Adams]

> > ,----[ C-h v confirm-kill-emacs RET ]
> > | confirm-kill-emacs is a variable defined in `files.el'.
> > | Its value is y-or-n-p
>
> I customized this option to the same value long ago since this key
> combination is easy to mistype.  But I guess changing its default value to
> always ask confirmation will be undesirable for users who rebound it to
> another key which is not easy to mistype.  Also this is undesirable when
> exiting is invoked from the menu.
>
> Maybe there should exist a new function (for putting it to
> confirm-kill-emacs), and it should check if it was called by
> `C-x C-c' and ask confirmation only in this case?

Why? I don't get it. Why only for `C-x C-c'?

"Will be undesirable for users" who prefer something else is not a problem.
That will always be true for some users, no matter what the default behavior
is. But they can customize the option.

The real question is what the default behavior should be, and who it should
target. I argue that possible loss of data is important, and it is
especially important for newbies. Those who want to live more dangerously
and who don't want to be bothered by the confirmation query can customize
this.

Re: A wish, a plea

[Glyn Millington]

storm@cua.dk (Kim F. Storm) writes:

> Hacksaw <hacksaw@hacksaw.org> writes:
>
>> So I started writing, and I wrote for quite a while, it was really
>> flowing well, and I thought, hey, I should save, because I don't want
>> to lose this, but in my reverie, I hit the ^X^C first.
>
> Since both C-x and C-c are prefix keys, and thus used a lot in
> sequence with other keys, C-x C-c has always seemed like a
> particularly dangerous binding to me.
>
> One of the first things I changed when I started to use Emacs was
> to change the "kill-emacs" binding to C-x C-c C-x
>
> (global-set-key "\C-x\C-c"	'nil)
> (global-set-key "\C-x\C-c\C-x"	'save-buffers-kill-emacs)
>
> C-x C-c C-x works really well (it is still easy to type, and I've
> never hit it accidentally).


Another way round - pretty sure this isn't mine!!

;;; Don't quit unless you mean it!
  (defun maybe-save-buffers-kill-emacs (really)
      "If REALLY is 'yes', call save-buffers-kill-emacs."
      (interactive "sAre you sure about this? ")
      (if (equal really "yes")
          (save-buffers-kill-emacs)))
    (global-set-key [(control x) (control c)] 'maybe-save-buffers-kill-emacs)



atb 




Glyn

Re: A wish, a plea

[Nic James Ferrier]

Glyn Millington <wistanswick@linuxmail.org> writes:

> Another way round - pretty sure this isn't mine!!
>
> ;;; Don't quit unless you mean it!
>   (defun maybe-save-buffers-kill-emacs (really)
>       "If REALLY is 'yes', call save-buffers-kill-emacs."
>       (interactive "sAre you sure about this? ")
>       (if (equal really "yes")
>           (save-buffers-kill-emacs)))
>     (global-set-key [(control x) (control c)]
>   'maybe-save-buffers-kill-emacs)

It doesn't work for me. My braind had trained me to skip the question
(can't remember what response I was using, "no" presumably).

So the effect was the same thing as just quit.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   

Re: A wish, a plea

[Glyn Millington]

Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:

> Glyn Millington <wistanswick@linuxmail.org> writes:
>
>> Another way round - pretty sure this isn't mine!!
>>
>> ;;; Don't quit unless you mean it!
>>   (defun maybe-save-buffers-kill-emacs (really)
>>       "If REALLY is 'yes', call save-buffers-kill-emacs."
>>       (interactive "sAre you sure about this? ")
>>       (if (equal really "yes")
>>           (save-buffers-kill-emacs)))
>>     (global-set-key [(control x) (control c)]
>>   'maybe-save-buffers-kill-emacs)
>
> It doesn't work for me. My braind had trained me to skip the question
> (can't remember what response I was using, "no" presumably).
>
> So the effect was the same thing as just quit.

Eh?

You can only quit, using the above, if you type in "yes". Anything else
will leave you in the buffer on which you were working.

Sorry if I have misunderstood something.

atb

Glyn

Re: A wish, a plea

[Juanma Barranquero]

On 6/22/07, Kim F. Storm <storm@cua.dk> wrote:

> One of the first things I changed when I started to use Emacs was
> to change the "kill-emacs" binding to C-x C-c C-x
>
> (global-set-key "\C-x\C-c"      'nil)
> (global-set-key "\C-x\C-c\C-x"  'save-buffers-kill-emacs)

I wrapped save-buffers-kill-emacs in a little function that asks for
confirmation. I don't mind being asked every time; it's not that
frequent. But I hate exiting Emacs by accident.

             Juanma

Re: A wish, a plea

[Denis Bueno]

On 06/22/2007 02:01, "storm@cua.dk" <storm@cua.dk> wrote:
> (global-set-key "\C-x\C-c" 'nil)
> (global-set-key "\C-x\C-c\C-x" 'save-buffers-kill-emacs)

In this same vein, after I killed Emacs accidentally too many times, I just
deleted the C-x C-c binding altogether.  I'm happy to type M-x
save-buffers-kill-emacs RET (with partial-completion-mode this is just M-x
s-b-k-e) whenever I want to kill Emacs.

-Denis