Emacs: Problems of the Scratch Buffer

Emacs: Problems of the Scratch Buffer

[Xah Lee]

for entertainment purpose only.

〈Emacs: Problems of the Scratch Buffer〉
http://xahlee.org/emacs/modernization_scratch_buffer.html

---------------------------------------------

Emacs: Problems of the Scratch Buffer
 By Xah Lee, 2008-09, …, 2012-04-18

Here are reasons that the scratch buffer is not useful to most people:

 1.It is not useful for 99% of emacs users. If people wanted a scratch
pad, they can open a new document and not save it. This way is
familiar to all software users.
 2.The “*scratch*” “buffer” is designed for emacs lisp programers. (it
defaults to lisp-interaction-mode.) 99% of emacs users are not lisp
coders.
 3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
not familiar what it is. It is the first thing presented to users, and
it persists.

Scratch Buffer is Inconvenient

Here are reasons that a alternative to “*scratch*” “buffer” is more
useful:

 1.There is no easy, intuitive way to create multiple scratch buffers.
(it is done by calling switch-to-buffer 【Ctrl+x b】 then give a name
that is not one of existing buffers.)
 2.When the scratch buffer is closed, emacs does not prompt user to
save it. This easily causes data loss.
 3.A scratch pad can be very useful not just for temporary elisp code
but for any scratch notes or programing in other languages. (For
example, well known programer Stevey Yegg in his popular blog article
Effective Emacs↗, considers creating new temp buffer as a top 10 tip
in emacs productivity.)
 4.Emacs does not provide a user level function to create a new
buffer. It has menu 〖File▸Open file…〗 (a wrapper to the find-file
command), which immediately prompt user for a full file path. This is
annoying. Modern apps's New File command actually just create a new
untitled file without prompting, and prompt only when user wants to
save it. If user closes it, it prompts for saving.

Proposed Fix: Adding a “new-buffer” Command

I propose that emacs should add a command “new-buffer” with menu
〖File▸New〗. Once called, it should create a empty buffer titled
{untitled, untitled<2>, untitled<3>, …}.

 1.Users can now create multiple temp buffers easily, by just calling
“new-buffer”. No more work-around using “switch-to-buffer” method.
 2.Data lose is prevented because closing any unsaved buffer will
prompt for save.
 3.For lisp coders, new buffer can default to a lisp mode. Other
programers can default it to python mode, ruby mode, etc.

 1.No more redundant and mysterious “*scratch*” concept.
 2.The menu command “New” is a widely adopted standard among apps
across Mac, Windows, Linux.
 3.A “new-buffer” command completely cover the functionality of
emacs's “*scratch*” buffer.
 4.The name “untitled” is conventional, widely understood.

Implementation

The above suggestion is implemented in ErgoEmacs Keybinding, where you
simply press 【Ctrl+n】 to create a new buffer.

Re: Emacs: Problems of the Scratch Buffer

[Joe Corneli]

A long time ago I wrote something called scrat.el that somewhat improves
scratch buffer functioning - what do you think?

http://lists.gnu.org/archive/html/gnu-emacs-sources/2004-06/msg00035.html

On Wed, Apr 18, 2012 at 1:00 PM, Xah Lee <xahlee@gmail.com> wrote:
> for entertainment purpose only.
>
> 〈Emacs: Problems of the Scratch Buffer〉
> http://xahlee.org/emacs/modernization_scratch_buffer.html
>
> ---------------------------------------------
>
> Emacs: Problems of the Scratch Buffer
>  By Xah Lee, 2008-09, …, 2012-04-18
>
> Here are reasons that the scratch buffer is not useful to most people:
>
>  1.It is not useful for 99% of emacs users. If people wanted a scratch
> pad, they can open a new document and not save it. This way is
> familiar to all software users.
>  2.The “*scratch*” “buffer” is designed for emacs lisp programers. (it
> defaults to lisp-interaction-mode.) 99% of emacs users are not lisp
> coders.
>  3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
> not familiar what it is. It is the first thing presented to users, and
> it persists.
>
> Scratch Buffer is Inconvenient
>
> Here are reasons that a alternative to “*scratch*” “buffer” is more
> useful:
>
>  1.There is no easy, intuitive way to create multiple scratch buffers.
> (it is done by calling switch-to-buffer 【Ctrl+x b】 then give a name
> that is not one of existing buffers.)
>  2.When the scratch buffer is closed, emacs does not prompt user to
> save it. This easily causes data loss.
>  3.A scratch pad can be very useful not just for temporary elisp code
> but for any scratch notes or programing in other languages. (For
> example, well known programer Stevey Yegg in his popular blog article
> Effective Emacs↗, considers creating new temp buffer as a top 10 tip
> in emacs productivity.)
>  4.Emacs does not provide a user level function to create a new
> buffer. It has menu 〖File▸Open file…〗 (a wrapper to the find-file
> command), which immediately prompt user for a full file path. This is
> annoying. Modern apps's New File command actually just create a new
> untitled file without prompting, and prompt only when user wants to
> save it. If user closes it, it prompts for saving.
>
> Proposed Fix: Adding a “new-buffer” Command
>
> I propose that emacs should add a command “new-buffer” with menu
> 〖File▸New〗. Once called, it should create a empty buffer titled
> {untitled, untitled<2>, untitled<3>, …}.
>
>  1.Users can now create multiple temp buffers easily, by just calling
> “new-buffer”. No more work-around using “switch-to-buffer” method.
>  2.Data lose is prevented because closing any unsaved buffer will
> prompt for save.
>  3.For lisp coders, new buffer can default to a lisp mode. Other
> programers can default it to python mode, ruby mode, etc.
>
>  1.No more redundant and mysterious “*scratch*” concept.
>  2.The menu command “New” is a widely adopted standard among apps
> across Mac, Windows, Linux.
>  3.A “new-buffer” command completely cover the functionality of
> emacs's “*scratch*” buffer.
>  4.The name “untitled” is conventional, widely understood.
>
> Implementation
>
> The above suggestion is implemented in ErgoEmacs Keybinding, where you
> simply press 【Ctrl+n】 to create a new buffer.

Re: Emacs: Problems of the Scratch Buffer

[Steinar Bang]

>>>>> Xah Lee <xahlee@gmail.com>:

>  3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
> not familiar what it is. It is the first thing presented to users, 

No it's not.

The first thing presented to users is the banner buffer.

RE: Emacs: Problems of the Scratch Buffer

[Ludwig, Mark]

> From: Steinar Bang
> Sent: Wednesday, April 18, 2012 11:57 AM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs: Problems of the Scratch Buffer
> 
> >>>>> Xah Lee <xahlee@gmail.com>:
> 
> >  3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
> > not familiar what it is. It is the first thing presented to users,
> 
> No it's not.
> 
> The first thing presented to users is the banner buffer.

Not consistently, and it would be more useful if it just sat there indefinitely.  It times out, right?  Also, if you touch any key that it isn't expecting, it disappears, doesn't it?

At the moment, "emacs -Q" (23.1 on Windows) is dropping me into *scratch* ... (*shrug*) but I know I sometimes see that banner....  I thought I understood this, but anyway it's making the original argument rather well, I think.  

Anyway, I've been an Emacs Lisp hacker for >20 years, and I very rarely use *scratch*; when I do, it has never been first thing I wanted to do....  (I also rather dislike the 'reuse' characteristics that keep placing newer output from repeated Lisp expressions at the end....)

Cheers,
Mark

Re: Emacs: Problems of the Scratch Buffer

[Juanma Barranquero]

On Wed, Apr 18, 2012 at 19:33, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> At the moment, "emacs -Q" (23.1 on Windows) is dropping me into *scratch* ...

If it hurts, don't do that.

emacs --help
...
--quick, -Q                 equivalent to:
                              -q --no-site-file --no-site-lisp --no-splash
...

so it's no surprise that you don't see the splash screen. Try

emacs -q --no-site-file --no-site-lisp

    Juanma

Re: Emacs: Problems of the Scratch Buffer

[Juanma Barranquero]

On Wed, Apr 18, 2012 at 20:15, Juanma Barranquero <lekktu@gmail.com> wrote:

> emacs -q --no-site-file --no-site-lisp

--no-site-lisp does not exist in 23.1, so just  "-q --no-site-file" will do.

    Juanma

Re: Emacs: Problems of the Scratch Buffer

[Steinar Bang]

>>>>> "Ludwig, Mark" <ludwig.mark@siemens.com>:

> Anyway, I've been an Emacs Lisp hacker for >20 years, and I very
> rarely use *scratch*;

I use the *scratch* buffer all the time.  I use it as a generic
copy/paste text buffer, and I use it to evaluate lisp expression (mostly
just using it as a calculator).

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Wed, 18 Apr 2012 17:33:07 +0000, Ludwig, Mark wrote:

> Not consistently, and it would be more useful if it just sat there
> indefinitely.  It times out, right?  Also, if you touch any key that it
> isn't expecting, it disappears, doesn't it?

Hmm... not for me.  It comes up consistently for me, and won't go away 
until I close it or switch to another buffer (or create one).

I'm using emacs23, FWIW...

-- 
Suspicion always haunts the guilty mind.
		-- Wm. Shakespeare

RE: Emacs: Problems of the Scratch Buffer

[Ludwig, Mark]

> From: Chiron
> Sent: Wednesday, April 18, 2012 4:11 PM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs: Problems of the Scratch Buffer
> 
> On Wed, 18 Apr 2012 17:33:07 +0000, Ludwig, Mark wrote:
> 
> > Not consistently, and it would be more useful if it just sat there
> > indefinitely.  It times out, right?  Also, if you touch any key that it
> > isn't expecting, it disappears, doesn't it?
> 
> Hmm... not for me.  It comes up consistently for me, and won't go away
> until I close it or switch to another buffer (or create one).
> 
> I'm using emacs23, FWIW...

I stand corrected.  Using 'emacs -q' shows the startup screen, and it does appear more durable than I remembered.  Good!

Now, I don't see anything in my .emacs that should prevent the startup screen from appearing, but it's not appearing.  How does Emacs decide whether to show the startup screen?  I know that if I ask to open a file immediately, it will not show the startup screen, but if I just invoke 'runemacs' (this is Windows), there is no startup screen or buffer, and I am presented with *scratch*.  Why isn't it showing the startup screen?

Thanks,
Mark

Re: Emacs: Problems of the Scratch Buffer

[Tassilo Horn]

"Ludwig, Mark" <ludwig.mark@siemens.com> writes:

Hi Mark,

> I stand corrected.  Using 'emacs -q' shows the startup screen, and it
> does appear more durable than I remembered.  Good!
>
> Now, I don't see anything in my .emacs that should prevent the startup
> screen from appearing, but it's not appearing.  How does Emacs decide
> whether to show the startup screen?

