*scratch* buffer (was: A wish, a plea)

*scratch* buffer (was: A wish, a plea)

[David Reitter]

Here's what we do in Aquamacs. Perhaps this applies to all of Emacs:

`initial-major-mode' and `default-major-mode' default to `text-mode'.
We assume that most people want to write one or another form of text  
or code in some language other than elisp. Text-mode provides basic  
support for that. We are pretty sure that the majority of users  
doesn't know much elisp, and of those who know it, only a minority  
will use Emacs predominantly to configure or extend Emacs.

The initial message in the *scratch* buffer is not shown. We want its  
function to be self-evident. Users are not required to read text  
before they get going (most people, even newbies, presumably don't  
read it anyways).

I am also intending to make the *scratch* buffer persistent across  
sessions.
That way, users will not be bothered to give it a name and to  
explicitly save it. But they will retain its contents across crashes  
and intentional restarts. If the desktop is a good analogy: when I  
come into my office in the morning, all my scratch papers are still  
on my desk. Even in companies that operate a "clean desk policy", the  
cleaners are not instructed to throw away everything that's on  
people's desks at 7am. (Or do they?)

Re: *scratch* buffer (was: A wish, a plea)

[Jason Rumney]

David Reitter wrote:
> I am also intending to make the *scratch* buffer persistent across
> sessions.
> That way, users will not be bothered to give it a name and to
> explicitly save it. But they will retain its contents across crashes
> and intentional restarts.

That might be a good idea if there is a simple and obvious command to
clear it when the user wants to start afresh.

Re: *scratch* buffer (was: A wish, a plea)

[David Reitter]

On 22 Jun 2007, at 12:57, Jason Rumney wrote:

> David Reitter wrote:
>> I am also intending to make the *scratch* buffer persistent across
>> sessions.
>> That way, users will not be bothered to give it a name and to
>> explicitly save it. But they will retain its contents across crashes
>> and intentional restarts.
>
> That might be a good idea if there is a simple and obvious command to
> clear it when the user wants to start afresh.

I was thinking of mark-whole-buffer, then delete (whatever keys are  
bound to that). That seems obvious to me.

Giving *scratch* the right buffer-file-name and turning on auto-save- 
mode is easy enough. If the file exists, its contents are loaded at  
startup and saved upon quit without user interaction.

One could generalize that mechanism with a customization variable:

persistent-buffers:
(("*scratch*" . "~/.emacs.scratch"))

so that the user can add further persistent buffers or remove the  
*scratch* buffer to turn of persistency.

I'm not sure about how useful this would be -?

Re: *scratch* buffer (was: A wish, a plea)

[Juanma Barranquero]

On 6/22/07, David Reitter <david.reitter@gmail.com> wrote:

> persistent-buffers:
> (("*scratch*" . "~/.emacs.scratch"))

I hope you meant

  (list (cons "*scratch*"
              (locate-user-data-file ".emacs.scratch" "scratch")))


Sorry, couldn't resist :)

             Juanma

Re: *scratch* buffer (was: A wish, a plea)

[Davis Herring]

> I was thinking of mark-whole-buffer, then delete (whatever keys are
> bound to that). That seems obvious to me.

There are no keys bound to delete-region by default, and in standard Emacs
normal keys like DEL and backspace do not destroy the region under any
circumstances.  We'd need something more reliable than this combo.

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: *scratch* buffer (was: A wish, a plea)

[David House]

Davis Herring writes:
 > There are no keys bound to delete-region by default, and in standard Emacs
 > normal keys like DEL and backspace do not destroy the region under any
 > circumstances.  We'd need something more reliable than this combo.

It doesn't have to be delete-region, it could be kill-region, which is bound to
C-w.

-- 
-David House, dmhouse@gmail.com

Re: *scratch* buffer (was: A wish, a plea)

[Davis Herring]

>  > There are no keys bound to delete-region by default, and in standard
> Emacs
>  > normal keys like DEL and backspace do not destroy the region under any
>  > circumstances.  We'd need something more reliable than this combo.
>
> It doesn't have to be delete-region, it could be kill-region, which is
> bound to
> C-w.

What we really want here is `erase-buffer', since the point of clearing a
persistent scratch space is not to put its contents somewhere else but
rather to allow it to be used for other things.  And if a prolific user
has written megabytes in *scratch*, putting that both on the undo list and
the kill ring when they really mean for it to be nowhere seems wrong. 
It's not all that important; I just don't want it assumed that
non-standard modes (Transient Mark, Delete Selection, CUA, etc.) obviate
the need for a "true" interface to such a feature.

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: *scratch* buffer (was: A wish, a plea)

[Richard Stallman]

    `initial-major-mode' and `default-major-mode' default to `text-mode'.
    We assume that most people want to write one or another form of text  
    or code in some language other than elisp. Text-mode provides basic  
    support for that. We are pretty sure that the majority of users  
    doesn't know much elisp, and of those who know it, only a minority  
    will use Emacs predominantly to configure or extend Emacs.

    The initial message in the *scratch* buffer is not shown. We want its  
    function to be self-evident. Users are not required to read text  
    before they get going (most people, even newbies, presumably don't  
    read it anyways).

It would seem that this does nothing to address the problem at hand.

Re: *scratch* buffer (was: A wish, a plea)

[Davis Herring]

> I am also intending to make the *scratch* buffer persistent across
> sessions.
> That way, users will not be bothered to give it a name and to
> explicitly save it. But they will retain its contents across crashes
> and intentional restarts. If the desktop is a good analogy: when I
> come into my office in the morning, all my scratch papers are still
> on my desk. Even in companies that operate a "clean desk policy", the
> cleaners are not instructed to throw away everything that's on
> people's desks at 7am. (Or do they?)

I realize that Mac does not believe in running two copies of the same
application (process), but taking that to be a Bad Assumption, I ask: how
does this deal in any even moderately graceful way with simultaneous
Emacses?  We have a persistent state, automatically saved, with no name,
that is surely to conflict with other *scratch*es.

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: *scratch* buffer

[Juri Linkov]

> I realize that Mac does not believe in running two copies of the same
> application (process), but taking that to be a Bad Assumption, I ask: how
> does this deal in any even moderately graceful way with simultaneous
> Emacses?  We have a persistent state, automatically saved, with no name,
> that is surely to conflict with other *scratch*es.

In the case of saving the scratch buffer in a file like ~/.emacs.d/scratch
the standard Emacs file locking mechanism takes care of this.

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

Re: *scratch* buffer

[Davis Herring]

> In the case of saving the scratch buffer in a file like ~/.emacs.d/scratch
> the standard Emacs file locking mechanism takes care of this.

So then editing *scratch* should generate lock-steal queries?  And
attempting to exit Emacs should have to prompt about overwriting a more
recent version of a file the user has -never visited-?  To me the implicit
persistence (or "invisible" saving) just sounds confusing.

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.