,----[ (info "(emacs)Entering Emacs") ]
|    If the variable `inhibit-startup-screen' is non-`nil', Emacs does
| not display the startup screen.  In that case, if one or more files
| were specified on the command line, Emacs simply displays those files;
| otherwise, it displays a buffer named `*scratch*', which can be used to
| evaluate Emacs Lisp expressions interactively.  *Note Lisp
| Interaction::.  You can set the variable `inhibit-startup-screen' using
| the Customize facility (*note Easy Customization::), or by editing your
| initialization file (*note Init File::).(1)
| 
|    You can also force Emacs to display a file or directory at startup
| by setting the variable `initial-buffer-choice' to a non-`nil' value.
| (In that case, even if you specify one or more files on the command
| line, Emacs opens but does not display them.)  The value of
| `initial-buffer-choice' should be the name of the desired file or
| directory.
`----

Bye,
Tassilo

Re: Emacs: Problems of the Scratch Buffer

[Mark Skilbeck]

Isn't idiosyncratic behaviour idiosyncratic for a reason?

- mgsk

Re: Emacs: Problems of the Scratch Buffer

[Aaron Meurer]

On Wed, Apr 18, 2012 at 6:00 AM, Xah Lee <xahlee@gmail.com> wrote:
> for entertainment purpose only.
>
> 〈Emacs: Problems of the Scratch Buffer〉
> http://xahlee.org/emacs/modernization_scratch_buffer.html
>
> ---------------------------------------------
>
> Emacs: Problems of the Scratch Buffer
>  By Xah Lee, 2008-09, …, 2012-04-18
>
> Here are reasons that the scratch buffer is not useful to most people:
>
>  1.It is not useful for 99% of emacs users. If people wanted a scratch
> pad, they can open a new document and not save it. This way is
> familiar to all software users.
>  2.The “*scratch*” “buffer” is designed for emacs lisp programers. (it
> defaults to lisp-interaction-mode.) 99% of emacs users are not lisp
> coders.
>  3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
> not familiar what it is. It is the first thing presented to users, and
> it persists.
>
> Scratch Buffer is Inconvenient
>
> Here are reasons that a alternative to “*scratch*” “buffer” is more
> useful:
>
>  1.There is no easy, intuitive way to create multiple scratch buffers.
> (it is done by calling switch-to-buffer 【Ctrl+x b】 then give a name
> that is not one of existing buffers.)
>  2.When the scratch buffer is closed, emacs does not prompt user to
> save it. This easily causes data loss.

I think this is the whole point.

>  3.A scratch pad can be very useful not just for temporary elisp code
> but for any scratch notes or programing in other languages. (For
> example, well known programer Stevey Yegg in his popular blog article
> Effective Emacs↗, considers creating new temp buffer as a top 10 tip
> in emacs productivity.)

I agree.  The scratch buffer seems to be made so you could easily type
and execute lisp code interactively.  But even if you just want to run
one lisp command, you can type it literally anywhere and type C-x C-e
(the disadvantage is you won't get syntax highlighting or completion
if you are not in lisp-mode).  IMHO, *scratch* should default to
text-mode.

>  4.Emacs does not provide a user level function to create a new
> buffer. It has menu 〖File▸Open file…〗 (a wrapper to the find-file
> command), which immediately prompt user for a full file path. This is
> annoying. Modern apps's New File command actually just create a new
> untitled file without prompting, and prompt only when user wants to
> save it. If user closes it, it prompts for saving.
>
> Proposed Fix: Adding a “new-buffer” Command
>
> I propose that emacs should add a command “new-buffer” with menu
> 〖File▸New〗. Once called, it should create a empty buffer titled
> {untitled, untitled<2>, untitled<3>, …}.
>
>  1.Users can now create multiple temp buffers easily, by just calling
> “new-buffer”. No more work-around using “switch-to-buffer” method.
>  2.Data lose is prevented because closing any unsaved buffer will
> prompt for save.
>  3.For lisp coders, new buffer can default to a lisp mode. Other
> programers can default it to python mode, ruby mode, etc.

+1 for this plan.

One thing, though.  I do like how opening emacs with no files gives
you the scratch buffer.  I just think it should default to text mode.

>
>  1.No more redundant and mysterious “*scratch*” concept.
>  2.The menu command “New” is a widely adopted standard among apps
> across Mac, Windows, Linux.
>  3.A “new-buffer” command completely cover the functionality of
> emacs's “*scratch*” buffer.
>  4.The name “untitled” is conventional, widely understood.
>
> Implementation
>
> The above suggestion is implemented in ErgoEmacs Keybinding, where you
> simply press 【Ctrl+n】 to create a new buffer.

Well you'd need a normal keybinding too, assumedly one that's C-x
C-something.  C-n moves down a line, and I don't think that's going to
change any time soon.

Aaron Meurer

Re: Emacs: Problems of the Scratch Buffer

[Deniz Dogan]

On 2012-04-18 21:33, Aaron Meurer wrote:
> On Wed, Apr 18, 2012 at 6:00 AM, Xah Lee<xahlee@gmail.com>  wrote:
> >   2.When the scratch buffer is closed, emacs does not prompt user to
>> save it. This easily causes data loss.
>
> I think this is the whole point.
>

Indeed.  Any buffer whose name starts and ends with an apostrophe has 
this behavior, if I remember correctly.

Re: Emacs: Problems of the Scratch Buffer

[Kevin Rodgers]

On 4/18/12 2:22 PM, Deniz Dogan wrote:
> On 2012-04-18 21:33, Aaron Meurer wrote:
>> On Wed, Apr 18, 2012 at 6:00 AM, Xah Lee<xahlee@gmail.com> wrote:
>> > 2.When the scratch buffer is closed, emacs does not prompt user to
>>> save it. This easily causes data loss.
>>
>> I think this is the whole point.
>>
>
> Indeed. Any buffer whose name starts and ends with an apostrophe has this
> behavior, if I remember correctly.

s/apostrophe/asterisk/

I think that's just a convention, but not enforced by Emacs.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Emacs: Problems of the Scratch Buffer

[Kevin Rodgers]

On 4/18/12 1:33 PM, Aaron Meurer wrote:
> On Wed, Apr 18, 2012 at 6:00 AM, Xah Lee<xahlee@gmail.com>  wrote:
...
>>   3.A scratch pad can be very useful not just for temporary elisp code
>> but for any scratch notes or programing in other languages. (For
>> example, well known programer Stevey Yegg in his popular blog article
>> Effective Emacs↗, considers creating new temp buffer as a top 10 tip
>> in emacs productivity.)
>
> I agree.  The scratch buffer seems to be made so you could easily type
> and execute lisp code interactively.  But even if you just want to run
> one lisp command, you can type it literally anywhere and type C-x C-e
> (the disadvantage is you won't get syntax highlighting or completion
> if you are not in lisp-mode).  IMHO, *scratch* should default to
> text-mode.

(setq initial-major-mode 'text-mode)

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Emacs: Problems of the Scratch Buffer

[Bug Dout]

Several good points. But given the ultra-conservative nature of
emacsians, changes will never be implemented. Gnu Emacs remains firmly
in the last century.
-- 
The reasonable man adjusts himself to the world, the unreasonable one
persists in trying to adapt the world to himself; therefore all
progress depends on the unreasonable man.
 ~ George Bernard Shaw

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Thu, 19 Apr 2012 13:47:40 -0700, Bug Dout wrote:

> Several good points. But given the ultra-conservative nature of
> emacsians, changes will never be implemented. Gnu Emacs remains firmly
> in the last century.

See, saying things like that (GNU Emacs is in the last century) doesn't 
actually show that GNU Emacs is in any way deficient.  One problem with 
computers and software is that there is this mad scramble to have the 
latest whatever.  Most of the time, sure, it's better.  But "new" doesn't 
*automatically* mean better.  You could equally say that GNU Emacs has 
"stood the test of time."

But both claims are bullshit.  They say nothing at all about whether GNU 
Emacs should change, or how.  One claims "new is better," while the other 
claims "new is better."  The truth is, "better is better."

And really, "better" is a judgement made by each user.  Most of the 
arguments about Emacs make as much sense as arguing about what shoe size 
is "better."  It's the shoes that fit your own feet that are better.

So with Emacs.  Some people are never going to find it a good fit for 
their needs and habits.  They'll want to change it or use another tool.  
Others do find it a good fit.  They're not going to want to change it.

If Emacs works for you, use it.  If not, don't, or fix what you feel is 
wrong with it.  It's nothing but the most highly customizable editor on 
the planet.

-- 
I believe that professional wrestling is clean and everything else in
the world is fixed.
		-- Frank Deford, sports writer

RE: Emacs: Problems of the Scratch Buffer

[Ludwig, Mark]

> From: Chiron
> Sent: Thursday, April 19, 2012 4:12 PM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs: Problems of the Scratch Buffer
> 
> On Thu, 19 Apr 2012 13:47:40 -0700, Bug Dout wrote:
> 
> > Several good points. But given the ultra-conservative nature of
> > emacsians, changes will never be implemented. Gnu Emacs remains firmly
> > in the last century.
> 
> And really, "better" is a judgement made by each user....  
> 
> If Emacs works for you, use it.  If not, don't, or fix what you feel is
> wrong with it.  It's nothing but the most highly customizable editor on
> the planet.

Right, and I appreciate learning some simple ways to make *scratch* more useful, as well as finding the stray code in .emacs that was suppressing the startup screen.

The original post was from someone who doesn't like *scratch* to be the first thing he sees.  It seems clear that something in his customization is suppressing the normal startup screen (including possibly something at the site done by someone who likes seeing *scratch*...).

Cheers,
Mark

Re: Emacs: Problems of the Scratch Buffer

[Pascal J. Bourguignon]

"Ludwig, Mark" <ludwig.mark@siemens.com> writes:

> The original post was from someone who doesn't like *scratch* to be
> the first thing he sees.  It seems clear that something in his
> customization is suppressing the normal startup screen (including
> possibly something at the site done by someone who likes seeing
> *scratch*...).

The original post was from someone who's an narcissistic idiot who
prefers to write hundreds of lines of profanities instead of adding a
single line to his ~/.emacs:

    (kill-buffer (get-buffer "*scratch*"))


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: Emacs: Problems of the Scratch Buffer

[Aaron Meurer]

On Thu, Apr 19, 2012 at 9:27 PM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
> "Ludwig, Mark" <ludwig.mark@siemens.com> writes:
>
>> The original post was from someone who doesn't like *scratch* to be
>> the first thing he sees.  It seems clear that something in his
>> customization is suppressing the normal startup screen (including
>> possibly something at the site done by someone who likes seeing
>> *scratch*...).
>
> The original post was from someone who's an narcissistic idiot who
> prefers to write hundreds of lines of profanities instead of adding a
> single line to his ~/.emacs:

I refer you to the very first line of the very first post in this thread.

Aaron Meurer

>
>    (kill-buffer (get-buffer "*scratch*"))
>
>
> --
> __Pascal Bourguignon__                     http://www.informatimago.com/
> A bad day in () is better than a good day in {}.

Re: Emacs: Problems of the Scratch Buffer

[Fritz Wuehler]

Very nice post and true way beyond Emacs.

Re: Emacs: Problems of the Scratch Buffer

[Richard Riley]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> If Emacs works for you, use it.  If not, don't, or fix what you feel is 
> wrong with it.  It's nothing but the most highly customizable editor on 
> the planet.


And there is the core problem with so many Emacs types. Dont like it
dont use it. God forbid it could *easily* be made more accessible to new
adopters : the hard core are more than capable of re-enabling the
somewhat out of date and history rooted "defaults" such as an elisp
*scratch* as the first buffer you see or the hideous cut & paste
defaults which leave those coming from the desktops which, like it or lump it,
account for 97% of computers totally lost and bemused.

I love emacs, but this "dont like dont use it" attitude is
ridiculous. its a great piece of SW hekp to make it appeal : more users
== more maintainers == more ideas == better product. "I'm alright Jack"
attitude wont do anything to improve its usage. And usage IS important
to ensure its future. Just look at how behind it is with regards to mix
mode programming and Java in particular : and no, no one wants to know
how "mixed mode programming sucks" - its exists and is common.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Fri, 20 Apr 2012 13:48:34 +0200, Richard Riley wrote:

> Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:
> 
>> If Emacs works for you, use it.  If not, don't, or fix what you feel is
>> wrong with it.  It's nothing but the most highly customizable editor on
>> the planet.
> 
> 
> And there is the core problem with so many Emacs types. Dont like it
> dont use it. God forbid it could *easily* be made more accessible to new
> adopters : the hard core are more than capable of re-enabling the
> somewhat out of date and history rooted "defaults" such as an elisp
> *scratch* as the first buffer you see or the hideous cut & paste
> defaults which leave those coming from the desktops which, like it or
> lump it, account for 97% of computers totally lost and bemused.
> 
> I love emacs, but this "dont like dont use it" attitude is ridiculous.
> its a great piece of SW hekp to make it appeal : more users == more
> maintainers == more ideas == better product. "I'm alright Jack" attitude
> wont do anything to improve its usage. And usage IS important to ensure
> its future. Just look at how behind it is with regards to mix mode
> programming and Java in particular : and no, no one wants to know how
> "mixed mode programming sucks" - its exists and is common.

OK, so here's the situation, as I understand it:

1.  The maintainers of emacs are happy with the way it is right now.

2.  The maintainers probably *use* emacs for their work - so it's one of 
the tools in their toolbox.

3. You want these maintainers to modify their tool in ways they don't 
like, in order to make their tool more appealing to more people.

4.  Theoretically, if they do this, then there will be more people to 
join in and make it a "better" tool - which doesn't mean a tool more in 
keeping with what the maintainers want, but with what other people want.

5.  This, in some way, is supposed to be a good thing.

I think I can confidently say that the maintainers are not going to be 
badgered into modifying this tool just to please the crowds.  I think 
that the idea of getting lots of maintainers isn't a priority for them.

The current maintainers have absolutely no incentive to try to make emacs 
appealing to the masses.  If they did that, sure, they'd probably get 
plenty of new maintainers, but these new guys would change their tool in 
ways they don't want.  They're OK with the way it is right now.  What's 
in it for them to change it?

A text editor isn't a popularity contest.  No one gets points for extra 
users.  It's a tool.  It does what it does.  If you want a tool that does 
that, it's the best one out there.  If you want a tool that does 
something else, it's not such a good choice.  So you either pick another 
tool, or you modify the one you have until it does what you want.

I don't know what you're talking about when you say the *scratch* buffer 
comes up first.  When I fire up emacs, the first buffer is *GNU Emacs*.  
On it are links to the Emacs Tutorial, Emacs Guided Tour, View Emacs 
Manual, and Customize Startup.  As far back as I can recall, emacs has 
always come up with this buffer first.  I'm using emacs 23.3.1, if that 
means anything.

Maybe emacs is a system whose time has come.  It has had a good run - far 
longer than most software.  Maybe it's just too old to fix.  There is 
such a thing as natural selection, and it works for programs as much as 
for living beings.  Dinosaurs tend to die out, eventually.  Maybe it's 
time...

Anyway, emacs is only one among dozens of text editors and word 
processors, ranging from pico and nano to kate to vi(m), gedit, notepad, 
Word, libreoffice, and whatever.   No one is forced to use emacs, and if 
it doesn't suit a person's needs, they shouldn't use it.  This is not a 
"problem."  This is like anything else.  If it works for you, fine.  If 
not, use something else.  Or, if you're ambitious, change it yourself, 
since it's open source.  Or *hire* someone to modify it for you, if you 
can't do it yourself.

Or hey, maybe offer to pay the maintainers to make the changes you think 
should be made.  But why complain about people who are doing this for 
free, who like it the way it is?

Or start a fork of emacs that will make the changes you feel are needed 
or desired.  That's altogether possible, and if there are enough people 
who care enough, you'll likely find some programmers who will contribute 
their time on the project.

Personally, I figure your best bet would be to start a fork.  Get a whole 
new set of maintainers, perhaps people more progressive than the 
maintainers for emacs itself.  Get some new blood in there, guys who will 
be trying to add timely new features and change whatever things could use 
updating.

I can't speak for the emacs maintainers, since I'm not one of them.  
However, I can almost guarantee you that no amount of complaining, 
badgering, whining, or criticism is going to motivate any of them to make 
the changes you feel are appropriate.

Maybe the bottom line is that free software is about freedom - and that 
can mean the freedom to cling to the past, if that's what the maintainers 
are really doing.

-- 
If this is timesharing, give me my share right now.

Re: Emacs: Problems of the Scratch Buffer

[Joost Kremers]

Chiron wrote:
> I think I can confidently say that the maintainers are not going to be 
> badgered into modifying this tool just to please the crowds.  I think 
> that the idea of getting lots of maintainers isn't a priority for them.

badgered, no. but that doesn't mean they would never consider making
changes to the default settings that could attract more users. in fact,
IIRC there have been such changes, and i also remember a poll set up by RMS
a while back asking opinions on making some part of CUA mode the default or
something similar. (don't remember the exact details...)

> The current maintainers have absolutely no incentive to try to make emacs 
> appealing to the masses.  If they did that, sure, they'd probably get 
> plenty of new maintainers,

new users, not new maintainers. potential new maintainers at best.

> but these new guys would change their tool in 
> ways they don't want.  They're OK with the way it is right now.  What's 
> in it for them to change it?

more users. which isn't necessarily a bad thing.

> A text editor isn't a popularity contest.  No one gets points for extra 
> users.

but you get extra users for extra users. that's worth something.

> Maybe emacs is a system whose time has come.  It has had a good run - far 
> longer than most software.  Maybe it's just too old to fix.

well, the scratch buffer would be an easy fix. in fact, *my* scratch buffer
uses text-mode (i use ielm for lisp interaction). it didn't take much to
change that.

>  There is 
> such a thing as natural selection, and it works for programs as much as 
> for living beings.  Dinosaurs tend to die out, eventually.  Maybe it's 
> time...

that's an interesting analogy. the dinosaurs died out because they couldn't
adapt fast enough to the new environment when it changed dramatically. the
point is, stuff, whether animals or software or anything else, dies out
when it doesn't adapt to new circumstances. the dinosaurs couldn't help it,
but emacs is developed by sentient beings that can see the change of times
and react, if necessary.

i don't have a strong opinion on what to do with the scratch buffer, i have
no idea if it is something that holds back people from adopting emacs as
their editor. but it is worth discussing, i think.


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 08:16:56 +0000, Joost Kremers wrote:

> but you get extra users for extra users. that's worth something.

I don't see that it's worth anything.  In what way do the maintainers of 
emacs benefit from having more users?

<snip

>> [quoted text muted]
> 
> that's an interesting analogy. the dinosaurs died out because they
> couldn't adapt fast enough to the new environment when it changed
> dramatically. the point is, stuff, whether animals or software or
> anything else, dies out when it doesn't adapt to new circumstances. the
> dinosaurs couldn't help it, but emacs is developed by sentient beings
> that can see the change of times and react, if necessary.
> 
Well, the point I was getting at is that things have a lifetime.  
Everything comes to an end, and that's not a bad thing.  It's just the 
way it is.  There are times to adapt, and there are times to scratch 
something and go on to something new.  Maybe emacs has had its day - and 
if it has, that's fine.

The sentient beings who work on emacs are not interested in making the 
suggested changes, for whatever reason they may have.  Perhaps they can't 
do it; perhaps they're stubborn; perhaps they're simply not interested in 
catering to the passing fads of programming that come and go every year.  
I have no idea.  But if they don't want to do it, they're not going to do 
it, and no amount of saying they "should" do it will help.

> i don't have a strong opinion on what to do with the scratch buffer, i
> have no idea if it is something that holds back people from adopting
> emacs as their editor. but it is worth discussing, i think.

I still don't understand the talk about the *scratch* buffer.  It comes 
up, but it's not the initial frame or buffer I get, and never has been.  
Is there some version of emacs where this happens?  I could see this 
being very confusing, if that were the case.  I still don't know enough 
lisp to do much about the *scratch* buffer.  If that's all I got when I 
started emacs, I'd probably go on to some other editor.  And no one would 
ever miss me...

-- 
I come from a small town whose population never changed.  Each time a 
woman got pregnant, someone left town.
		-- Michael Prichard

Re: Emacs: Problems of the Scratch Buffer

[Jambunathan K]

> I'd probably go on to some other editor.  
Please do.

> And no one would ever miss me...
True.
-- 

Re: Emacs: Problems of the Scratch Buffer

[Eli Zaretskii]

> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
> Date: Sat, 21 Apr 2012 12:43:45 GMT
> 
> In what way do the maintainers of emacs benefit from having more
> users?

If you ever maintained a package that others used, you must know that
satisfying your users is a very powerful incentive.  Frankly, I'm
surprised to see this question asked at all.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 18:17:32 +0530, Jambunathan K wrote:

>> I'd probably go on to some other editor.
> Please do.
> 
>> And no one would ever miss me...
> True.

Why the ad hominem argument?  If you have a reasoned objection to what I 
say, then present it.  If you simply don't like it, you accomplish 
nothing by insulting me.  You neither demonstrate the validity of your 
arguments, nor refute mine.

-- 
To understand the heart and mind of a person, look not at what
he has already achieved, but at what he aspires to do.

Re: Emacs: Problems of the Scratch Buffer

[Joe Corneli]

On Sat, Apr 21, 2012 at 2:42 PM, Chiron
<chiron613.no.spam.@no.spam.please.gmail.com> wrote:

> Why the ad hominem argument?

Last I heard this was a help list for Emacs, how about we all get back
to talking about the subject at hand?

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 14:49:50 +0000, Joe Corneli wrote:

> On Sat, Apr 21, 2012 at 2:42 PM, Chiron
> <chiron613.no.spam.@no.spam.please.gmail.com> wrote:
> 
>> Why the ad hominem argument?
> 
> Last I heard this was a help list for Emacs, how about we all get back
> to talking about the subject at hand?

Last I heard, we *were* talking about emacs.



-- 
Q:	What's the difference between a Mac and an Etch-a-Sketch?
A:	You don't have to shake the Mac to clear the screen.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 17:10:48 +0300, Eli Zaretskii wrote:

>> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
>> 21 Apr 2012 12:43:45 GMT
>> 
>> In what way do the maintainers of emacs benefit from having more users?
> 
> If you ever maintained a package that others used, you must know that
> satisfying your users is a very powerful incentive.  Frankly, I'm
> surprised to see this question asked at all.

Well, I'm just going by the behavior of the current maintainers.  They 
aren't making the changes that people seem to want - at least not the 
ones that might gather lots of users.  So apparently these guys aren't 
all that concerned about who's using their product, or at least not how 
many people are using it.  Otherwise, I'd expect that they'd do things to 
attract more users.

Satisfying users may be a powerful incentive, but it certainly is not the 
only one.  Apparently, it is not the one that motivates the current 
maintainers.

And this is why I suggested that those who want changes to emacs consider 
creating a fork.  If they don't do that, they're going to just have to 
take emacs as it is - or go to another editor.

-- 
A bore is a man who talks so much about himself that you can't talk about
yourself.

Re: Emacs: Problems of the Scratch Buffer

[Eli Zaretskii]

> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
> Date: Sat, 21 Apr 2012 14:46:07 GMT
> 
> On Sat, 21 Apr 2012 17:10:48 +0300, Eli Zaretskii wrote:
> 
> >> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
> >> 21 Apr 2012 12:43:45 GMT
> >> 
> >> In what way do the maintainers of emacs benefit from having more users?
> > 
> > If you ever maintained a package that others used, you must know that
> > satisfying your users is a very powerful incentive.  Frankly, I'm
> > surprised to see this question asked at all.
> 
> Well, I'm just going by the behavior of the current maintainers.

What behavior?  Facts, please.

> They aren't making the changes that people seem to want - at least
> not the ones that might gather lots of users.

Which changes?  Facts, please!

> Satisfying users may be a powerful incentive, but it certainly is not the 
> only one.  Apparently, it is not the one that motivates the current 
> maintainers.

Without the facts to back this up, I would not consider this
"conclusion" valid.

Re: Emacs: Problems of the Scratch Buffer

[Dan Espen]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> On Sat, 21 Apr 2012 17:10:48 +0300, Eli Zaretskii wrote:
>
>>> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
>>> 21 Apr 2012 12:43:45 GMT
>>> 
>>> In what way do the maintainers of emacs benefit from having more users?
>> 
>> If you ever maintained a package that others used, you must know that
>> satisfying your users is a very powerful incentive.  Frankly, I'm
>> surprised to see this question asked at all.
>
> Well, I'm just going by the behavior of the current maintainers.  They 
> aren't making the changes that people seem to want

You're making that up right?

Every one of the maintainers works on something someone wants.
With a little reflection on your part, you'll understand why
this is a truism.

Xah has a point, users and especially new users stumble on
the scratch buffer.  All Emacs asks is that it's users be smart
enough to read the little blurb there and ignore the buffer.

But so far, I don't see a lot of people coming up with good alternative
designs.  At least the mention of lisp in the blurb gives new users
an idea what language they need to use to modify things.

-- 
Dan Espen

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 12:15:20 -0400, Dan Espen wrote:

> Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:
> 
>> On Sat, 21 Apr 2012 17:10:48 +0300, Eli Zaretskii wrote:
>>
>>>> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
>>>> 21 Apr 2012 12:43:45 GMT
>>>> 
>>>> In what way do the maintainers of emacs benefit from having more
>>>> users?
>>> 
>>> If you ever maintained a package that others used, you must know that
>>> satisfying your users is a very powerful incentive.  Frankly, I'm
>>> surprised to see this question asked at all.
>>
>> Well, I'm just going by the behavior of the current maintainers.  They
>> aren't making the changes that people seem to want
> 
> You're making that up right?
> 
> Every one of the maintainers works on something someone wants. With a
> little reflection on your part, you'll understand why this is a truism.
> 
> Xah has a point, users and especially new users stumble on the scratch
> buffer.  All Emacs asks is that it's users be smart enough to read the
> little blurb there and ignore the buffer.
> 
> But so far, I don't see a lot of people coming up with good alternative
> designs.  At least the mention of lisp in the blurb gives new users an
> idea what language they need to use to modify things.

OK, I give up.  For some reason, I'm just not making myself clear, and 
there are too many people misunderstanding me for it to be their fault.  
One or two I could understand, but...  As Struther Martin might say, 
"what we got heyah is failyuh to communicate."

I can't think of how to properly express my opinion so that it is 
understood.  Since I'm not particularly attached to this opinion - which 
may very well be incorrect to begin with - I won't continue to belabor it.

-- 
Life is a gamble at terrible odds, if it was a bet you wouldn't take it.
		-- Tom Stoppard, "Rosencrantz and Guildenstern are Dead"

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 18:34:03 +0300, Eli Zaretskii wrote:

>> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
>> 21 Apr 2012 14:46:07 GMT
>> 
>> On Sat, 21 Apr 2012 17:10:48 +0300, Eli Zaretskii wrote:
>> 
>> >> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date:
>> >> Sat, 21 Apr 2012 12:43:45 GMT
>> >> 
>> >> In what way do the maintainers of emacs benefit from having more
>> >> users?
>> > 
>> > If you ever maintained a package that others used, you must know that
>> > satisfying your users is a very powerful incentive.  Frankly, I'm
>> > surprised to see this question asked at all.
>> 
>> Well, I'm just going by the behavior of the current maintainers.
> 
> What behavior?  Facts, please.
> 
The decision of the maintainers not to implement certain changes.  Kindly 
refer to earlier posts in this thread for more information.

>> They aren't making the changes that people seem to want - at least not
>> the ones that might gather lots of users.
> 
> Which changes?  Facts, please!
> 
Refer to earlier posts in this thread.  The specific change wasn't the 
issue.  The issue was whether someone who wants emacs to be different 
should expect someone else, who hasn't expressed such a desire, to make 
the changes.  And, by extension, whether the maintainers have the right 
to *not* make changes, even if making those changes might attract lots of 
new users.

>> Satisfying users may be a powerful incentive, but it certainly is not
>> the only one.  Apparently, it is not the one that motivates the current
>> maintainers.
> 
> Without the facts to back this up, I would not consider this
> "conclusion" valid.

It's not a "conclusion."  It's an opinion.  My opinion is based on what I 
see, which is a very limited subset of what occurs.  There is no 
particular reason for you to accept this opinion.

You're certainly entitled to your opinion.  I think you have mistaken my 
comments for those of someone else.  It may be helpful to review the 
thread to see what I was originally responding to.

In case I have been unclear, I am not criticizing the current maintainers 
of emacs.  I am supporting their right to make or not make changes in 
emacs, as they see fit.

I feel that for some reason people are not understanding what I am 
saying.  I'd like to blame it on the reader, but since it's more than 
one, I have to wonder whether I'm simply not getting my points across.  I 
don't know what more I can do about it, if the fault is with me.  And if 
by some chance the fault isn't with me, there really isn't anything for 
me to do.


-- 
To find a friend one must close one eye; to keep him -- two.
		-- Norman Douglas

Re: Emacs: Problems of the Scratch Buffer

[Eli Zaretskii]

> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
> Date: Sat, 21 Apr 2012 16:32:07 GMT
> 
> On Sat, 21 Apr 2012 18:34:03 +0300, Eli Zaretskii wrote:
> 
> >> Well, I'm just going by the behavior of the current maintainers.
> > 
> > What behavior?  Facts, please.
> > 
> The decision of the maintainers not to implement certain changes.  Kindly 
> refer to earlier posts in this thread for more information.

I asked on what behavior did _you_ decide that the maintainers behave
as you say they do.

> >> They aren't making the changes that people seem to want - at least not
> >> the ones that might gather lots of users.
> > 
> > Which changes?  Facts, please!
> > 
> Refer to earlier posts in this thread.

There's nothing there to suggest that.  What are _your_ facts, please?

> > Without the facts to back this up, I would not consider this
> > "conclusion" valid.
> 
> It's not a "conclusion."  It's an opinion.  My opinion is based on what I 
> see, which is a very limited subset of what occurs.  There is no 
> particular reason for you to accept this opinion.

If you tell what are your opinions based on, we could try figuring out
whether those opinions are justified or just misunderstandings.  But
as long as you evade any particulars, there's no sense in continuing
this discussion, and there indeed is no reason at all for me to accept
your opinion or even to consider it.

> I think you have mistaken my comments for those of someone else.

I did not.

> It may be helpful to review the thread to see what I was originally
> responding to.

I already did that.

> In case I have been unclear, I am not criticizing the current maintainers 
> of emacs.  I am supporting their right to make or not make changes in 
> emacs, as they see fit.

You are ascribing them motives and behavior that (1) don't exist, and
(2) are derogatory to their role and the way they perform their
duties.  If that's not "criticizing", then I don't know what would be.

> I feel that for some reason people are not understanding what I am 
> saying.

They do.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 19:52:18 +0300, Eli Zaretskii wrote:

>> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
<snip>
>> > 
>> The decision of the maintainers not to implement certain changes. 
>> Kindly refer to earlier posts in this thread for more information.
> 
> I asked on what behavior did _you_ decide that the maintainers behave as
> you say they do.
> 
And I told you where to find it.

>> >> They aren't making the changes that people seem to want - at least
>> >> not the ones that might gather lots of users.
>> > 
>> > Which changes?  Facts, please!
>> > 
>> Refer to earlier posts in this thread.
> 
> There's nothing there to suggest that.  What are _your_ facts, please?
> 
Yes, there is.  Or else, there isn't.  You'll have to go find it, if you 
want it.  I'm just about done with this thread.

I'm obviously not making myself clear, and too many people are 
misunderstanding me for it to be them.  Obviously I'm just not getting 
through, and it's something I'm doing wrong.

>> > Without the facts to back this up, I would not consider this
>> > "conclusion" valid.
>> 
>> It's not a "conclusion."  It's an opinion.  My opinion is based on what
>> I see, which is a very limited subset of what occurs.  There is no
>> particular reason for you to accept this opinion.
> 
> If you tell what are your opinions based on, we could try figuring out
> whether those opinions are justified or just misunderstandings.  But as
> long as you evade any particulars, there's no sense in continuing this
> discussion, and there indeed is no reason at all for me to accept your
> opinion or even to consider it.
> 
Well, since several people are not understanding me, there is a very good 
chance that it's misunderstandings - on my part.  I'd love to blame it on 
all of you, and theoretically it could be so; but the numbers say the 
problem is with me.

>> I think you have mistaken my comments for those of someone else.
> 
> I did not.
> 
Did too (just kidding).

>> It may be helpful to review the thread to see what I was originally
>> responding to.
> 
> I already did that.
> 
OK.  Then I have nothing more to add; I am obviously unfit for further 
discussion.

>> In case I have been unclear, I am not criticizing the current
>> maintainers of emacs.  I am supporting their right to make or not make
>> changes in emacs, as they see fit.
> 
> You are ascribing them motives and behavior that (1) don't exist, and
> (2) are derogatory to their role and the way they perform their duties. 
> If that's not "criticizing", then I don't know what would be.
> 
No, actually I'm not, which is why I say people are not understanding 
me.  I was arguing for the right of maintainers (anyone, actually) to 
make or not make changes.  But somehow this degenerated into a whole set 
of other issues that I never cared to discuss, claims that I never 
intended to make, and so on.  Obviously, I am not getting through.

>> I feel that for some reason people are not understanding what I am
>> saying.
> 
> They do.

No, they don't.  If they did, they wouldn't say the things they are 
saying.  Now, I am *NOT* claiming that anyone is being obtuse, or that 
anyone *should* understand me.  I *am* saying that I am apparently having 
some difficulty with communicating.  I am not stupid, and I am also 
normally good at communicating, but right now, for some reason, I am 
simply not getting through.  I must be doing something wrong.

Rather than continue to frustrate myself, I will withdraw from this 
conversation.

In case I'm still not clear:  I am blaming myself for my lack of clarity.

-- 
Catproof is an oxymoron, childproof nearly so.

Re: Emacs: Problems of the Scratch Buffer

[Dan Espen]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> In case I have been unclear, I am not criticizing the current maintainers 
> of emacs.  I am supporting their right to make or not make changes in 
> emacs, as they see fit.

Perhaps you are not fully aware of Xah's history.
He means well, but he sometimes presents his ideas in a rather
confrontational manner.  You may be getting a bit of a reaction
because of this.

-- 
Dan Espen

Re: Emacs: Problems of the Scratch Buffer

[Bastien]

Hi Chiron,

if you've followed last years development of Org (http://orgmode.org)
you will realize that the wide Emacs community (including Org's one) is
quite welcoming to new users.

I guess the miscommunication comes from the fact that maintainers tend
to think against patches and more concrete proposals.

Right now, I cannot think of something better than the scratch buffer,
but maybe there *is* something.

Jambunathan made some concrete proposals in a recent message to Emacs
bug tracking system -- let's see how it evolve and contribute from
there?

-- 
 Bastien

Re: Emacs: Problems of the Scratch Buffer

[Joost Kremers]

Chiron wrote:
> On Sat, 21 Apr 2012 08:16:56 +0000, Joost Kremers wrote:
>
>> but you get extra users for extra users. that's worth something.
>
> I don't see that it's worth anything.  In what way do the maintainers of 
> emacs benefit from having more users?

well, for one, it's gratifying to have people who use the software you
write and who (apparently) appreciate your work. it's one of the reasons i
suspect many open source/free software developers are in it for.

but more users usually also means more visibility, more bug reports and/or
contributions, more potential developers, better chances of the project
remaining alive once you are no longer able to maintain it.

> Well, the point I was getting at is that things have a lifetime.  
> Everything comes to an end, and that's not a bad thing.

sometimes it is. sure, in the grand scheme of things, what does it all
matter, but if emacs were to die out, i'd be thoroughly unhappy. that's
important, though possibly mainly to myself. ;-)

but kidding aside, i think i did get your point. i was just saying that
something as adaptable as emacs doesn't need to meet its end in such a way
as you describe.

> The sentient beings who work on emacs are not interested in making the 
> suggested changes, for whatever reason they may have.

yes, you said that before, but i'm pretty sure that that's simply not true.

note that if you conclude that from some of the comments in this (and
possibly other threads), you may be basing your conclusions on false
premisses. the emacs devs certainly are interested in hearing comments from
users and suggestions how to improve upon the software. that, however,
doesn't mean that they will implement *every* suggestion.

>  Perhaps they can't 
> do it; perhaps they're stubborn; perhaps they're simply not interested in 
> catering to the passing fads of programming that come and go every year.  
> I have no idea.  But if they don't want to do it, they're not going to do 
> it, and no amount of saying they "should" do it will help.

of course, but i don't think that's at issue here. (at least, that was *my*
impression of this thread. ;-)

>> i don't have a strong opinion on what to do with the scratch buffer, i
>> have no idea if it is something that holds back people from adopting
>> emacs as their editor. but it is worth discussing, i think.
>
> I still don't understand the talk about the *scratch* buffer.  It comes 
> up, but it's not the initial frame or buffer I get, and never has been.  

the scratch buffer was what started the whole thread. it comes up as the
first buffer a user can actually enter text into, but it doesn't behave in
the same way that the first usable text entry area in most other editors or
word processors behave, i.e., programs with which potential new emacs users
may be more familiar with. the proposal was to make the scratch buffer
behave more in that way.

> Is there some version of emacs where this happens?

IIRC every version since i've been using emacs, which is emacs 21 or 22, i
think.

>  I could see this 
> being very confusing, if that were the case.  I still don't know enough 
> lisp to do much about the *scratch* buffer.  If that's all I got when I 
> started emacs, I'd probably go on to some other editor.  And no one would 
> ever miss me...

you can't miss what you never had. or more precisely, you can't miss what
you cannot imagine having. :-)


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Emacs: Problems of the Scratch Buffer

[rusi]

I'll try and restate what Xah is saying in less Xah-ish language.

Emacs comes from a time when anyone who used a computer knew (about)
programming.
Today everyone uses a computer; so the programmers are the freaks.

The scratch buffer is meaningful/useful/beautiful for those who can
understand what it signifies that they can (re)program their editor.

It is a stupid and meaningless irritation to those not so endowed.

Re: Emacs: Problems of the Scratch Buffer

[Richard Riley]

rusi <rustompmody@gmail.com> writes:

> I'll try and restate what Xah is saying in less Xah-ish language.
>
> Emacs comes from a time when anyone who used a computer knew (about)
> programming.
> Today everyone uses a computer; so the programmers are the freaks.
>
> The scratch buffer is meaningful/useful/beautiful for those who can
> understand what it signifies that they can (re)program their editor.
>
> It is a stupid and meaningless irritation to those not so endowed.
>

Even speaking as a programmer I have to agree. I am surprised anyone
disagrees. Anyone clued in enough to emacs to know what *Scratch* is for
can create their own easily enough from their .emacs. 

Re: Emacs: Problems of the Scratch Buffer

[ken]

On 04/24/2012 07:35 AM Richard Riley wrote:
> rusi<rustompmody@gmail.com>  writes:
>
>> I'll try and restate what Xah is saying in less Xah-ish language.
>>
>> Emacs comes from a time when anyone who used a computer knew (about)
>> programming.
>> Today everyone uses a computer; so the programmers are the freaks.
>>
>> The scratch buffer is meaningful/useful/beautiful for those who can
>> understand what it signifies that they can (re)program their editor.
>>
>> It is a stupid and meaningless irritation to those not so endowed.
>>
>
> Even speaking as a programmer I have to agree. I am surprised anyone
> disagrees. Anyone clued in enough to emacs to know what *Scratch* is for
> can create their own easily enough from their .emacs.

I still recall from decades ago my first experiences with emacs.  Yes, 
the *scratch* buffer was in those first few months a bit of a mystery, 
but certainly in no way "a stupid and meaningless irritation".

What's much more of an irritation is this continual urge to dumb down 
software or make it more like an MS product-- oftentimes one and the 
same goal.  This more often than not leads to the elimination of 
features and functionality which seasoned users (and, No, not in every 
case programmers) are accustomed to.  If a person is irritated by the 
extra features and functionality, she has plenty of options to deal with 
them: learn how to turn them off, learn how to use them, learn how to 
deal with the fact that she doesn't understand everything in the 
software within the first week of using it, or switch to some other 
software which is less challenging and so less "irritating".

One option that newbies don't get-- and I'm speaking especially to those 
with an inflated sense of their own wisdom and opinions-- is to decide 
for everyone what features and functionality the software should and 
shouldn't have... and even less to then expect expect everyone else to 
make the efforts to adjust to their naive views and ridiculously low 
irritation thresholds.

Re: Emacs: Problems of the Scratch Buffer

[Thien-Thi Nguyen]

() ken <gebser@mousecar.com>
() Tue, 24 Apr 2012 09:44:15 -0400

   naive views and ridiculously low irritation thresholds

such are those that spurn GPL for BSD:
soft-shade rose (a personal hell) for me not thee.
"i recognize as brothers
none from other mothers!
my heart knows (and maw does yell) ignorant sincerity."

"everyone uses computers", true, but emacs chooses its friends.
you may court it, keys chorded, for the response that it sends.
a shoulder-length ear?
industrial strength leer?
what is *scratch* best for, to define beginnings or ends?

Re: Emacs: Problems of the Scratch Buffer

[ken]

On 04/25/2012 06:39 AM Thien-Thi Nguyen wrote:
> () ken<gebser@mousecar.com>
> () Tue, 24 Apr 2012 09:44:15 -0400
>
>     naive views and ridiculously low irritation thresholds
>
> such are those that spurn GPL for BSD:
> soft-shade rose (a personal hell) for me not thee.
> "i recognize as brothers
> none from other mothers!
> my heart knows (and maw does yell) ignorant sincerity."
>
> "everyone uses computers", true, but emacs chooses its friends.
> you may court it, keys chorded, for the response that it sends.
> a shoulder-length ear?
> industrial strength leer?
> what is *scratch* best for, to define beginnings or ends?

Thanks, Nguyen,

Though the stalk of wheat
which bears the most seed
the farthest bends,
in the end,
it must loose its fruit
so that others may take root.

Re: Emacs: Problems of the Scratch Buffer

[Jambunathan K]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () ken <gebser@mousecar.com>
> () Tue, 24 Apr 2012 09:44:15 -0400
>
>    naive views and ridiculously low irritation thresholds
>
> such are those that spurn GPL for BSD:
> soft-shade rose (a personal hell) for me not thee.
> "i recognize as brothers
> none from other mothers!
> my heart knows (and maw does yell) ignorant sincerity."
>
> "everyone uses computers", true, but emacs chooses its friends.
> you may court it, keys chorded, for the response that it sends.
> a shoulder-length ear?
> industrial strength leer?
> what is *scratch* best for, to define beginnings or ends?

Of what use is Emacs with no *scratch*,  
Or a Poet with no muse to catch?

Anything that looks nice,
Was built atleast twice.

I build things with hands I own,
I care much for what is shown *and* thrown.

Don't need *scratch*, Hey!
Take this C-x k.

Need more *scratch*, so it be,
What you need is C-x b.

To each his own,
But, I want my lawn mown.

I care for all my tools,
(One as equal as the other)
Off you go, you fools!
-- 

Re: Emacs: Problems of the Scratch Buffer

[rusi]

Hello folks! I must make bold
To say that emacs is very very old

We laugh and chuckle at Xah's profanities
And shed a silent tear at their hidden verities

So thanks folks for your sweet poemings
Me? Im quite out of rhyme and meterings

Re: Emacs: Problems of the Scratch Buffer

[Bastien]

 
   You don't wanna crash
   The whole mailing list

   Just because Emacs
   Is not as you wish...

   So don't itch The Scratch
   But do scratch an itch!


-- 
 Bastien

Re: Emacs: Problems of the Scratch Buffer

[Xah Lee]

On Apr 25, 3:39 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote:
> () ken <geb...@mousecar.com>
> () Tue, 24 Apr 2012 09:44:15 -0400
>
>    naive views and ridiculously low irritation thresholds
>
> such are those that spurn GPL for BSD:
> soft-shade rose (a personal hell) for me not thee.
> "i recognize as brothers
> none from other mothers!
> my heart knows (and maw does yell) ignorant sincerity."
>
> "everyone uses computers", true, but emacs chooses its friends.
> you may court it, keys chorded, for the response that it sends.
> a shoulder-length ear?
> industrial strength leer?
> what is *scratch* best for, to define beginnings or ends?

justification of Emacs's *scratch*:

  emacs's *scratch*
  amounts to a bitch
  but we cannot ditch
  the banner of our church

 Xah

Re: Emacs: Problems of the Scratch Buffer

[Dan Espen]

rusi <rustompmody@gmail.com> writes:

> I'll try and restate what Xah is saying in less Xah-ish language.
>
> Emacs comes from a time when anyone who used a computer knew (about)
> programming.
> Today everyone uses a computer; so the programmers are the freaks.
>
> The scratch buffer is meaningful/useful/beautiful for those who can
> understand what it signifies that they can (re)program their editor.
>
> It is a stupid and meaningless irritation to those not so endowed.

That's less Xah-ish?

(Sorry Xah.)

Why did you find it necessary to use the words freaks and stupid?

When suggesting that someone else do work for you, it's best to not
start out with name calling.

What I think most of us are waiting for is constructive suggestions
about what to display when Emacs is started without a file name.

Isn't the "modern" way to do this is start with a buffer in fundamental
mode named "untitled-n" and if anything is typed in the buffer, save it
as "untitled-n"?  So a typical user would have a home directory
filled with "untitled-n" files?

I _don't_ think I would like that better than the current scratch buffer.

-- 
Dan Espen

Re: Emacs: Problems of the Scratch Buffer

[PJ Weisberg]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On Tuesday, April 24, 2012, Dan Espen <despen@verizon.net> wrote:
> Isn't the "modern" way to do this is start with a buffer in fundamental
> mode named "untitled-n" and if anything is typed in the buffer, save it
> as "untitled-n"?  So a typical user would have a home directory
> filled with "untitled-n" files?

Actually, the "modern" way is to prompt for a filename when the user tries
to save the untitled buffer.

FWIW, I have a launcher script for emacs that I wrote for myself, and one
of the things it does is insert the file argument "new-file-$RANDOM.txt" if
there is none.

-- 
-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

[-- Attachment #2: Type: text/html, Size: 881 bytes --]

Re: Emacs: Problems of the Scratch Buffer

[Thien-Thi Nguyen]

() Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
() Sat, 21 Apr 2012 03:53:33 GMT

   The current maintainers have absolutely no incentive to try to
   make emacs appealing to the masses.

Maybe, maybe not.

   If they did that, sure, they'd probably get plenty of new
   maintainers, but these new guys would change their tool in ways
   they don't want.  They're OK with the way it is right now.
   What's in it for them to change it?

Well, a superior change accomodates both old and new.  Not every
programmer realizes such change, but there's no point losing hope.
Whether or not that programmer is a maintainer is beside the point.

Re: Emacs: Problems of the Scratch Buffer

[Joe Corneli]

On Sat, Apr 21, 2012 at 8:36 AM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> Well, a superior change accomodates both old and new.  Not every
> programmer realizes such change, but there's no point losing hope.
> Whether or not that programmer is a maintainer is beside the point.

It seems to me that if my circa 2004 code (first reply) was appealing
enough to enough people, it might have been included in Emacs (I did
sign papers to become a contributor).  But that doesn't seem to have
been the case, and I don't even use the code myself anymore (though
maybe I'll start again after this discussion to see if it improves my
life).

Anyway, it seems likely that if someone can identify the scratch
buffer as a problem, they can also figure out how to solve the
problem.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 10:36:27 +0200, Thien-Thi Nguyen wrote:

> () Chiron <chiron613.no.spam.@no.spam.please.gmail.com> () Sat, 21 Apr
> 2012 03:53:33 GMT
> 
>    The current maintainers have absolutely no incentive to try to make
>    emacs appealing to the masses.
> 
> Maybe, maybe not.

If they had an incentive to make emacs appealing to the masses, they'd do 
it.  Since they aren't doing it, I think it's clear that they don't have 
the incentive.
> 
>    If they did that, sure, they'd probably get plenty of new
>    maintainers, but these new guys would change their tool in ways they
>    don't want.  They're OK with the way it is right now. What's in it
>    for them to change it?
> 
> Well, a superior change accomodates both old and new.  Not every
> programmer realizes such change, but there's no point losing hope.
> Whether or not that programmer is a maintainer is beside the point.

Perhaps.  I was simply speaking of the motivation of the current 
maintainers to make changes to emacs.  Unless the current maintainers are 
confused, they *already* have emacs pretty much the way they want it.

What the complainer was suggesting was that new people - maintainers, 
programmers, whoever - would *change* emacs, which would make emacs less 
the way the current maintainers want it, and more the way others would 
want it.

I guess what I'm seeing, is Group A is unhappy with emacs and would like 
to see some changes made to it that might be beneficial.  They complain 
that the people who maintain emacs - Group B - don't want to make the 
changes.  But Group B is happy with things the way they are - so why 
should they go to the trouble to make the changes that Group A wants?

A.  We think you should change emacs to be the way we want it.

B.  Well, we like it the way it is.

A.  No, you're too old-fashioned or hidebound; you need to get with the 
program.  You need to make emacs a tool for modern programming practices.

B.  Why?  It works for us.

A.  But it doesn't work for us!

B.  Um... 

-- 
... bleakness ... desolation ... plastic forks ...

Re: Emacs: Problems of the Scratch Buffer

[Pascal J. Bourguignon]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> A.  We think you should change emacs to be the way we want it.
>
> B.  Well, we like it the way it is.
>
> A.  No, you're too old-fashioned or hidebound; you need to get with the 
> program.  You need to make emacs a tool for modern programming practices.
>
> B.  Why?  It works for us.
>
> A.  But it doesn't work for us!
>
> B.  Um... 

Followed by:

B. Um… but making it work as you want takes less time than this
   discussion, as shown by pjb on cll.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 15:31:44 +0200, Pascal J. Bourguignon wrote:

<snip>

> B. Um… but making it work as you want takes less time than this
>    discussion, as shown by pjb on cll.

My point exactly.  As I said, emacs is only the most customizable editor 
on the planet.  So customize it already, and quit complaining about how 
it doesn't do what you want it to.

-- 
"The Avis WIZARD decides if you get to drive a car. Your head won't touch 
the pillow of a Sheraton unless their computer says it's okay."
		-- Arthur Miller

Re: Emacs: Problems of the Scratch Buffer

[Eli Zaretskii]

> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
> Date: Sat, 21 Apr 2012 12:35:28 GMT
> 
> On Sat, 21 Apr 2012 10:36:27 +0200, Thien-Thi Nguyen wrote:
> 
> > () Chiron <chiron613.no.spam.@no.spam.please.gmail.com> () Sat, 21 Apr
> > 2012 03:53:33 GMT
> > 
> >    The current maintainers have absolutely no incentive to try to make
> >    emacs appealing to the masses.
> > 
> > Maybe, maybe not.
> 
> If they had an incentive to make emacs appealing to the masses, they'd do 
> it.  Since they aren't doing it, I think it's clear that they don't have 
> the incentive.

They have and they do, just watch the changes made in the last few
major releases.  It could be that the pace is not to your liking, or
that your most beloved feature didn't (yet) get in, but that doesn't
yet justify the extreme conclusions that you seem to have reached, and
now are spreading all over.

> Unless the current maintainers are confused, they *already* have
> emacs pretty much the way they want it.

No good maintainer ever stops evolving in his/her habits nor becomes
deaf to wishes of the users.  I suggest that you read the emacs-devel
list for a while, and I'm sure you will see how incorrect the above
judgment is.

> What the complainer was suggesting was that new people - maintainers, 
> programmers, whoever - would *change* emacs, which would make emacs less 
> the way the current maintainers want it, and more the way others would 
> want it.

Maintaining a package is never about a battle of wills of the kind you
seem to envision.  So your mental model of how this works is simply
wrong.  Again, you should read emacs-devel to see the actual state of
affairs.

> A.  We think you should change emacs to be the way we want it.
> 
> B.  Well, we like it the way it is.
> 
> A.  No, you're too old-fashioned or hidebound; you need to get with the 
> program.  You need to make emacs a tool for modern programming practices.
> 
> B.  Why?  It works for us.
> 
> A.  But it doesn't work for us!
> 
> B.  Um... 

You won't find this on emacs-devel.  So this line of reasoning will
never bring any change.

Several people in this thread explained why (a) *scratch* is useful
for them and (b) does not necessarily get in your way, unless you
insist (e.g., by using the -Q switch).  If someone has constructive
proposals for how to make that buffer even less prominent, please post
your suggestions to emacs-devel, or file "wishlist" bug reports to the
Emacs bug-tracker.

Arguing that *scratch* should be removed entirely is a non-starter,
since a non-negligible portion of users find it useful, but I
sincerely don't see why reasonable people would want that, if we can
find less extreme ways of getting it out of the way of those who don't
need it.

Re: Emacs: Problems of the Scratch Buffer

[Pascal J. Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:

> Arguing that *scratch* should be removed entirely is a non-starter,
> since a non-negligible portion of users find it useful, but I
> sincerely don't see why reasonable people would want that, if we can
> find less extreme ways of getting it out of the way of those who don't
> need it.

Actually, it's the first time I ever heard something against the
*scratch* buffer.  But on the contrary, I've myself implemented a M-x
scratch command and I've seen several other people asking or
implementing it themselve, to recreate a *scratch* buffer when it has
been accidentally killed.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: Emacs: Problems of the Scratch Buffer

[Jambunathan K]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Arguing that *scratch* should be removed entirely is a non-starter,
>> since a non-negligible portion of users find it useful, but I
>> sincerely don't see why reasonable people would want that, if we can
>> find less extreme ways of getting it out of the way of those who don't
>> need it.
>
> Actually, it's the first time I ever heard something against the
> *scratch* buffer.  But on the contrary, I've myself implemented a M-x
> scratch command and I've seen several other people asking or
> implementing it themselve, to recreate a *scratch* buffer when it has
> been accidentally killed.

M-x emacs-lock-mode RET

Increasingly, I am feeling the need for multiple scratch buffers.  By
default, my scratch buffer is in emacs-lisp mode.  Some times, I switch
that scratch buffer to Org-mode when I create lists, tables or just
copy-paste some plain text from interwebs purely for reasons of
wrapping/filling.

1. Allow multiple scratch buffers one for each mode the user is
   interested in.  The defcustom can have a solitary text-mode entry.  A
   user wanting no scratch buffer at all can null-ify the mode list.  A
   user like me can add emacs-lisp-mode and org-mode to it.

2. Just in case I need a one-off scratch buffer, I need a quick way to
   create it without having to think of (or type) out the full name Or
   confirm my intentions (This latter part is *very* annoying).  

      C-u C-x b can offer to create *scratch-%s* (or %s-scratch) in
      %s-mode.

3. I think it is not the scratch buffer that is idiosyncratic but the
   /name/.  Instead of using scratch one could call it say a notes
   buffer or a temp buffer.

That said I am happy with the way things are.  I know how to kill my
scratch buffer and I also know how to create multiple ones if needed.  I
also know how to type 'y' if prompted :-).
-- 

Re: Emacs: Problems of the Scratch Buffer

[Jambunathan K]

If any one feel strongly about scratch buffers please add your proposals
to:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11298

I have added my thoughts to that bug.

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 17:07:46 +0300, Eli Zaretskii wrote:

<snip>

I believe you have misunderstood me.  I am not arguing in favor of any 
changes.  You may be thinking I'm the one who's complaining about changes 
not being made.  That wasn't me.

I am arguing for the right of the current maintainers to make or to not 
make whatever changes they feel are appropriate; and I am saying that if 
the maintainers don't choose to make certain changes, that does not 
necessarily make them fossils, behind the times, stupid, or whatever.  It 
may simply be that they don't think those changes are important.

Oh, and finally, I'm saying that if Group A wants changes, and Group B 
doesn't, then I guess Group A is going to have to make the changes.

-- 
I can't understand it.  I can't even understand the people who can
understand it.
		-- Queen Juliana of the Netherlands.

Re: Emacs: Problems of the Scratch Buffer

[Eli Zaretskii]

> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
> Date: Sat, 21 Apr 2012 14:59:34 GMT
> 
> I am arguing for the right of the current maintainers to make or to not 
> make whatever changes they feel are appropriate; and I am saying that if 
> the maintainers don't choose to make certain changes, that does not 
> necessarily make them fossils, behind the times, stupid, or whatever.  It 
> may simply be that they don't think those changes are important.

A purely theoretical argument that is not relevant to the reality (in
which the maintainers _do_ make changes requested by users, albeit not
automatically and not without discussing them first).

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 18:35:58 +0300, Eli Zaretskii wrote:

>> From: Chiron <chiron613.no.spam.@no.spam.please.gmail.com> Date: Sat,
>> 21 Apr 2012 14:59:34 GMT
>> 
>> I am arguing for the right of the current maintainers to make or to not
>> make whatever changes they feel are appropriate; and I am saying that
>> if the maintainers don't choose to make certain changes, that does not
>> necessarily make them fossils, behind the times, stupid, or whatever. 
>> It may simply be that they don't think those changes are important.
> 
> A purely theoretical argument that is not relevant to the reality (in
> which the maintainers _do_ make changes requested by users, albeit not
> automatically and not without discussing them first).

Eli, I was responding to someone who was complaining that these 
maintainers weren't making certain changes that the person felt would be 
good.  Whoever this person was (he's in this thread, but I'm not going to 
go digging for it) said something mildly derogatory about the 
maintainers, as though their failure to make these changes was in some 
way a defect.  I argued that the maintainers had the right to not make 
the changes, and that doesn't make them deficient in any way.

It is only a "purely theoretical" argument if taken out of context.

Oh, yes.  Someone also was criticizing me for saying, in effect, "If you 
don't like emacs, don't use emacs."  His solution was to try to get 
someone to change emacs to make it more attractive to new users, because 
if you had lots of new users this would lead to an improved product.

By that logic, Microsoft Windows and Microsoft Word would be the best 
software out there.  I'm not sure everyone would agree with such a claim, 
though.

-- 
Duty, n:
	What one expects from others.
		-- Oscar Wilde

Re: Emacs: Problems of the Scratch Buffer

[Thien-Thi Nguyen]

() Chiron <chiron613.no.spam.@no.spam.please.gmail.com>
() Sat, 21 Apr 2012 12:35:28 GMT

   If they had an incentive to make emacs appealing to the masses,
   they'd do it.  Since they aren't doing it, I think it's clear
   that they don't have the incentive.

I must admit, from where i sit, nothing is so clear.

   I was simply speaking of the motivation of the current
   maintainers to make changes to emacs.  Unless the current
   maintainers are confused, they *already* have emacs pretty much
   the way they want it.

Probably confusion and acceptance are independent.  If not, the
acceptably confusing trick is to determine which causes which.  :-D

   But Group B is happy with things the way they are - so why
   should they go to the trouble to make the changes that Group A
   wants?

Long-term, the biggest trouble arises from overly-rigid boundaries
between groups.  What is a liquid border but a f{r}ont of change?

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 19:07:25 +0200, Thien-Thi Nguyen wrote:

> () Chiron <chiron613.no.spam.@no.spam.please.gmail.com> () Sat, 21 Apr
> 2012 12:35:28 GMT
> 
>    If they had an incentive to make emacs appealing to the masses,
>    they'd do it.  Since they aren't doing it, I think it's clear that
>    they don't have the incentive.
> 
> I must admit, from where i sit, nothing is so clear.
> 
Yes, you are about the fourth or fifth person who isn't understanding me 
- therefore, I must be doing something wrong, failing to be clear in some 
vital way that I just can't see.  So, without meaning to be rude, I feel 
it is time for me to withdraw from this conversation.  I don't seem to be 
able to say things clearly enough.


>    But Group B is happy with things the way they are - so why should
>    they go to the trouble to make the changes that Group A wants?
> 
> Long-term, the biggest trouble arises from overly-rigid boundaries
> between groups.  What is a liquid border but a f{r}ont of change?

Perhaps.  But I don't dare respond, because I am likely to just get into 
more trouble with communicating.  Maybe I need to get some sleep or 
something...


-- 
All bad precedents began as justifiable measures.
		-- Gaius Julius Caesar, quoted in "The Conspiracy of
		   Catiline", by Sallust

Re: Emacs: Problems of the Scratch Buffer

[Juanma Barranquero]

On Sat, Apr 21, 2012 at 19:14, Chiron
<chiron613.no.spam.@no.spam.please.gmail.com> wrote:

> So, without meaning to be rude, I feel
> it is time for me to withdraw from this conversation.  I don't seem to be
> able to say things clearly enough.

Let's try to understand, leaving aside any hard feeling.

You said:

> I think I can confidently say that the maintainers are not going to be
> badgered into modifying this tool just to please the crowds.  I think
> that the idea of getting lots of maintainers isn't a priority for them.

Don't know why you said "confidently", but if you read emacs-devel,
you'll see that the issue of changing settings or adding stuff to make
it easier for newbies has been discussed many times. And the answer
usually is not a knee-jerk "no", but of course it is not an
unconditional "yes" either. Depends on the issue, how far reaching it
is and how does it impact Emacs in general. Defaults for shift
selection, for example, have been changed in the past to cater to
current sensibilities. As for getting more maintainers, it's not a
"priority", but neither is it irrelevant. The (relative) shortage of
maintainers has often been quoted as one of the causes of the Emacs
project not branching for a release until it is near to releasing (to
avoid diverting efforts between "boring pre-release bug-fixing" and
"fun new features in the trunk").

> The current maintainers have absolutely no incentive to try to make emacs
> appealing to the masses.  If they did that, sure, they'd probably get
> plenty of new maintainers, but these new guys would change their tool in
> ways they don't want.  They're OK with the way it is right now.  What's
> in it for them to change it?

There are 150 people with commit rights to Emacs, and perhaps two
dozen who work on it with some regularity. It's hard to attribute
common desires and incentives to all of them. Some people are really
interested in making it appealing to the masses, some are uninterested
(though no one is hostile, I think). But I've never seen any
resistance to getting new developers, nor fear that they would change
Emacs. There have been plenty of changes in the last few years, some
trivial, others pretty disruptive (multi-tty and Unicode support were
hard). AFAICS, the Emacs project does not resist change; if anything,
it shows resistance against disruptive changes without a good reason.
But everything is open to discussion (too many times, often ;-)

Just my .02€

    Juanma

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 19:47:05 +0200, Juanma Barranquero wrote:

<snip>

No, definitely no hard feelings.  I just need to step back and sit this 
one out.  Apparently I'm just not making sense.  Time for me to shut up 
(so I'm not going to respond to further comments).  I'll try again 
another day, when my head is clearer.

-- 
I'm not a level-headed person...        -- Bruce Perens

Re: Emacs: Problems of the Scratch Buffer

[Jason Earl]

On Sat, Apr 21 2012, Chiron wrote:

> On Sat, 21 Apr 2012 10:36:27 +0200, Thien-Thi Nguyen wrote:
>
>> () Chiron <chiron613.no.spam.@no.spam.please.gmail.com> () Sat, 21 Apr
>> 2012 03:53:33 GMT
>> 
>>    The current maintainers have absolutely no incentive to try to make
>>    emacs appealing to the masses.
>> 
>> Maybe, maybe not.
>
> If they had an incentive to make emacs appealing to the masses, they'd
> do it.  Since they aren't doing it, I think it's clear that they don't
> have the incentive.

Xah writes some interesting stuff, but in this particular case he is a
bit behind the times.  For one thing, in the upcoming new version of
Emacs the *scratch* buffer is not the first buffer that you get.
Instead you get an informational buffer with links to things like the
documentation, the tutorial, etc.

In short, Xah's saner criticisms of Emacs have already been addressed.
My guess is that Xah even knows that, as he has his own fork of Emacs
and probably pays at least some attention to emacs-devel where the
different start up buffer options were debated at some length.

The cynical part of me thinks that perhaps Xah was just re-circulating
that old essay while it still had some merit.

>>    If they did that, sure, they'd probably get plenty of new
>>    maintainers, but these new guys would change their tool in ways
>>    they don't want.  They're OK with the way it is right now. What's
>>    in it for them to change it?
>> 
>> Well, a superior change accomodates both old and new.  Not every
>> programmer realizes such change, but there's no point losing hope.
>> Whether or not that programmer is a maintainer is beside the point.
>
> Perhaps.  I was simply speaking of the motivation of the current
> maintainers to make changes to emacs.  Unless the current maintainers
> are confused, they *already* have emacs pretty much the way they want
> it.

That's ridiculous.  Emacs can always do more.

> What the complainer was suggesting was that new people - maintainers,
> programmers, whoever - would *change* emacs, which would make emacs
> less the way the current maintainers want it, and more the way others
> would want it.

There certainly is some of that.  There are certainly some compromises
that are made so that Emacs can still work as a terminal application.

> I guess what I'm seeing, is Group A is unhappy with emacs and would
> like to see some changes made to it that might be beneficial.  They
> complain that the people who maintain emacs - Group B - don't want to
> make the changes.  But Group B is happy with things the way they are -
> so why should they go to the trouble to make the changes that Group A
> wants?

I know of at least 6 Emacs forks from the GNU Emacs code that are
actively maintained today.  Coincidentally Xah's ErgoEmacs is one of
them.  If you really think that he makes a point with his complaints you
should probably check his fork out.  That doesn't include other text
editors (like zile, for example) that clearly draw inspiration from
Emacs.  There is plenty of room for hacking on those projects if you
think that the GNU Emacs developers are not filling your needs.

Personally, I am quite excited about the new Emacs, and the shorter
development cycles means that new Emacs tools get into the hands of
people like me much faster.

Jason

Re: Emacs: Problems of the Scratch Buffer

[Stefan Monnier]

> OK, so here's the situation, as I understand it:
> 1.  The maintainers of emacs are happy with the way it is right now.
> 2.  The maintainers probably *use* emacs for their work - so it's one of 
> the tools in their toolbox.
> 3. You want these maintainers to modify their tool in ways they don't 
> like, in order to make their tool more appealing to more people.

I doubt that most Emacs maintainers have a strong opinion on how the
*scratch* buffer should work.


        Stefan

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 10:39:33 -0400, Stefan Monnier wrote:

>> OK, so here's the situation, as I understand it: 1.  The maintainers of
>> emacs are happy with the way it is right now. 2.  The maintainers
>> probably *use* emacs for their work - so it's one of the tools in their
>> toolbox.
>> 3. You want these maintainers to modify their tool in ways they don't
>> like, in order to make their tool more appealing to more people.
> 
> I doubt that most Emacs maintainers have a strong opinion on how the
> *scratch* buffer should work.
> 
> 
So they wouldn't have a strong opinion that they should change how the 
*scratch* buffer works.


-- 
Help me, I'm a prisoner in a Fortune cookie file!

Re: Emacs: Problems of the Scratch Buffer

[Martin]

just a little script I have written for myself:

- - - -

(setq create-selection-buffer-counter 0)
(defun create-selection-buffer()
    "Creates a buffer that contains primary X selection."
    (interactive)
    (setq create-selection-buffer-counter (+ create-selection-buffer-counter 1))
    (setq sel-buf-name
        (concat "selection-buffer-" (int-to-string create-selection-buffer-counter)))
    (set-buffer (get-buffer-create sel-buf-name))
    (yank)
    (set-window-buffer nil (get-buffer-create sel-buf-name)))

- - - -

Simple function that automatically creates a new named buffer with whatever
you have in clipboard

m.

On Wed, Apr 18, 2012 at 05:00:20AM -0700, Xah Lee wrote:
> for entertainment purpose only.
>
> 〈Emacs: Problems of the Scratch Buffer〉
> http://xahlee.org/emacs/modernization_scratch_buffer.html
>
> ---------------------------------------------
>
> Emacs: Problems of the Scratch Buffer
>  By Xah Lee, 2008-09, …, 2012-04-18
>
> Here are reasons that the scratch buffer is not useful to most people:
>
>  1.It is not useful for 99% of emacs users. If people wanted a scratch
> pad, they can open a new document and not save it. This way is
> familiar to all software users.
>  2.The “*scratch*” “buffer” is designed for emacs lisp programers. (it
> defaults to lisp-interaction-mode.) 99% of emacs users are not lisp
> coders.
>  3.The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY. New users are
> not familiar what it is. It is the first thing presented to users, and
> it persists.
>
> Scratch Buffer is Inconvenient
>
> Here are reasons that a alternative to “*scratch*” “buffer” is more
> useful:
>
>  1.There is no easy, intuitive way to create multiple scratch buffers.
> (it is done by calling switch-to-buffer 【Ctrl+x b】 then give a name
> that is not one of existing buffers.)
>  2.When the scratch buffer is closed, emacs does not prompt user to
> save it. This easily causes data loss.
>  3.A scratch pad can be very useful not just for temporary elisp code
> but for any scratch notes or programing in other languages. (For
> example, well known programer Stevey Yegg in his popular blog article
> Effective Emacs↗, considers creating new temp buffer as a top 10 tip
> in emacs productivity.)
>  4.Emacs does not provide a user level function to create a new
> buffer. It has menu 〖File▸Open file…〗 (a wrapper to the find-file
> command), which immediately prompt user for a full file path. This is
> annoying. Modern apps's New File command actually just create a new
> untitled file without prompting, and prompt only when user wants to
> save it. If user closes it, it prompts for saving.
>
> Proposed Fix: Adding a “new-buffer” Command
>
> I propose that emacs should add a command “new-buffer” with menu
> 〖File▸New〗. Once called, it should create a empty buffer titled
> {untitled, untitled<2>, untitled<3>, …}.
>
>  1.Users can now create multiple temp buffers easily, by just calling
> “new-buffer”. No more work-around using “switch-to-buffer” method.
>  2.Data lose is prevented because closing any unsaved buffer will
> prompt for save.
>  3.For lisp coders, new buffer can default to a lisp mode. Other
> programers can default it to python mode, ruby mode, etc.
>
>  1.No more redundant and mysterious “*scratch*” concept.
>  2.The menu command “New” is a widely adopted standard among apps
> across Mac, Windows, Linux.
>  3.A “new-buffer” command completely cover the functionality of
> emacs's “*scratch*” buffer.
>  4.The name “untitled” is conventional, widely understood.
>
> Implementation
>
> The above suggestion is implemented in ErgoEmacs Keybinding, where you
> simply press 【Ctrl+n】 to create a new buffer.
>

Re: Emacs: Problems of the Scratch Buffer

[Stefan Monnier]

>  3. The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY.

The reason behind the *scratch* buffer is highly confidential, but since
you're all trustworthy Emacs users here, I'll tell you (but please
promise you won't tell anyone else):

   It's an entrance test to the Emacs Church!


-- Stefan

Re: Emacs: Problems of the Scratch Buffer

[Dan Espen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  3. The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY.
>
> The reason behind the *scratch* buffer is highly confidential, but since
> you're all trustworthy Emacs users here, I'll tell you (but please
> promise you won't tell anyone else):
>
>    It's an entrance test to the Emacs Church!

Are there alternate designs for the scratch buffer?
There are variations on everything else in Emacs.

-- 
Dan Espen

Re: Emacs: Problems of the Scratch Buffer

[Stefan Monnier]

>>> 3. The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY.
>> The reason behind the *scratch* buffer is highly confidential, but since
>> you're all trustworthy Emacs users here, I'll tell you (but please
>> promise you won't tell anyone else):
>> It's an entrance test to the Emacs Church!
> Are there alternate designs for the scratch buffer?
> There are variations on everything else in Emacs.

Surprisingly, it looks nobody was sufficiently annoyed to come up with
an alternative.  Which doesn't surprise me.  I just happily ignored the
*scratch* buffer for most of my early Emacs-user life, and I expect
most people do too.


        Stefan

Re: Emacs: Problems of the Scratch Buffer

[Dan Espen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> 3. The “*scratch*” “buffer” is a INTRUSIVE IDIOSYNCRASY.
>>> The reason behind the *scratch* buffer is highly confidential, but since
>>> you're all trustworthy Emacs users here, I'll tell you (but please
>>> promise you won't tell anyone else):
>>> It's an entrance test to the Emacs Church!
>> Are there alternate designs for the scratch buffer?
>> There are variations on everything else in Emacs.
>
> Surprisingly, it looks nobody was sufficiently annoyed to come up with
> an alternative.  Which doesn't surprise me.  I just happily ignored the
> *scratch* buffer for most of my early Emacs-user life, and I expect
> most people do too.

Yep.

I'm having a hard time figuring out what _would_ be useful in a scratch
buffer.

-- 
Dan Espen

Re: Emacs: Problems of the Scratch Buffer

[Chiron]

On Sat, 21 Apr 2012 12:08:25 -0400, Dan Espen wrote:

> I'm having a hard time figuring out what _would_ be useful in a scratch
> buffer.

I use it to check out lisp statements as I try to learn the language.

I suppose it would be very helpful if I were to want to make changes to 
emacs using elisp, to test and debug my stuff.

-- 
I don't want to be young again, I just don't want to get any older.

Re: Emacs: Problems of the Scratch Buffer

[Dan Espen]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> On Sat, 21 Apr 2012 12:08:25 -0400, Dan Espen wrote:
>
>> I'm having a hard time figuring out what _would_ be useful in a scratch
>> buffer.
>
> I use it to check out lisp statements as I try to learn the language.
>
> I suppose it would be very helpful if I were to want to make changes to 
> emacs using elisp, to test and debug my stuff.

I've tried that on occasion but I soon end up in my .emacs or some .el
file and evaluating things there is easy enough.

-- 
Dan Espen

RE: Emacs: Problems of the Scratch Buffer

[Ludwig, Mark]

> From: Dan Espen
> Sent: Saturday, April 21, 2012 12:31 PM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs: Problems of the Scratch Buffer
> 
> Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:
> 
> > On Sat, 21 Apr 2012 12:08:25 -0400, Dan Espen wrote:
> >
> >> I'm having a hard time figuring out what _would_ be useful in a scratch
> >> buffer.
> >
> > I use it to check out lisp statements as I try to learn the language.
> >
> > I suppose it would be very helpful if I were to want to make changes to
> > emacs using elisp, to test and debug my stuff.
> 
> I've tried that on occasion but I soon end up in my .emacs or some .el
> file and evaluating things there is easy enough.

I have similar feelings.  It might use *scratch* more if it were in text mode, because mostly my spur-of-the-moment uses of Emacs in my Windows development environment are to "neutralize" copied text before pasting into some tool that's paying too much attention to formatting.  (I almost always just want the simple text, and sometimes it's surprisingly hard to get the stuff back to simple text after pasting it.)

I know how to change the mode and how to make that permanent, but haven't because I have another personal journal-like file open in a buffer that is in text mode all of the time (so use it for neutralizing text), and for those few occasions when I need Lisp interpretation, I switch back to *scratch* and do so.

If there were something like M-x scratch, I probably would just delete *scratch*, and in this mythical world, if there were a further option to not create *scratch* unless there is nothing else for Emacs to show, I would use that too.

Now, can anyone tell me why *scratch* has RET bound to (newline) instead of (eval-print-last-sexp)?  Seems that the bindings of RET and C-j are reversed for common uses....

Cheers,
Mark

Re: Emacs: Problems of the Scratch Buffer

[Petter Gustad]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> On Sat, 21 Apr 2012 12:08:25 -0400, Dan Espen wrote:
>
>> I'm having a hard time figuring out what _would_ be useful in a scratch
>> buffer.
>
> I use it to check out lisp statements as I try to learn the language.

You can do that with any buffer associated with lisp-interaction-mode

C-x b my-elisp-eval-buffer
M-x lisp-interaction-mode


//Petter
-- 
.sig removed by request. 

Re: Emacs: Problems of the Scratch Buffer

[Richard Riley]

Petter Gustad <newsmailcomp6@gustad.com> writes:

> Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:
>
>> On Sat, 21 Apr 2012 12:08:25 -0400, Dan Espen wrote:
>>
>>> I'm having a hard time figuring out what _would_ be useful in a scratch
>>> buffer.
>>
>> I use it to check out lisp statements as I try to learn the language.
>
> You can do that with any buffer associated with lisp-interaction-mode
>
> C-x b my-elisp-eval-buffer
> M-x lisp-interaction-mode
>
> //Petter

precisely, as well as create your own scratch buffer from your .emacs if
you're anyway proficient enough to even want a scratch buffer : which
was the main point about usability and "first look" impressions. Even
learning emacs and some elisp for customisation I can honestly say I
never once used the scratch buffer, all interation and evaluation went
on from my init.el as it went-

Re: Emacs: Problems of the Scratch Buffer

[Nikolai Alekseev]

But now we *already* have this buffer.

Re: Emacs: Problems of the Scratch Buffer

[Nikolai Alekseev]

It's *scratch* buffer, like scratch paper on table. If you don't use
scratch paper, don't use *scratch* buffer. Sometimes I just write
random thoughts, or paste unsortable interesting text.