New start up splash screen annoyance...

New start up splash screen annoyance...

[Sascha Wilde]

Hi *,

basically I like the idea of a configurable start-up behavior.  But
the current implementation is IMNSHO very flawed:

- First and most annoying: starting Emacs with an file to visit as
  argument no longer works as expected.  Without doing any configuration
  you always get the new splash screen and of cause C-l or starting
  editing doesn't make it go away.  You can switch to the buffer with
  the file using C-x C-b, but the splash screen doesn't tell you that.

I would like to have the old behavior back:  if a file name was given
on the command line the user definitely wants to edit that file, and
so any editing/movement/redraw command should switch to that files
buffer immediately.  In case people don't agree on that, the splash
screen should at least mention how to enter the buffer.

- Second, and maybe even worse: None of the settings for
  initial-buffer-choice restores the old behavior.  One might expect,
  that setting initial-buffer-choice to t (open *scratch* buffer)
  would be the right choice, but it isn't.  If set that way, the
  annoying behavior described above stays with the only differences,
  that the *scratch* buffer is opened and stays, even if a file to
  edit was given on start-up.

One would expect that at least one value of initial-buffer-choice
would restore the old behavior, which many of use are used to and
which at least me likes best: open *scratch* as default but open the
buffer(s) for the given files from the command line if there were
any. 

The only working solution is to set inhibit-splash-screen to t
and leave initial-buffer-choice nil -- which is a pity as the new
possibility of customizing the default behavior is lost.

- Third, as setting inhibit-splash-screen is the only (and as far as I
  can see not ell documented) way to get back the old behavior, it is
  a (minor) annoyance that inhibit-splash-screen not only turns of the
  splash screen, but the initial message in the *scratch* buffer too.
  Actually I never understood why this two things are configured by
  only one variable.

cheers
sascha
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

Re: New start up splash screen annoyance...

[Leo]

On 2007-09-09 14:56 +0100, Sascha Wilde wrote:
> - First and most annoying: starting Emacs with an file to visit as
>   argument no longer works as expected.  Without doing any configuration
>   you always get the new splash screen and of cause C-l or starting
>   editing doesn't make it go away.  You can switch to the buffer with
>   the file using C-x C-b, but the splash screen doesn't tell you that.

q to exit the startup screen.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: New start up splash screen annoyance...

[Mathias Dahl]

> - First and most annoying: starting Emacs with an file to visit as
>   argument no longer works as expected.  Without doing any configuration
>   you always get the new splash screen and of cause C-l or starting
>   editing doesn't make it go away.  You can switch to the buffer with
>   the file using C-x C-b, but the splash screen doesn't tell you that.

I agree. I knew that typing `q' would close the splash screen, but it
does not say anywhere, so a new user must be very confused about what
happened with his file.

Re: New start up splash screen annoyance...

[Richard Stallman]

    I would like to have the old behavior back:  if a file name was given
    on the command line the user definitely wants to edit that file, and
    so any editing/movement/redraw command should switch to that files
    buffer immediately.

I changed this because I want beginners to see the splash screen,
and beginners often have the habit of passing a file name.

      In case people don't agree on that, the splash
    screen should at least mention how to enter the buffer.

That is a good point.  We should make this easier.  Maybe typing SPC
on the splash screen should bury or kill it.  Also, we should say how
to do this, if we can fit it in.

    - Second, and maybe even worse: None of the settings for
      initial-buffer-choice restores the old behavior.

Given that we have another variable to do that,
who cares whether this variable can do that?
Why do you care?

    - Third, as setting inhibit-splash-screen is the only (and as far as I
      can see not ell documented) way to get back the old behavior, it is
      a (minor) annoyance that inhibit-splash-screen not only turns of the
      splash screen, but the initial message in the *scratch* buffer too.
      Actually I never understood why this two things are configured by
      only one variable.

We could change it not to affect the initial message in *scratch*.
However, if *scratch* is not the initial buffer, is that message
really needed anyway?  Maybe we should just get rid of it.

Re: New start up splash screen annoyance...

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     I would like to have the old behavior back:  if a file name was given
>     on the command line the user definitely wants to edit that file, and
>     so any editing/movement/redraw command should switch to that files
>     buffer immediately.
>
> I changed this because I want beginners to see the splash screen,
> and beginners often have the habit of passing a file name.

The way Emacs currently handles the splash screen is completely
unsatisfactory, because it gives the impression that the splash screen
is being displayed *instead of* the file specified by the user (and
thus implies that Emacs is unable to process command line arguments.)

The way other programs handle this is to (1) display the splash screen
in a small, floating X window, (2) provide a check box on the splash
screen saying "Display splash screen on startup" or something similar,
and (3) a prominent button saying "OK" or similar to dismiss the
splash screen.

Using a small, floating X window lets the user see that the command
line argument was processed correctly, since the main X window is
visible behind the splash screen panel.  In our case, it may be better
to use a pop-to-buffer.  Providing a check box makes it easy to
dismiss the splash screen, which in my experience almost everyone ends
up doing, since a splash screen gets annoying after the first time you
see it (and you shouldn't have to read the documentation to find out
how to disable it!)

Re: New start up splash screen annoyance...

[Juri Linkov]

> The way Emacs currently handles the splash screen is completely
> unsatisfactory, because it gives the impression that the splash screen
> is being displayed *instead of* the file specified by the user (and
> thus implies that Emacs is unable to process command line arguments.)

Yes, this looks like a bug, and this is confusing for beginners who don't
know how to turn this behavior off.

> The way other programs handle this is to (1) display the splash screen
> in a small, floating X window,

Clicking on the close button to close the floating X window is no less
annoying solution that typing a key to close the current startup screen.

> (2) provide a check box on the splash screen saying "Display splash
> screen on startup" or something similar, and

Now there is a link on the startup screen leading to customization,
so it is easier now to disable the startup screen.  But still this doesn't
remove the problem, because customization is not always desirable.

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

Re: New start up splash screen annoyance...

[Richard Stallman]

    > The way Emacs currently handles the splash screen is completely
    > unsatisfactory, because it gives the impression that the splash screen
    > is being displayed *instead of* the file specified by the user (and
    > thus implies that Emacs is unable to process command line arguments.)

    Yes, this looks like a bug, and this is confusing for beginners who don't
    know how to turn this behavior off.

The best way is: don't specify a file name argument when you start
Emacs.  That kind of argument is supported for compatibility with
other editors, but it is not the recommended way to use Emacs.
Experienced Emacs users generally don't do it anyway.

Re: New start up splash screen annoyance...

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > The way Emacs currently handles the splash screen is completely
>     > unsatisfactory, because it gives the impression that the splash screen
>     > is being displayed *instead of* the file specified by the user (and
>     > thus implies that Emacs is unable to process command line arguments.)
>
>     Yes, this looks like a bug, and this is confusing for beginners who don't
>     know how to turn this behavior off.
>
> The best way is: don't specify a file name argument when you start
> Emacs.  That kind of argument is supported for compatibility with
> other editors, but it is not the recommended way to use Emacs.
> Experienced Emacs users generally don't do it anyway.

I often find it convenient to use Emacs with filename arguments.
Obviously, different people have different usage patterns.

You seem to be arguing that just because *you* don't use a particular
Emacs feature, it is OK for Emacs to exhibit broken or annoying
behavior for that feature.

Re: New start up splash screen annoyance...

[Leo]

On 2007-09-10 18:00 +0100, Chong Yidong wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>>     > The way Emacs currently handles the splash screen is completely
>>     > unsatisfactory, because it gives the impression that the splash screen
>>     > is being displayed *instead of* the file specified by the user (and
>>     > thus implies that Emacs is unable to process command line arguments.)
>>
>>     Yes, this looks like a bug, and this is confusing for beginners who don't
>>     know how to turn this behavior off.
>>
>> The best way is: don't specify a file name argument when you start
>> Emacs.  That kind of argument is supported for compatibility with
>> other editors, but it is not the recommended way to use Emacs.
>> Experienced Emacs users generally don't do it anyway.
>
> I often find it convenient to use Emacs with filename arguments.
> Obviously, different people have different usage patterns.
>
> You seem to be arguing that just because *you* don't use a particular
> Emacs feature, it is OK for Emacs to exhibit broken or annoying
> behavior for that feature.

I agree with Chong.

Experienced users don't use startup screen anyway. But we are trying to
make newbies happy.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: New start up splash screen annoyance...

[Richard Stallman]

    Experienced users don't use startup screen anyway. But we are trying to
    make newbies happy.

Not exactly.  We are trying to make sure newbies see some of this
information, even if it makes them a little less happy.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Experienced users don't use startup screen anyway. But we are trying to
>     make newbies happy.
>
> Not exactly.  We are trying to make sure newbies see some of this
> information, even if it makes them a little less happy.

The way to win people's heart is not by making them unhappy.

"Welcome! To learn about Emacs, press F1 C-a or use the Help/About menu."

Use an idle-timer to make sure that for the first 30 seconds of
idleness, regardless how Emacs has been started, this message is not
obscured for longer than 5 seconds (of course, unless the startup
screen _is_ actually being displayed which would be the default for an
Emacs started without command line options and not, say, loading a
desktop or doing other startup operations ending in a dedicated
buffer).

It may take weeks before the user visits the screen.  But when he
does, the important thing is that he does it because _he_ chooses to
do so.  So he'll be in a reasonably open frame of mind.

And we want him in a reasonably open frame of mind to teach him about
GNU.

The worst epithet used for some kind of obnoxiously advertising
software is "nagware".  We don't want to be grouped along with them if
we can avoid it at reasonable cost, and not permitting the user to see
the file he has explicitly specified to be seen is right in that
ballpark.  And "people will recognize that everything's different when
we do it because we are the good guys" never works.  Not in
government, not in software.

It does not matter whether we are the good guys or not: people will
hate us for it.  And that does not help our cause.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Juri Linkov]

> The way to win people's heart is not by making them unhappy.
>
> "Welcome! To learn about Emacs, press F1 C-a or use the Help/About menu."

Good idea!  Just one line gives all necessary information about how to get
more help.  We can even make it more visible by highlighting it in bold red.

> Use an idle-timer to make sure that for the first 30 seconds of
> idleness, regardless how Emacs has been started, this message is not
> obscured for longer than 5 seconds (of course, unless the startup
> screen _is_ actually being displayed which would be the default for an
> Emacs started without command line options and not, say, loading a
> desktop

Yes, seeing the startup screen after loading a desktop instead of the
last saved file is the same annoyance as for starting Emacs with a file.
Furthermore, loading a desktop means that the user has already seen the
startup screen at least once on the previous session before saving the
desktop.

> or doing other startup operations ending in a dedicated buffer).

Like for instance,

emacs --eval '(info)'

when the user wants to use the Emacs Info reader instead of the standalone
Info reader, and sees the startup screen instead of the Info buffer.
The standalone Info reader does not do such bad things.

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

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > The way Emacs currently handles the splash screen is completely
>     > unsatisfactory, because it gives the impression that the splash screen
>     > is being displayed *instead of* the file specified by the user (and
>     > thus implies that Emacs is unable to process command line arguments.)
>
>     Yes, this looks like a bug, and this is confusing for beginners who don't
>     know how to turn this behavior off.
>
> The best way is: don't specify a file name argument when you start
> Emacs.  That kind of argument is supported for compatibility with
> other editors, but it is not the recommended way to use Emacs.

So what is the recommended way to use Emacs when one wants to edit a
file and has no Emacs session started already?  And why would I start
an Emacs session when I don't want to edit anything?

> Experienced Emacs users generally don't do it anyway.

Huh?  If I start Emacs, why should I not specify what file I want to
edit as an experienced user?

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Richard Stallman]

    So what is the recommended way to use Emacs when one wants to edit a
    file and has no Emacs session started already?

If you have no Emacs running, type `emacs'.
Otherwise, resume your existing Emacs.

Then type C-x C-f FILE RET.

    > Experienced Emacs users generally don't do it anyway.

    Huh?  If I start Emacs, why should I not specify what file I want to
    edit as an experienced user?

Because nearly always you already have an Emacs running.
It is a bad idea to teach yourself habits that presume
you don't have an Emacs running, because that would lead
you to kill Emacs and restart it, or to start multiple Emacs jobs.

Over 20 years of Emacs experience shows that it is important to teach
beginners to unlearn the habit of finding a file by typing `emacs FILE'.

Re: New start up splash screen annoyance...

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     So what is the recommended way to use Emacs when one wants to edit a
>     file and has no Emacs session started already?
>
> If you have no Emacs running, type `emacs'.
> Otherwise, resume your existing Emacs.
>
> Then type C-x C-f FILE RET.
>
> It is a bad idea to teach yourself habits that presume
> you don't have an Emacs running, because that would lead
> you to kill Emacs and restart it, or to start multiple Emacs jobs.
>
> Over 20 years of Emacs experience shows that it is important to teach
> beginners to unlearn the habit of finding a file by typing `emacs FILE'.

What you say may have been true 20 years ago.

On modern computers, Emacs starts up so quickly and uses such an
insignificant amount of memory that there is basically much no
difference between starting a new Emacs and returning to a
pre-existing Emacs session.

Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[Bill Wohler]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     So what is the recommended way to use Emacs when one wants to edit a
>>     file and has no Emacs session started already?
>>
>> If you have no Emacs running, type `emacs'.
>> Otherwise, resume your existing Emacs.
>>
>> Then type C-x C-f FILE RET.
>>
>> It is a bad idea to teach yourself habits that presume
>> you don't have an Emacs running, because that would lead
>> you to kill Emacs and restart it, or to start multiple Emacs jobs.
>>
>> Over 20 years of Emacs experience shows that it is important to teach
>> beginners to unlearn the habit of finding a file by typing `emacs FILE'.
>
> What you say may have been true 20 years ago.
>
> On modern computers, Emacs starts up so quickly and uses such an
> insignificant amount of memory that there is basically much no
> difference between starting a new Emacs and returning to a
> pre-existing Emacs session.

Agreed.

Not only that, consider other legitimate use cases such as "sudo emacs
FILE" or "ssh SOME_REMOTE_MACHINE; emacs -nw FILE". Emacs would start
up as fast as vi if it weren't for the blasted splash screen that
needs to be dismissed.

I like David's idea of "Welcome! To learn about Emacs, press F1 C-a or
use the Help/About menu." And it can go in the mini-buffer where it
will not contribute to the principle of least astonishment (or most
annoyance, whatever the case may be).

Here's something completely different: If it hurts when the user does
something, don't let them do it.

Many programs today will attach themselves to an existing process when
started. Emacs can do the same thing. If the "emacs" executable
detects an existing process on the local machine owned by the same
user in the same session (X server), and the -nw option is not
specified, it can behave like emacsclient; otherwise, it starts a new
process.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Folding emacsclient into emacs

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> On modern computers, Emacs starts up so quickly and uses such an
>> insignificant amount of memory that there is basically much no
>> difference between starting a new Emacs and returning to a
>> pre-existing Emacs session.
>
> Agreed.

Not here.

> Not only that, consider other legitimate use cases such as "sudo
> emacs FILE" or "ssh SOME_REMOTE_MACHINE; emacs -nw FILE".

C-x C-f /sudo::FILE RET
C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET

> Here's something completely different: If it hurts when the user
> does something, don't let them do it.
>
> Many programs today will attach themselves to an existing process
> when started. Emacs can do the same thing. If the "emacs" executable
> detects an existing process on the local machine owned by the same
> user in the same session (X server), and the -nw option is not
> specified, it can behave like emacsclient; otherwise, it starts a
> new process.

Emacs is not multi-threaded, so there are legitimate use cases to have
several Emacs sessions open.  Actually, another argument against the
"there need only be one" claim.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Folding emacsclient into emacs

[Bill Wohler]

David Kastrup <dak@gnu.org> wrote:

> C-x C-f /sudo::FILE RET
> C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET

Very, very cool, didn't know about that. Why doesn't the help for C-x
C-f even hint that this sort of thing is possible? Maybe it can be
mentioned on the splash screen for beginners like me.

Thanks for the tip.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Folding emacsclient into emacs

[dhruva]

Hi,

On 9/12/07, Bill Wohler <wohler@newt.com> wrote:
> David Kastrup <dak@gnu.org> wrote:
>
> > C-x C-f /sudo::FILE RET
> > C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
>
> Very, very cool, didn't know about that. Why doesn't the help for C-x
> C-f even hint that this sort of thing is possible? Maybe it can be
> mentioned on the splash screen for beginners like me.

FWIK, it comes from TRAMP and the info link for TRAMP has it.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Folding emacsclient into emacs

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>
> On 9/12/07, Bill Wohler <wohler@newt.com> wrote:
>> David Kastrup <dak@gnu.org> wrote:
>>
>> > C-x C-f /sudo::FILE RET
>> > C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
>>
>> Very, very cool, didn't know about that. Why doesn't the help for C-x
>> C-f even hint that this sort of thing is possible? Maybe it can be
>> mentioned on the splash screen for beginners like me.
>
> FWIK, it comes from TRAMP and the info link for TRAMP has it.

But since tramp is built into Emacs 22, there is no sense not
distributing the knowledge further.  One place where it likely would
make sense is the graphical file dialog (which we plaster with
information about how to remove the dialog already).

Or maybe the open file menu tooltip?  While there are people and
systems where it will probably be rarely if ever shown, having the
information there in addition to where else it makes sense could not
be worse than now.

Or we add a menu entry "Open remote/privileged file" which prompts for
method, host, username and after opening leaves a message "Note:
equivalent to C-x C-f /sudo::/etc/host" (and, of course, puts the
right find-file incantation directly into the Lisp command history).

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Eli Zaretskii]

> Date: Wed, 12 Sep 2007 12:36:28 +0530
> From: dhruva <dhruvakm@gmail.com>
> 
> > > C-x C-f /sudo::FILE RET
> > > C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
> >
> > Very, very cool, didn't know about that. Why doesn't the help for C-x
> > C-f even hint that this sort of thing is possible? Maybe it can be
> > mentioned on the splash screen for beginners like me.
> 
> FWIK, it comes from TRAMP and the info link for TRAMP has it.

Btw, the node "Filename Syntax" in the Tramp manual does not list all
the possible methods supported by Tramp.  For example, /sudo: is not
there.  It would be a good idea, IMO, to have a node with a catalog of
all the methods supported by tramp.el out of the box, instead of (or
maybe in addition to) having them scattered throughout the manual.

Re: Folding emacsclient into emacs

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, the node "Filename Syntax" in the Tramp manual does not list all
> the possible methods supported by Tramp.  For example, /sudo: is not
> there.  It would be a good idea, IMO, to have a node with a catalog of
> all the methods supported by tramp.el out of the box, instead of (or
> maybe in addition to) having them scattered throughout the manual.

(info "(tramp)Inline methods")
(info "(tramp)External transfer methods")
(info "(tramp)Gateway methods")

Yes, three sections, because it's a lot of material. And indeed, they
shall be put into a superordinate chapter "Methods", or so.

I'll add references to these nodes from section "Filename Syntax" tonight.

Best regards, Michael.

Re: Folding emacsclient into emacs

[Eli Zaretskii]

> Date: Tue, 11 Sep 2007 22:57:03 -0700
> From: Bill Wohler <wohler@newt.com>
> Cc: emacs-devel@gnu.org
> 
> David Kastrup <dak@gnu.org> wrote:
> 
> > C-x C-f /sudo::FILE RET
> > C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
> 
> Very, very cool, didn't know about that. Why doesn't the help for C-x
> C-f even hint that this sort of thing is possible?

It does now.

Thanks for suggesting this.

Tramp (was: Folding emacsclient into emacs)

[Bill Wohler]

David Kastrup <dak@gnu.org> wrote:

> C-x C-f /sudo::FILE RET
> C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET

How about if I want to run "M-x svn-status RET / RET" as root locally.

How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
me or as root on a remote machine? Note that the remote machine is
configured to not accept ssh connections as root--you have to log in as
another user first. I tried "M-x svn-status RET /ssh:host:~wohler RET"
and that produced a view of my home directory on localhost.

Also, I read in the manual (for tramp version 2.1.11) about
tramp-default-proxies-alist so that one can edit files as root on a
remote host, but that variable does not appear to be available in tramp
2.0.55 (in Emacs 22).

Thanks again.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Tramp

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> C-x C-f /sudo::FILE RET
>> C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
>
> How about if I want to run "M-x svn-status RET / RET" as root
> locally.

M-x svn-status RET /sudo::/ RET

> How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
> me or as root on a remote machine?

M-x svn-status RET /ssh:root@SOME_REMOTE_MACHINE:FILE RET

> Note that the remote machine is configured to not accept ssh
> connections as root--you have to log in as another user first.

> I tried "M-x svn-status RET /ssh:host:~wohler RET" and that produced
> a view of my home directory on localhost.

Then there is something wrong and you should file a proper bug report.

> Also, I read in the manual (for tramp version 2.1.11) about
> tramp-default-proxies-alist so that one can edit files as root on a
> remote host, but that variable does not appear to be available in
> tramp 2.0.55 (in Emacs 22).

You can use multihop methods.

-- 
David Kastrup

Re: Tramp

[Michael Albinus]

Bill Wohler <wohler@newt.com> writes:

> How about if I want to run "M-x svn-status RET / RET" as root locally.
>
> How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
> me or as root on a remote machine? Note that the remote machine is
> configured to not accept ssh connections as root--you have to log in as
> another user first. I tried "M-x svn-status RET /ssh:host:~wohler RET"
> and that produced a view of my home directory on localhost.

All this should be possible with Tramp 2.1, which is integrated in the
Emacs trunk.

> Also, I read in the manual (for tramp version 2.1.11) about
> tramp-default-proxies-alist so that one can edit files as root on a
> remote host, but that variable does not appear to be available in tramp
> 2.0.55 (in Emacs 22).

Emacs 22.x won't be upgraded to Tramp 2.1 I suspect. So you must
either use Emacs 23.0.50 (that is the Emacs trunk from CVS), or
install Tramp 2.1 in parallel to Emacs 22.

> Thanks again.

Best regards, Michael.

Re: Folding emacsclient into emacs

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

David> Emacs is not multi-threaded, so there are legitimate use cases to have
David> several Emacs sessions open.  Actually, another argument against the
David> "there need only be one" claim.

I'd like to hear more about these use cases.

There are some drawbacks to running multiple copies of Emacs.  I used
to do this (one for hacking, one for gnus) but was occasionally
frustrated by the lack of shared state (which is obvious... the nice
thing about a a highly integrated environment is its integration).
Also having to figure out which one ought to be the server is somewhat
irritating.

These days Emacs is fast enough (or Emacs is the same and the machines
are fast enough :-) that I haven't felt the need to run multiple
copies.

There are still a few areas where the lack of threading is noticeable.
Getting new news in Gnus remains one of these.  Also on this list are
some VC operations (until recently, annotate) and running pcvs or psvn
on a large project.

Tom

Re: Folding emacsclient into emacs

[Leo]

On 2007-09-12 21:20 +0100, Tom Tromey wrote:
> These days Emacs is fast enough (or Emacs is the same and the machines
> are fast enough :-) that I haven't felt the need to run multiple
> copies.
>
> There are still a few areas where the lack of threading is noticeable.
> Getting new news in Gnus remains one of these.  Also on this list are
> some VC operations (until recently, annotate) and running pcvs or psvn
> on a large project.

In article <microsoft-free.87ekh7nr5w.fsf@youngs.au.com>, Steve has
announced a multi-threaded Emacs. So at least we have something to look
forward to.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: Folding emacsclient into emacs

[Jan Djärv]

Tom Tromey skrev:

> 
> There are still a few areas where the lack of threading is noticeable.
> Getting new news in Gnus remains one of these.  Also on this list are
> some VC operations (until recently, annotate) and running pcvs or psvn
> on a large project.
> 

Working on multiple projects/branches.  I like having separate TAGS, desktop 
save files, and so on for each branch.  Having a lot of file.c, file.c<2>, 
file.c<3> and so on doesn't help when you what to select file.c for a specific 
branch.  I also run each instance of Emacs in separate X11 workspace to 
separate them visually also.

	Jan D.

Re: Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[Robert J. Chassell]

>> Over 20 years of Emacs experience shows that it is important to teach
>> beginners to unlearn the habit of finding a file by typing `emacs FILE'.

Yes.  After all, you don't start a window manager for every FILE
evocation.  Nor do you start any other basic program, like an xterm in
a window manager.

Only people with bad habits start an instance of a window manager for
every FILE evocation or an instance of Emacs every time.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[Robert J. Chassell]

Bill Wohler <wohler@newt.com> wrote

    ... consider other legitimate use cases such as "sudo emacs FILE"

That is another bad habit.  It is an illegitimate use of the feature.
Don't you keep a root owned instance of Emacs running all the time you
are at your terminal, when it is safe to run as root?  Or run as
another user?  Do you start other fundamental programs frequently,
like xterms or your window managers?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Bill Wohler <wohler@newt.com> wrote
>
>     ... consider other legitimate use cases such as "sudo emacs FILE"
>
> That is another bad habit.  It is an illegitimate use of the feature.
> Don't you keep a root owned instance of Emacs running all the time you
> are at your terminal, when it is safe to run as root?  Or run as
> another user?  Do you start other fundamental programs frequently,
> like xterms or your window managers?

Whatever.  It is not the job of Emacs to punish users that have
different work styles or preferences or habits from yours or mine.

Emacs is the tool, not the master.

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Bill Wohler]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Don't you keep a root owned instance of Emacs running all the time you
> are at your terminal, when it is safe to run as root?

This is a bad idea. Step away for a moment without locking your screen
and someone can come in an wreak havoc on your system. In my case,
there is no need for the clutter of an Emacs in my taskbar that I
might only need once every two weeks or less. As it turns out, your
suggestion is an illegitimate use of Emacs (to use your argument)
since you can use Tramp from your existing invocation for the same
effect.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Folding emacsclient into emacs

[Chong Yidong]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Bill Wohler <wohler@newt.com> wrote
>
>     ... consider other legitimate use cases such as "sudo emacs FILE"
>
> That is another bad habit.  It is an illegitimate use of the feature.
>
> Don't you keep a root owned instance of Emacs running all the time you
> are at your terminal, when it is safe to run as root?

That is a much worse (and potentially disastrous) habit.

Re: Folding emacsclient into emacs

[Robert J. Chassell]

    > Don't you keep a root owned instance of Emacs running all the
    > time you are at your terminal, when it is safe to run as root?

    That is a much worse (and potentially disastrous) habit.

It is safe to run root if you do not expect anyone to break into your
home office when you are there; it is definitely a disasterous habit
if you expect a stranger or a malicious friend or a well-intentioned
but careless person (as happened to me in 1984) come to your terminal
when you have stepped way from it.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[Richard Stallman]

	... consider other legitimate use cases such as "sudo emacs FILE"

    That is another bad habit.  It is an illegitimate use of the feature.

It is better not to have a root Emacs running all the time.  But each
time you do need one, you will probably visit multiple files in it.
So it is still not a good habit to specify file name args.

Re: Folding emacsclient into emacs

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> 	... consider other legitimate use cases such as "sudo emacs FILE"
>
>     That is another bad habit.  It is an illegitimate use of the feature.
>
> It is better not to have a root Emacs running all the time.  But each
> time you do need one, you will probably visit multiple files in it.
> So it is still not a good habit to specify file name args.

It is not like specifying file name args would cause Emacs to quit on
its own or do anything awful.

So I utterly disagree with you here.  If I know that I am going to
edit one or more files with certain names when calling Emacs, there is
no gain whatsoever in using C-x C-f instead of just listing the files
on the command line.

It is a bad habit to exit Emacs when one might need it soon.  But
there is nothing to be gained from starting it when one does not
actually need to edit anything.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Folding emacsclient into emacs

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 12 Sep 2007 21:08:57 +0200
> Cc: bob@rattlesnake.com, emacs-devel@gnu.org
> 
> there is nothing to be gained from starting it when one does not
> actually need to edit anything.

Are you saying that Emacs is only for editing?  Coming from one of the
Emacs developers, that sounds almost like heresy ;-)

What about reading mail, showing me the time, the calendar, and how
many hours are left for me to work on my current project?  What about
launching programs from a Dired buffer and comparing files with Ediff?
What about doing cleanups late at night when I'm asleep?  What about
the plethora of other things Emacs does that aren't editing?

Re: Folding emacsclient into emacs

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 12 Sep 2007 21:08:57 +0200
>> Cc: bob@rattlesnake.com, emacs-devel@gnu.org
>> 
>> there is nothing to be gained from starting it when one does not
>> actually need to edit anything.
>
> Are you saying that Emacs is only for editing?  Coming from one of the
> Emacs developers, that sounds almost like heresy ;-)
>
> What about reading mail, showing me the time, the calendar, and how
> many hours are left for me to work on my current project?  What about
> launching programs from a Dired buffer and comparing files with Ediff?
> What about doing cleanups late at night when I'm asleep?  What about
> the plethora of other things Emacs does that aren't editing?

Are you saying that users should be punished if the first thing they
want to do with Emacs is "merely" edit a file?

Should we punish them also when they do

emacs -f gnus

or

emacs -f rmail

or similar?

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Eli Zaretskii]

> Cc: rms@gnu.org, bob@rattlesnake.com, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 13 Sep 2007 09:45:18 +0200
> 
> Are you saying that users should be punished if the first thing they
> want to do with Emacs is "merely" edit a file?

No, of course not.  You will see from my other message in this thread
that I think the current behavior with "emacs FILE" is annoying.

But making that point doesn't mean we should use preposterously wrong
arguments such as that Emacs can be restarted whenever we need to edit
a file, or that when there's nothing to edit there's no need to have
Emacs running.

Re: Folding emacsclient into emacs

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: rms@gnu.org, bob@rattlesnake.com, emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 13 Sep 2007 09:45:18 +0200
>> 
>> Are you saying that users should be punished if the first thing they
>> want to do with Emacs is "merely" edit a file?
>
> No, of course not.  You will see from my other message in this thread
> that I think the current behavior with "emacs FILE" is annoying.
>
> But making that point doesn't mean we should use preposterously
> wrong arguments such as that Emacs can be restarted whenever we need
> to edit a file, or that when there's nothing to edit there's no need
> to have Emacs running.

I was talking about the case where the first thing you want to do when
starting Emacs is to edit a file.  All the "preposterously wrong
arguments" you try attributing to me are your own invention.

Since there is not a lack of opportunity for disagreement on this
list, it might be more productive if you focused on those things that
have actually been written.

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Eli Zaretskii]

> Cc: rms@gnu.org, bob@rattlesnake.com, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 13 Sep 2007 09:59:28 +0200
> 
> I was talking about the case where the first thing you want to do when
> starting Emacs is to edit a file.  All the "preposterously wrong
> arguments" you try attributing to me are your own invention.
> 
> Since there is not a lack of opportunity for disagreement on this
> list, it might be more productive if you focused on those things that
> have actually been written.

I was replying to what you wrote, viz:

> >> Are you saying that users should be punished if the first thing they
> >> want to do with Emacs is "merely" edit a file?

If I misunderstood what you meant, perhaps you should write more
clearly and shout on others less vociferously.

Re: Folding emacsclient into emacs

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: rms@gnu.org, bob@rattlesnake.com, emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 13 Sep 2007 09:59:28 +0200
>> 
>> I was talking about the case where the first thing you want to do when
>> starting Emacs is to edit a file.  All the "preposterously wrong
>> arguments" you try attributing to me are your own invention.
>> 
>> Since there is not a lack of opportunity for disagreement on this
>> list, it might be more productive if you focused on those things that
>> have actually been written.
>
> I was replying to what you wrote, viz:
>
>> >> Are you saying that users should be punished if the first thing they
>> >> want to do with Emacs is "merely" edit a file?
>
> If I misunderstood what you meant, perhaps you should write more
> clearly and shout on others less vociferously.

What about "first thing" did you not understand?  Isn't "first thing"
just a teensy weensy bit different from "only thing"?  And what you
wrote in reply was:

> But making that point doesn't mean we should use preposterously
> wrong arguments such as that Emacs can be restarted whenever we need
> to edit a file, or that when there's nothing to edit there's no need
> to have Emacs running.

Where did I write or even imply that Emacs should be restarted
whenever we need to edit a file?  Where did I imply that when there is
nothing to edit there is not need to have Emacs running?

And you complain about me "shouting vociferously" when you put such
nonsense into my mouth and chastize me vociferously as putting forward
"preposterously wrong arguments" you invented yourself and attributed
to me?

As I said: there is enough room for disagreement about the things
actually being written.  No need to invent any of your own for me.

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 13 Sep 2007 11:04:34 +0200
> 
> > I was replying to what you wrote, viz:
> >
> >> >> Are you saying that users should be punished if the first thing they
> >> >> want to do with Emacs is "merely" edit a file?
> >
> > If I misunderstood what you meant, perhaps you should write more
> > clearly and shout on others less vociferously.
> 
> What about "first thing" did you not understand?

I didn't understand it as an important enough part of your message, it
seems.  It's ambiguous.

> > But making that point doesn't mean we should use preposterously
> > wrong arguments such as that Emacs can be restarted whenever we need
> > to edit a file, or that when there's nothing to edit there's no need
> > to have Emacs running.
> 
> Where did I write or even imply that Emacs should be restarted
> whenever we need to edit a file?

You didn't, but others did.  You shouldn't take everything as aimed on
you; this is a discussion thread with many participants.

> And you complain about me "shouting vociferously" when you put such
> nonsense into my mouth

I didn't put it in your mouth.  And even if I did, being wrong does
not yet mean being rude.

> As I said: there is enough room for disagreement about the things
> actually being written.  No need to invent any of your own for me.

Likewise.

Re: Folding emacsclient into emacs

[Richard Stallman]

    It is a bad habit to exit Emacs when one might need it soon.  But
    there is nothing to be gained from starting it when one does not
    actually need to edit anything.

The bad habit effect is that if one gets in the habit of visiting a
file by starting Emacs, one will tend to start a new Emacs instead of
going back to the old one -- without thinking about it.

Maybe you have the constant mindfulness to overcome the force
of habit, but many users don't.

Re: Folding emacsclient into emacs

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     It is a bad habit to exit Emacs when one might need it soon.  But
>     there is nothing to be gained from starting it when one does not
>     actually need to edit anything.
>
> The bad habit effect is that if one gets in the habit of visiting a
> file by starting Emacs,

That was not what I was talking about.  I was talking about the habit
of starting Emacs by visiting a file.

I hop you can see the difference.

> one will tend to start a new Emacs instead of going back to the old
> one -- without thinking about it.
>
> Maybe you have the constant mindfulness to overcome the force of
> habit, but many users don't.

Again: it is not our task to punish users whose habits don't match
ours.  Emacs is a tool, not a master for the user.

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Richard Stallman]

    Again: it is not our task to punish users whose habits don't match
    ours.

I agree, and we are not trying to do so.

Re: Folding emacsclient into emacs

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Again: it is not our task to punish users whose habits don't match
>     ours.
>
> I agree, and we are not trying to do so.

We certainly are.  If we create behavior _particularly_ for the case
where a user's habit does not match the prescription (namely when he
dares starting Emacs with a file name) that we know to be annoying in
this case, then we _are_ punishing his habits quite deliberately.  And
the "it's for his own good" excuse does not fly when alternatives for
bringing the same information across are not even considered because
"it's his own fault to start Emacs in the wrong way".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Folding emacsclient into emacs

[Richard Stallman]

    We certainly are.  If we create behavior _particularly_ for the case
    where a user's habit does not match the prescription (namely when he
    dares starting Emacs with a file name) that we know to be annoying in
    this case, then we _are_ punishing his habits quite deliberately.

We are deliberately making sure that those people too will see the
splash screen.

      And
    the "it's for his own good" excuse

We don't say it is for his own good.  That must be a misunderstanding.

				       does not fly when alternatives for
    bringing the same information across are not even considered because
    "it's his own fault to start Emacs in the wrong way".

I never said it was his "fault".

You seem to be distorting my words to make me look bad.  It is not
much use to discuss the matter with you if you do that.

Re: Folding emacsclient into emacs

[dhruva]

Hi,
 These are my personal views with my current/limited understanding of
the whole topic.The simplest way to handle all camps is to show the
splash screen is handle the following possibilities:

1. if the user does not have a dot emacs (here we assume a seasoned
emacs user will have a dot emacs).
2. If the user has a dot emacs interpret it:
     a. If there is an explicit statement to hide the startup splash  screen,
         honor it.
     b. Check the time stamp of the dot emacs with the emacs executable, if
         emacs executable is newer, show the splash screen (with an option to
         disable it in the main screen)
     c. If there is way to store the dot emacs compatibility by
storing versions
         in a list, we could check if the current version of emacs is
newer than
         the one for which dot emacs was written. Show the splash screen and
         an option to disable by adding the current version into the
list. The list
         can be similar to 'custom-set-variables' /'custom-set-faces'.

IMHO, it is quite impossible to satisfy the different types of users
of Emacs. I see this approach in most GUI based tools on M$. There
will be a tip of the day and startup dialog that pops up with a check
box to disable it. Emacs should be no different. If someone is trying
to open a file from command line, it is clear the user wants to edit a
file and not get interrupted by a startup screen.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Folding emacsclient into emacs

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>  These are my personal views with my current/limited understanding of
> the whole topic.The simplest way to handle all camps is to show the
> splash screen is handle the following possibilities:
>
> 1. if the user does not have a dot emacs (here we assume a seasoned
> emacs user will have a dot emacs).
> 2. If the user has a dot emacs interpret it:
>      a. If there is an explicit statement to hide the startup splash  screen,
>          honor it.
>      b. Check the time stamp of the dot emacs with the emacs executable, if
>          emacs executable is newer, show the splash screen (with an option to
>          disable it in the main screen)
>      c. If there is way to store the dot emacs compatibility by
> storing versions
>          in a list, we could check if the current version of emacs is
> newer than
>          the one for which dot emacs was written. Show the splash screen and
>          an option to disable by adding the current version into the
> list. The list
>          can be similar to 'custom-set-variables' /'custom-set-faces'.

No, that is nonsense.  We don't want Emacs to behave unpredictable:
annoy the user for some time and then suddenly stop without the user
being able to figure out what he changed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Folding emacsclient into emacs

[dhruva]

Hi,

On 9/16/07, David Kastrup <dak@gnu.org> wrote:
> No, that is nonsense.  We don't want Emacs to behave unpredictable:

I really do not see anything unpredictable there. If it was too
unpredictable, I would not have clearly enumerated the various
options. Each variant involves a very conscious user interaction.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Folding emacsclient into emacs

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

> On 9/16/07, David Kastrup <dak@gnu.org> wrote:
>> No, that is nonsense.  We don't want Emacs to behave unpredictable:
>
> I really do not see anything unpredictable there. If it was too
> unpredictable, I would not have clearly enumerated the various
> options. Each variant involves a very conscious user interaction.

Interpreting touching .emacs as an instruction to disable the splash
screen does not count as "a very conscious user interaction" in my
book.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Folding emacsclient into emacs

[Robert J. Chassell]

dhruva <dhruvakm@gmail.com> wrote,

   1. if the user does not have a dot emacs (here we assume a seasoned
   emacs user will have a dot emacs).

That is not true.  OK, I see that your option 2c handles the case with
`-q' in the start string.

Please do not confuse us readers by saying something early on that you
contradict later.  Please begin your message by writing, `1. Other
than in 2c below, if the user does not have a dot emacs ...'  You know
what you plan to say, but we don't.

        c. If there is way to store the dot emacs compatibility by
           storing versions in a list, we could check if the current
           version of emacs is newer than the one for which dot emacs
           was written. Show the splash screen and an option to
           disable by adding the current version into the list.

I load different initialization files depending on which version of
Emacs I am loading.

            The list can be similar to 'custom-set-variables'
            /'custom-set-faces'.

Or it can or should be a simple setq expression in your initialization
file.  Remember, an experienced user depends more on writing setq
expressions in his or her initialization file than on putting
custom-set-variables or custom-set-faces expressions in his or her
initialization file.  Running a customize command or adjusting an
initialization file is more time consuming that simply writing a setq
expression.

   ... If someone is trying
   to open a file from command line, it is clear the user wants to edit a
   file and not get interrupted by a startup screen.

No, that is not clear.

Such a person might be a newbie who assumes that Emacs is an editor.
After all, that is what it describes itself as.  (That is a mistake,
in my opinion, but that is a different matter.)  

That person might not realize that Emacs is much more than an editor
and that you stay in it all the time, like a window manager with a
shell or with icons that invoke commands.  In Emacs, you save time by
visiting a file directly rather than by leaving an existing Emacs and
starting another.

Few start X or a restricted window manager such as those produced by
Microsoft every time he or she visits a file.  (I know, there are some
users who must start an instance of Emacs on a different machine to
visit one file.  They will then shut the connection.  For them the
option that RMS wrote is worth while.)

On the whole, most keep Emacs going all the time.  If they need
different instances for different reasons, such as for different
projects, they keep several Emacs going.  Perhaps they miniaturise
those instances they are not using or put them into different
consoles.  (I `roll up' extra instances in the same `desktop'
display.)

In any case, nowadays, most users always have an Emacs, a tiling
window manager, running in a non-tiling window manager.  Only a few
operate Emacs in a console.  (Also those running Emacs in a non-tiling
window manager may connect to a remote machine in an xterm and not use
Tramp.)

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Folding emacsclient into emacs

[Juri Linkov]

> 2. If the user has a dot emacs interpret it:
>      a. If there is an explicit statement to hide the startup splash  screen,
>          honor it.
>      b. Check the time stamp of the dot emacs with the emacs executable, if
>          emacs executable is newer, show the splash screen (with an option to
>          disable it in the main screen)
>      c. If there is way to store the dot emacs compatibility by storing versions
>         in a list, we could check if the current version of emacs is
>         newer than the one for which dot emacs was written. Show the
>         splash screen and an option to disable by adding the current
>         version into the list. The list can be similar to
>         'custom-set-variables' /'custom-set-faces'.

Much simpler heuristic would be checking for the existence of the dot emacs:
if .emacs exists in the user's home directory this definitely means that
the user is not a complete beginner and have seen the Emacs startup screen
at least once before creating .emacs.  So there is no need to show the
startup screen again when starting Emacs with command line arguments.

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

Re: Folding emacsclient into emacs

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> Much simpler heuristic would be checking for the existence of the
> dot emacs: if .emacs exists in the user's home directory this
> definitely means that the user is not a complete beginner

Disagree.  Just click "Options/Word Wrap in Text Modes" and
"Options/Save Options" and you qualify as an expert without startup
screen access?  No.

Anyway, first experiences are important.  If Emacs refuses to do what
is asked of it, that is not a good sign.  Either the splash screen
info is important, and then we want the user to _know_ how he'll get
it whenever he finally chooses to do so, or it isn't, and then frankly
the whole discussion would be pointless.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Folding emacsclient into emacs

[Glenn Morris]

David Kastrup wrote:

> Juri Linkov <juri@jurta.org> writes:
>
>> Much simpler heuristic would be checking for the existence of the
>> dot emacs: if .emacs exists in the user's home directory this
>> definitely means that the user is not a complete beginner
>
> Disagree.  Just click "Options/Word Wrap in Text Modes" and
> "Options/Save Options" and you qualify as an expert without startup
> screen access?  No.

Also, the `useradd' command installs some default dotfiles from
/etc/skel. At least on Red Hat, this includes a basic .emacs file.

(_Why_ they do it this way rather than through default.el is a
different issue...)

Re: Folding emacsclient into emacs

[Juri Linkov]

>>> Much simpler heuristic would be checking for the existence of the
>>> dot emacs: if .emacs exists in the user's home directory this
>>> definitely means that the user is not a complete beginner
>>
>> Disagree.  Just click "Options/Word Wrap in Text Modes" and
>> "Options/Save Options" and you qualify as an expert without startup
>> screen access?  No.

If the user is already familiar with the Emacs menu structure,
the user can easily find the item Help->About Emacs.

> Also, the `useradd' command installs some default dotfiles from
> /etc/skel. At least on Red Hat, this includes a basic .emacs file.
>
> (_Why_ they do it this way rather than through default.el is a
> different issue...)

We could compare .emacs with the initial .emacs in /etc/skel,
but I agree this is not worth trying.

Just another idea: what about creating a file ~/.emacs.d/startup-counter,
which contains a number of Emacs invocations, and automatically increment it
after every Emacs startup.  A bigger number would make the startup screen
less annoying: starting with displaying the startup screen in the separate
window and progressing to displaying it in the echo area with less and less
lines.

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

Re: Folding emacsclient into emacs

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> Disagree.  Just click "Options/Word Wrap in Text Modes" and
>>> "Options/Save Options" and you qualify as an expert without startup
>>> screen access?  No.
>
> If the user is already familiar with the Emacs menu structure,
> the user can easily find the item Help->About Emacs.

Why would he be familiar with the menu structure because he used one
menu once?

>> Also, the `useradd' command installs some default dotfiles from
>> /etc/skel. At least on Red Hat, this includes a basic .emacs file.
>>
>> (_Why_ they do it this way rather than through default.el is a
>> different issue...)
>
> We could compare .emacs with the initial .emacs in /etc/skel,
> but I agree this is not worth trying.
>
> Just another idea: what about creating a file
> ~/.emacs.d/startup-counter, which contains a number of Emacs
> invocations, and automatically increment it after every Emacs
> startup.  A bigger number would make the startup screen less
> annoying: starting with displaying the startup screen in the
> separate window and progressing to displaying it in the echo area
> with less and less lines.

No.  The _default_ configuration should be one that does _not_ mess
with getting basic work done.  At the same time, Emacs should not
change its behavior without being asked.  In particular not with
regard to a feature which we consider essential for new users.

If a sysadmin is asked to do something on a user account and starts
Emacs a few times while working on that, it is not acceptable that by
the time the user starts Emacs, the help information is no longer
available, either because the sysadmin had to reconfigure Emacs in
order to get his work done, or because Emacs reconfigured itself.

If we find a "startup screen less annoying" that still gets the
relevant pointers across if the user chose not to learn the initial
obnoxious startup by heart, then there is no good reason not to use
this setting right from the start rather than after a number of
iterations.

-- 
David Kastrup

Re: Folding emacsclient into emacs

[Glenn Morris]

Juri Linkov wrote:

> Just another idea: what about creating a file
> ~/.emacs.d/startup-counter, which contains a number of Emacs
> invocations, and automatically increment it after every Emacs
> startup. A bigger number would make the startup screen less
> annoying: starting with displaying the startup screen in the
> separate window and progressing to displaying it in the echo area
> with less and less lines.

Only if you get to win fabulous prizes on the millionth invocation. :)

Actually, I guess you should rather count the Emacs uptime. Or
keypresses! But I don't think this will fly.

Re: Folding emacsclient into emacs

[Richard Stallman]

    If the user is already familiar with the Emacs menu structure,
    the user can easily find the item Help->About Emacs.

The question is not whether he CAN, it is whether he is likely to do
so.

Re: Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[Davis Herring]

> Many programs today will attach themselves to an existing process when
> started. Emacs can do the same thing. If the "emacs" executable
> detects an existing process on the local machine owned by the same
> user in the same session (X server), and the -nw option is not
> specified, it can behave like emacsclient; otherwise, it starts a new
> process.

Such attachment is not necessarily a good idea, and it certainly shouldn't
be the default.  If the new process exits immediately (after sending its
command line to another process), then such things as shell scripts will
break; if it waits, how long should it wait when the command is simply
"emacs"?  Should it wait forever if the user (perhaps not even knowing
that there are two "emacs" processes) never kills the buffers that the
command line creates?

I don't see much harm in the behavior if it's explicitly requested, but it
seems that emacsclient could support it (if it doesn't already) with the
--alternate-editor option.

Davis

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

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Tue, 11 Sep 2007 16:57:20 -0400
> Cc: juri@jurta.org, wilde@sha-bang.de, emacs-devel@gnu.org
> 
> > Over 20 years of Emacs experience shows that it is important to teach
> > beginners to unlearn the habit of finding a file by typing `emacs FILE'.
> 
> What you say may have been true 20 years ago.
> 
> On modern computers, Emacs starts up so quickly and uses such an
> insignificant amount of memory that there is basically much no
> difference between starting a new Emacs and returning to a
> pre-existing Emacs session.

There will always be a difference, no matter how fast and memory-rich
our computers will be, as long as ending a session makes certain
things go away, like history variables, buffers that don't visit
files, etc.

If I take your argument to the absurd, you are actually saying that if
the machine boots fast enough, let's reboot it for each new command we
run.  Why not? it certainly cleans up memory from random junk put
there by buggy software.

Re: New start up splash screen annoyance...

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> On modern computers, Emacs starts up so quickly and uses such an
>> insignificant amount of memory that there is basically much no
>> difference between starting a new Emacs and returning to a
>> pre-existing Emacs session.
>
> There will always be a difference, no matter how fast and memory-rich
> our computers will be, as long as ending a session makes certain
> things go away, like history variables, buffers that don't visit
> files, etc.

Obviously there's a tradeoff.  For instance, for my usage patterns,
the advantages you mention are offset by the fact that:

  (1) Finding the old Emacs window, selecting it, and opening the file
      there interrupts my train of thought.  On a cluttered desktop,
      this can take about a second or more.  (I don't use emacsclient
      for various other reasons.)

  (2) I sometimes find accumulated Emacs session variables annoying
      rather than useful, e.g. a buffer list containing files from two
      completely unrelated projects I am concurrently working on.

  (3) Since Emacs is single-threaded, checking mail in Emacs
      interrupts all other work taking place in that instance of
      Emacs, so I must have more than one Emacs open anyway.

  (4) My current Emacs session tends to become buggy if I am in the
      process of hacking Emacs, and I don't want those bugs to affect
      other tasks I do with Emacs.

Re: New start up splash screen annoyance...

[Johannes Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 490 bytes --]

Hi,

On Tue, Sep 11, 2007 at 04:31:17PM -0400, Richard Stallman wrote:
> Over 20 years of Emacs experience shows that it is important to teach
> beginners to unlearn the habit of finding a file by typing `emacs FILE'.

When I came from other editors, `emacs FILE' was my first way to go.  But even
without anyone recommending me persistent Emacs sessions, I started to use
them, because they seemed more useful to ME.

But if people like to use Emacs the other way, why forbid it?

	Hannes

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: New start up splash screen annoyance...

[Robert J. Chassell]

    But if people like to use Emacs the other way, why forbid it?

The command `emacs FILE' is not forbidden; it is a bad habit.

By the way, David Kastrup's comments on Tramp are apropos:

    C-x C-f /sudo::FILE RET
    C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
    M-x cvs-examine RET /sudo::/ RET

I got into my habit of having a root instance of GNU Emacs before
Tramp was invented.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: New start up splash screen annoyance...

[Richard Stallman]

    But if people like to use Emacs the other way, why forbid it?

You're arguing against a straw man.  Nobody is trying to "forbid" this.

File name arguments did not implement themselves, you know;
I specifically wrote the code to implement them, even though I think
it's a bad habit.

However, the Emacs manual encourages people not to get into that bad
habit.

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 12 Sep 2007 14:52:31 -0400
> Cc: juri@jurta.org, wilde@sha-bang.de, cyd@stupidchicken.com,
> 	emacs-devel@gnu.org
> 
> File name arguments did not implement themselves, you know;
> I specifically wrote the code to implement them, even though I think
> it's a bad habit.
> 
> However, the Emacs manual encourages people not to get into that bad
> habit.

I think we should continue to discourage users from getting into this
habit.

But still, if the user did type "emacs FILE", it is IMO bad behavior
to show them the splash screen instead.  It looks like breaking the
contract with the users: they asked us to display the file, not the
splash screen.  The fact that the file is displayed in half the frame,
and the fact that there's a Dismiss button, don't help much, IMO.

There are a few other GUI programs out there which behave like this:
i.e. request me to click some button to make the splash screen go
away.  They always annoy me.

If we don't restore the original Emacs behavior of making the splash
screen go away (which I think we should), at least let's pop it up in
a separate frame, so that it doesn't get in the way of the file the
user asked to edit.

Re: New start up splash screen annoyance...

[Sascha Wilde]

Eli Zaretskii <eliz@gnu.org> wrote:
[...]
> If we don't restore the original Emacs behavior of making the splash
> screen go away (which I think we should), at least let's pop it up in
> a separate frame, so that it doesn't get in the way of the file the
> user asked to edit.

This won't help
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

Re: New start up splash screen annoyance...

[Sascha Wilde]

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

> Eli Zaretskii <eliz@gnu.org> wrote:
> [...]
>> If we don't restore the original Emacs behavior of making the splash
>> screen go away (which I think we should), at least let's pop it up in
>> a separate frame, so that it doesn't get in the way of the file the
>> user asked to edit.
>
> This won't help

...with ttys.

is the end of the sentence, which was lost because some strange
extraterrestrial force send this mail before it was finished...

sascha
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> Cc: rms@gnu.org, hannes@saeurebad.de, emacs-devel@gnu.org
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Thu, 13 Sep 2007 10:24:04 +0200
> 
> Sascha Wilde <wilde@sha-bang.de> wrote:
> 
> > Eli Zaretskii <eliz@gnu.org> wrote:
> > [...]
> >> If we don't restore the original Emacs behavior of making the splash
> >> screen go away (which I think we should), at least let's pop it up in
> >> a separate frame, so that it doesn't get in the way of the file the
> >> user asked to edit.
> >
> > This won't help
> 
> ...with ttys.

I wasn't talking about a tty.

Re: New start up splash screen annoyance...

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

> But still, if the user did type "emacs FILE", it is IMO bad behavior
> to show them the splash screen instead.  It looks like breaking the
> contract with the users: they asked us to display the file, not the
> splash screen.  The fact that the file is displayed in half the frame,
> and the fact that there's a Dismiss button, don't help much, IMO.

Agree 100%.

> There are a few other GUI programs out there which behave like this:
> i.e. request me to click some button to make the splash screen go
> away.  They always annoy me.

Me too -- it is typically those programs which ask you to register
(for no good reason).  I see no reason for Emacs to take that path.

A simple notice in the message area (it may fill more than one line)
when starting emacs with a file name (as someone suggested) seems
fully adequate IMO.

> If we don't restore the original Emacs behavior of making the splash
> screen go away (which I think we should), at least let's pop it up in
> a separate frame, so that it doesn't get in the way of the file the
> user asked to edit.

Only if it can automatically minimize and bury that frame :-)

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

Re: New start up splash screen annoyance...

[David Kastrup]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> If we don't restore the original Emacs behavior of making the
>> splash screen go away (which I think we should), at least let's pop
>> it up in a separate frame, so that it doesn't get in the way of the
>> file the user asked to edit.
>
> Only if it can automatically minimize and bury that frame :-)

We could put it in a tooltip (including a link to the splash screen)
over the initially displayed window area.  Since it is pretty much
impossible to get the mouse onto a link in a tooltip, the user will
feel _euphoric_ if he finally manages actually getting to the splash
screen itself.  Which is the right mood for perusing it.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Richard Stallman]

    If we don't restore the original Emacs behavior of making the splash
    screen go away (which I think we should), at least let's pop it up in
    a separate frame, so that it doesn't get in the way of the file the
    user asked to edit.

I don't necessarily object to popping up two frames, on a window
system where it is possible.

Re: New start up splash screen annoyance...

[Mathias Dahl]

> But still, if the user did type "emacs FILE", it is IMO bad behavior
> to show them the splash screen instead.  It looks like breaking the
> contract with the users: they asked us to display the file, not the
> splash screen.

I agree, as a new user I think I would be very confused by this behavior.

Re: New start up splash screen annoyance...

[Romain Francoise]

Eli Zaretskii <eliz@gnu.org> writes:

> But still, if the user did type "emacs FILE", it is IMO bad
> behavior to show them the splash screen instead.  It looks like
> breaking the contract with the users: they asked us to display the
> file, not the splash screen.

Yeah.  When I first made Emacs 22 available in Debian, I got lots of
reports from users who thought that it was a bug that Emacs showed
the splash screen instead of their file.  At some point I even
considered changing the default value of `inhibit-splash-screen' to
avoid getting those reports (but I didn't).

Re: New start up splash screen annoyance...

[Juri Linkov]

> File name arguments did not implement themselves, you know;
> I specifically wrote the code to implement them, even though I think
> it's a bad habit.
>
> However, the Emacs manual encourages people not to get into that bad habit.

There are cases where starting Emacs with a file name command line argument
is fully justified: for instance, logging into a remote computer only to
fix one config file.  Many users preferred using vi for such tasks because
vi was faster to start.  However, on modern hardware emacs startup time is
comparable to vi.  The only drawback Emacs has for such scenarios is that
unlike vi, Emacs displays the annoying startup screen instead of the
requested file.  After replacing the Emacs startup screen with a message
saying how to get more help, we can win more vi users!

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

Re: New start up splash screen annoyance...

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> File name arguments did not implement themselves, you know;
>> I specifically wrote the code to implement them, even though I think
>> it's a bad habit.
>>
>> However, the Emacs manual encourages people not to get into that bad habit.
>
> There are cases where starting Emacs with a file name command line
> argument is fully justified: for instance, logging into a remote
> computer only to fix one config file.

One can do this using tramp, but then I think prescribing a single
work style and making everything else inconvenient by design is a
mistake.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Romain Francoise]

David Kastrup <dak@gnu.org> writes:

>> There are cases where starting Emacs with a file name command line
>> argument is fully justified: for instance, logging into a remote
>> computer only to fix one config file.

> One can do this using tramp [...]

Tramp is very, very slow to find the first remote file because it
has to setup the communication channel between Emacs and the remote
host.  In the time Tramp takes to find the file, I can ssh into the
box and start a local Emacs several times over.  (Tramp 2.1 is much
better than Tramp 2.0 in this regard, but it's still not perfect.)

Re: New start up splash screen annoyance...

[Bill Wohler]

David Kastrup <dak@gnu.org> writes:

> Juri Linkov <juri@jurta.org> writes:
>
>>> File name arguments did not implement themselves, you know;
>>> I specifically wrote the code to implement them, even though I think
>>> it's a bad habit.
>>>
>>> However, the Emacs manual encourages people not to get into that bad habit.
>>
>> There are cases where starting Emacs with a file name command line
>> argument is fully justified: for instance, logging into a remote
>> computer only to fix one config file.
>
> One can do this using tramp, but then I think prescribing a single
> work style and making everything else inconvenient by design is a
> mistake.

Thanks, I agree.

In addition, I'm finding that TRAMP isn't there yet. I spent about 30
minutes yesterday trying to figure out a multi-hop method since I had
to log into a remote host as myself and su to a non-root user. I
finally threw up my hands and ran "emacs file" on the remote machine
and made my change in 2 seconds.

I'll be making a bug report; nonetheless, not everything is a nail.

p.s. I mentioned earlier that "M-x svn-status RET /sudo::/" viewed my
home directory rather than / as root. Would this be a bug in psvn or
in TRAMP?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: New start up splash screen annoyance...

[Stefan Monnier]

> p.s. I mentioned earlier that "M-x svn-status RET /sudo::/" viewed my
> home directory rather than / as root. Would this be a bug in psvn or
> in TRAMP?

I'd guess it's just that psvn has not been written to take advantage of the
new process-file and start-file-process functions, introduced in Emacs-22.1
and into which Tramp hooks to try and support those situations.

Similarly pcvs.el hasn't been updated either.


        Stefan

Re: New start up splash screen annoyance...

[Bill Wohler]

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

> > p.s. I mentioned earlier that "M-x svn-status RET /sudo::/" viewed my
> > home directory rather than / as root. Would this be a bug in psvn or
> > in TRAMP?
> 
> I'd guess it's just that psvn has not been written to take advantage of the
> new process-file and start-file-process functions, introduced in Emacs-22.1
> and into which Tramp hooks to try and support those situations.
> 
> Similarly pcvs.el hasn't been updated either.

Thanks Stefan, I'll let Stefan Reichor know so he can update psvn.

I imagine your note suffices as a bug report to an owner of pcvs that it
needs a Tramp update ;-).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: New start up splash screen annoyance...

[Michael Albinus]

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

> I'd guess it's just that psvn has not been written to take advantage of the
> new process-file and start-file-process functions, introduced in Emacs-22.1
> and into which Tramp hooks to try and support those situations.

start-file-process has been introduced in the trunk only. I don't know
of plans for backporting it to EMACS_22_BASE. It would also require to
replace Tramp 2.0 by 2.1 there.

>         Stefan

Best regards, Michael.

Re: New start up splash screen annoyance...

[Stefan Monnier]

>> I'd guess it's just that psvn has not been written to take advantage of the
>> new process-file and start-file-process functions, introduced in Emacs-22.1
>> and into which Tramp hooks to try and support those situations.

> start-file-process has been introduced in the trunk only. I don't know
> of plans for backporting it to EMACS_22_BASE. It would also require to
> replace Tramp 2.0 by 2.1 there.

Indeed, that's what I noticed when I tried the patch to pcvs.el on the
22 branch.  Luckily I tried it *before* committing, so I only committed the
change to the trunk.  ;-)


        Stefan

Re: New start up splash screen annoyance...

[Richard Stallman]

    start-file-process has been introduced in the trunk only. I don't know
    of plans for backporting it to EMACS_22_BASE. It would also require to
    replace Tramp 2.0 by 2.1 there.

I don't want to put those changes into Emacs 22.2.  We need to aim
for a release soon.

Please, people, fix the Emacs 22 bugs so we can start pretesting Emacs
22.2.

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 14 Sep 2007 02:43:51 +0300
> Cc: wilde@sha-bang.de, hannes@saeurebad.de, emacs-devel@gnu.org
> 
> There are cases where starting Emacs with a file name command line argument
> is fully justified: for instance, logging into a remote computer only to
> fix one config file.

I think, on a tty, Emacs ought not to display the splash screen if a
file argument was given to it.  Newbies will seldom use Emacs on a
character terminal anyway.

For a window system, I already suggested to pop the splash screen in a
separate frame, preferably smaller than the standard frame
dimensions.  Many GUI programs do that, so this won't come as a
surprise for newbies.

Re: New start up splash screen annoyance...

[Richard Stallman]

    I think, on a tty, Emacs ought not to display the splash screen if a
    file argument was given to it.  Newbies will seldom use Emacs on a
    character terminal anyway.

Maybe that is a valid point.

Re: New start up splash screen annoyance...

[Richard Stallman]

    There are cases where starting Emacs with a file name command line argument
    is fully justified: for instance, logging into a remote computer only to
    fix one config file.  Many users preferred using vi for such tasks because
    vi was faster to start.  However, on modern hardware emacs startup time is
    comparable to vi.

When I want to do this, I start Emacs and then visit the file.
What's the advantage of specifying the file name as a command arg?

Re: New start up splash screen annoyance...

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> When I want to do this, I start Emacs and then visit the file.
> What's the advantage of specifying the file name as a command arg?

It's a common usage pattern for me when doing sysadmin tasks.

For instance, I'll be looking for something in a config file, like this:

# grep foo /etc/apache/httpd.conf

I find that that's what I'm looking for, and I type

# emacs M-.

which will insert the previous parameter (i.e., the path name), and I
edit away.  Starting Emacs without a parameter would require me to type
the file name path again, which is slower.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New start up splash screen annoyance...

[Richard Stallman]

    # grep foo /etc/apache/httpd.conf

    I find that that's what I'm looking for, and I type

    # emacs M-.

That is something an advanced user will do occasionally.
Advanced users can easily turn off the splash screen.

(I didn't know about the shell key M-.  I expect to use it,
tho not for invoking Emacs.)

There are nonetheless beginners who habitually run Emacs with a file
name argument, and would never see the splash screen if it only
appeared with no argument.  The reason I made that change is that
I discovered this phenomenon.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     # grep foo /etc/apache/httpd.conf
>
>     I find that that's what I'm looking for, and I type
>
>     # emacs M-.
>
> That is something an advanced user will do occasionally.
> Advanced users can easily turn off the splash screen.

Advanced shell users are not automatically advanced Emacs users.

> (I didn't know about the shell key M-.  I expect to use it,
> tho not for invoking Emacs.)
>
> There are nonetheless beginners who habitually run Emacs with a file
> name argument, and would never see the splash screen if it only
> appeared with no argument.  The reason I made that change is that I
> discovered this phenomenon.

That's why I proposed announcing it with a message or tooltip that
persists for a while but does not keep the user from actually working.

Anyway, I think we have more to gain from educating the people who
stick with Emacs (and thus will at one point of time get to see the
splash screen) rather than the people who try it a few times and then
give up in disgust.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    That's why I proposed announcing it with a message or tooltip that
    persists for a while but does not keep the user from actually working.

I don't think that's sufficient to reliably inform people,
because it is too indirect.

Someone suggested popping up two frames.  That seems worth
considering.

    Anyway, I think we have more to gain from educating the people who
    stick with Emacs (and thus will at one point of time get to see the
    splash screen) rather than the people who try it a few times and then
    give up in disgust.

Exaggerations like this just make me angry at you, which makes
me less inclined than normally to entertain changes you suggest.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     That's why I proposed announcing it with a message or tooltip that
>     persists for a while but does not keep the user from actually working.
>
> I don't think that's sufficient to reliably inform people,
> because it is too indirect.

If "reliably informs" means "make sure from the start that they can't
do anything useful before reading this and/or taking extra action" you
are right.  But that also means that nobody (not just newbies) can
start doing anything useful unobstructedly on a standard Emacs without
customization.

We don't want to have this degree of reliability.  It is bad, not good
for both the image of Emacs and the GNU project.

> Someone suggested popping up two frames.  That seems worth
> considering.
>
>     Anyway, I think we have more to gain from educating the people
>     who stick with Emacs (and thus will at one point of time get to
>     see the splash screen) rather than the people who try it a few
>     times and then give up in disgust.
>
> Exaggerations like this just make me angry at you, which makes me
> less inclined than normally to entertain changes you suggest.

Unfortunately, it isn't an exaggeration.  It is sad that when
everybody tells you the same that you think they must be exaggerating
or lying and that you will punish them by ignoring their input.

I know several vi aficionados who clearly said that they don't use
Emacs since whenever they tried it, it "screwed them over" and thus
they decided "they are just not an Emacs person".  At one time, the
"C-h for help" binding was the ultimate candidate for surprising
annoyance.

We really don't want to feed the prejudices in that manner: we have
come such a long way in the last few years.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    Unfortunately, it isn't an exaggeration.

You're taking a hostile tack which I consider unjust, so I will not
give weight to whatever is based on it.  You may as well not repeat
it.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Unfortunately, it isn't an exaggeration.
>
> You're taking a hostile tack which I consider unjust, so I will not
> give weight to whatever is based on it.  You may as well not repeat
> it.

Richard, you have accused about half a dozen different Emacs
contributors of hostility by now and have threatened a number of
things, from ignoring people to ominous warnings about actions you'll
take.  People are participating on Emacs development and discussing on
this list not for the purpose of annoying you and making Emacs and GNU
worse.

There is, as far as I can see, not a _single_ person apart from you on
this list who considers it a good idea to start Emacs with a splash
screen when one asks it to edit a file.  So we are trying to come up
with a way of achieving your goals that has the least negative impact
with regard to Emacs and GNU acceptance.  And it does not help when
you are threatening everybody who tries to help with the complicate
task of implementing your goals in a manner compatible to the needs of
Emacs users.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Leo]

On 2007-09-18 06:39 +0100, David Kastrup wrote:
> There is, as far as I can see, not a _single_ person apart from you on
> this list who considers it a good idea to start Emacs with a splash
> screen when one asks it to edit a file.

Really? I am surprised how freedom has been compromised in the realm of
Emacs.

I don't like the splash screen and I have never seen any text editor
that gets in the way of getting things done.

Don't make Emacs a political machine.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: New start up splash screen annoyance...

[David Kastrup]

Leo <sdl.web@gmail.com> writes:

> On 2007-09-18 06:39 +0100, David Kastrup wrote:
>> There is, as far as I can see, not a _single_ person apart from you on
>> this list who considers it a good idea to start Emacs with a splash
>> screen when one asks it to edit a file.
>
> Really? I am surprised how freedom has been compromised in the realm
> of Emacs.

Huh?  Everybody is free to edit or customize or change Emacs according
to his liking and distribute the result.  There is no compromise of
freedom involved here.

Instead, we are trying to find a consensus for a common Emacs in order
to make it easier for users to pick one Emacs and stay with it.
Whether or not we manage to find consensus does not impact freedom: it
just would be a good thing since it makes us stronger when we are
united, and when the users see themselves able to appreciate our
goals.

> I don't like the splash screen and I have never seen any text editor
> that gets in the way of getting things done.

Well, vi's habit of starting in edit mode rather than insertion mode
could be called that...

> Don't make Emacs a political machine.

Emacs is part of the GNU project, and the GNU project has political
goals.  Emacs has always been a political statement as well as an
editor, and there is no reason to change that.  I certainly concur
with Richard that the GNU project's message is important, and that
Emacs is appropriate for conveying this message.

Where I am in strong disagreement with him is what kind of technical
measures might not rather harm than promote our goals by alienating
the users.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     Unfortunately, it isn't an exaggeration.
>>
>> You're taking a hostile tack which I consider unjust, so I will not
>> give weight to whatever is based on it.  You may as well not repeat
>> it.
>
> Richard, you have accused about half a dozen different Emacs
> contributors of hostility by now and have threatened a number of
> things, from ignoring people to ominous warnings about actions you'll
> take.  People are participating on Emacs development and discussing on
> this list not for the purpose of annoying you and making Emacs and GNU
> worse.
>
> There is, as far as I can see, not a _single_ person apart from you on
> this list who considers it a good idea to start Emacs with a splash
> screen when one asks it to edit a file.  So we are trying to come up
> with a way of achieving your goals that has the least negative impact
> with regard to Emacs and GNU acceptance.  And it does not help when
> you are threatening everybody who tries to help with the complicate
> task of implementing your goals in a manner compatible to the needs of
> Emacs users.

Well said!  And no hostility intended!

I still don't see why we cannot simply output a (possibly rather
verbose) message in the echo area when emacs is started with a file
name arg.  

Such a message disappears automatically on the first key-press, so
even though some users may still find it annoying, it doesn't get in
the way of editing the file.

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

Re: New start up splash screen annoyance...

[David Kastrup]

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

> I still don't see why we cannot simply output a (possibly rather
> verbose) message in the echo area when emacs is started with a file
> name arg.  
>
> Such a message disappears automatically on the first key-press, so
> even though some users may still find it annoying, it doesn't get in
> the way of editing the file.

It would likely need to be somewhat more persistent: I know that
Debian Emacsen will usually output messages when loading additionally
installed Emacs packages which would likely clear out the echo area
message.  But maybe there is a point in the load order where we can
place the message in a manner where it will persist reasonably well.

In case this is not reliable, I had proposed two different ways of
working around this (which both more or less got lost in the heat).

a) use an idle hook (triggered on 5 seconds of idleness) that will
replace the echo area message with the pointer as long as fewer than
30 seconds have passed (that would presumably help against autoload
messages and/or garbage-collect messages and/or autosave messages).

b) put a tooltip overlay for 30 seconds over the whole buffer that
ends up being displayed, or something equivalent.

Tooltips are designed to be displayed in a manner that does not
obstruct editing, so it might make sense to use the user interface
intelligence (and developer fallout) that already went into promoting
information without annoyance.

In either case, we'll need a handy shortcut for the About screen
(which is not yet there), and f1 C-a seems reasonable.

So to get a reliable non-obtrusive pointer to the splash screen for
the case of starting with a filename, there is certainly some code to
be written and tested.  Discussing this proves to be hard at the
moment.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Glenn Morris]

David Kastrup wrote:

> a) use an idle hook (triggered on 5 seconds of idleness) that will
> replace the echo area message with the pointer as long as fewer than
> 30 seconds have passed (that would presumably help against autoload
> messages and/or garbage-collect messages and/or autosave messages).

The VM mail reader does something like this. I've never found it
obtrusive, and it has actually made me notice the message, many times.
If it were a splash screen thing, I'd have turned it off ages ago.

Re: New start up splash screen annoyance...

[Richard Stallman]

I don't think an echo area message can do the job, because there
is not enough room.  An extra level of indirection would be far
less effective.

The idea of popping up two frames seems worth trying.
Would someone like to try it?

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I don't think an echo area message can do the job, because there
> is not enough room.  An extra level of indirection would be far
> less effective.

I completely agree that this is far less effective, and it is so by
design: it leaves the decision of when to peruse the startup screen to
the user when the user starts Emacs with a command line.  If we grant
that reducing effectiveness to this level (which hopefully is
acceptable to most people) might be appropriate (and I strongly think
it is), we can think about how to replace

!) make sure that the user can't avoid getting a splash screen,
against his explicit wish to start editing a particular file

with the following:

a) make sure that the user will be aware of the startup screen and
certain how to get it
b) make it obvious to the user that it would be in his best interest to
peruse it if he has not already done so.

I believe that we can achieve this with either a somewhat persistent
echo area message or a tooltip popup, either timed for about 30
seconds.  We use such echo area messages for teaching keybindings, and
they are effective for that purpose.  We use tooltips for conveying a
number of other information, and they also are doing a reasonably good
job without being annoying.

> The idea of popping up two frames seems worth trying.
> Would someone like to try it?

Tooltips are frames designed to be unobtrusive but noticeable, so it
would be a good idea to use them.  However, the splash screen would be
too large for a tooltip, and links would not be followable in a
tooltip, and it is a bit too ephemeral for such a bunch of
information.  So while we already have an interface for an information
popup, it would be appropriate to use another indirection level when
using it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    I completely agree that this is far less effective, and it is so by
    design:

They you know I won't do it.

Re: New start up splash screen annoyance...

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I don't think an echo area message can do the job, because there
> is not enough room. 

Really?  Something like this would be quite sufficient IMVHO.

(if menu-bar-mode
    (message
"Welcome to GNU Emacs, one component of the GNU/Linux system.
Please view \"About Emacs\" and \"About GNU\" on the Help menu.

Use the Help menu to try out the Emacs Tutorial, view the Emacs Manuals,
copying instructions, how to order printed copies of manuals and much more.

GNU Emacs comes with ABSOLUTELY NO WARRANTY.  See Help > (Non)Warranty.

To quit a partially entered command, type Control-g.  
Use Control-x Control-c To exit Emacs")
  (message
"Welcome to GNU Emacs, one component of the GNU/Linux system.
Type Control-g to quit a command.  Control-x Control-c to Exit.

Type C-h C-t to try out the Emacs Tutorial, C-h r to view the Emacs Manuals,
C-h C-h for a list of other help topics including copying instructions
and how to order printed copies of manuals.

GNU Emacs comes with ABSOLUTELY NO WARRANTY.  See C-h C-w."))

> An extra level of indirection would be far
> less effective.

I don't follow.

> The idea of popping up two frames seems worth trying.
> Would someone like to try it?

I would find that exteremely annoying.  
And I don't see how it can work with -nw mode.

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

Re: New start up splash screen annoyance...

[David Kastrup]

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

> Richard Stallman <rms@gnu.org> writes:
>
>> I don't think an echo area message can do the job, because there
>> is not enough room. 
>
> Really?  Something like this would be quite sufficient IMVHO.
>
> (if menu-bar-mode
>     (message
> "Welcome to GNU Emacs, one component of the GNU/Linux system.
> Please view \"About Emacs\" and \"About GNU\" on the Help menu.
>
> Use the Help menu to try out the Emacs Tutorial, view the Emacs Manuals,
> copying instructions, how to order printed copies of manuals and much more.
>
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.  See Help > (Non)Warranty.
>
> To quit a partially entered command, type Control-g.  
> Use Control-x Control-c To exit Emacs")
>   (message
> "Welcome to GNU Emacs, one component of the GNU/Linux system.
> Type Control-g to quit a command.  Control-x Control-c to Exit.
>
> Type C-h C-t to try out the Emacs Tutorial, C-h r to view the Emacs Manuals,
> C-h C-h for a list of other help topics including copying instructions
> and how to order printed copies of manuals.
>
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.  See C-h C-w."))
>
>> An extra level of indirection would be far
>> less effective.
>
> I don't follow.

My suggestion was to use something like

(message "Type f1 C-a for important information about Emacs and the GNU project")

(or a tooltip), just more persistent than message ordinarily is.  That
would be the added level at indirection.

>> The idea of popping up two frames seems worth trying.
>> Would someone like to try it?
>
> I would find that exteremely annoying.  
> And I don't see how it can work with -nw mode.

I don't think that a large "message" will do the trick: it will
disappear too easily, and if one would instead force it to stay around
for 30 seconds or so, again, it would be quite annoying.

I agree that it would be less obnoxious than the current variant, but
I think it is more annoying than necessary when one does not want the
information, while it is less reliable when one wants it.

I have my doubts that this discrepance can be resolved really
satisfactorily without what Richard calls "an extra level of
indirection".

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Stephen J. Turnbull]

David Kastrup writes:

 > I don't think that a large "message" will do the trick: it will
 > disappear too easily, and if one would instead force it to stay around
 > for 30 seconds or so, again, it would be quite annoying.
 > 
 > I agree that it would be less obnoxious than the current variant, but
 > I think it is more annoying than necessary when one does not want the
 > information, while it is less reliable when one wants it.

You could combine the two approaches, with a large message at startup
and a one- or two-liner that persists for 30 seconds.

Re: New start up splash screen annoyance...

[Stefan Monnier]

> I still don't see why we cannot simply output a (possibly rather
> verbose) message in the echo area when emacs is started with a file
> name arg.

I'd be willing to live with a split screen:
- without any option, show the full startup screen, of course: there's no
  disagreement on this, AFAIK.
- with a file option (or some other related option such as "-f gnus"), do
  show the file, but show also an extra startup screen in
  a separate window.  Since the normal startup screen takes up too much
  space for this use, we'd need a shorter version of the startup screen with
  a button that you click to say "show me the full screen".

It's a lot more obstructive than the echo-area version, so Richard would
probably prefer it (I'd prefer the echo-area version).


        Stefan

Re: New start up splash screen annoyance...

[Mathias Dahl]

> I'd be willing to live with a split screen:
> - without any option, show the full startup screen, of course: there's no
>   disagreement on this, AFAIK.
> - with a file option (or some other related option such as "-f gnus"), do
>   show the file, but show also an extra startup screen in
>   a separate window.  Since the normal startup screen takes up too much
>   space for this use, we'd need a shorter version of the startup screen with
>   a button that you click to say "show me the full screen".

I thought about this as well and I would also accept it. Having the
"splash-window" a bit smaller would make it less intrusive but still
very visible.

I think I would also be OK with the idle-timer + echo area message idea.

Personally I now mostly start emacs with -Q those times when I want to
make a super quick edit and don't have an instance already running
(starting up with my .emacs takes quite a long time).

Re: New start up splash screen annoyance...

[Richard Stallman]

    Richard, you have accused about half a dozen different Emacs
    contributors of hostility by now and have threatened a number of
    things, from ignoring people to ominous warnings about actions you'll
    take.

I do not take kindly to insults, so if you try to make me change
my mind by insulting me, I won't.

To make an argument which incorporates a premise that I've already
said I think is wrong is not useful as an argument.  So if you keep
repeating such arguments, I can only interpret this as an attempt to
bully me.  I won't give in to bullying, so you may as well stop it.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Richard, you have accused about half a dozen different Emacs
>     contributors of hostility by now and have threatened a number of
>     things, from ignoring people to ominous warnings about actions you'll
>     take.
>
> I do not take kindly to insults, so if you try to make me change
> my mind by insulting me, I won't.

Do you want me to support the above statement with quotes?  I wish I
couldn't.

> To make an argument which incorporates a premise that I've already
> said I think is wrong is not useful as an argument.  So if you keep
> repeating such arguments, I can only interpret this as an attempt to
> bully me.  I won't give in to bullying, so you may as well stop it.

How can I bully someone who has the absolute power of decision and
makes use of it?  At most I can annoy you.  While it is obvious that I
indeed annoy you, it is a consequence rather than the purpose of our
difference, and you can rest assured that this annoyance is quite
mutual.  Neither of us can help feeling strongly about this issue it
would appear.  And it is not encouraging that there is no feedback
about the technical solutions I am proposing in order to address your
concerns.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> To make an argument which incorporates a premise that I've already
> said I think is wrong is not useful as an argument.  So if you keep
> repeating such arguments, I can only interpret this as an attempt to
> bully me.  I won't give in to bullying, so you may as well stop it.

Richard, we all want what's best for Emacs.  We all love Emacs and want
it to be The Editor.  Please don't interpret our arguments for or
against a particular change as "bullying".

Anyway, here's another data point: On our site, we use Emacs as the
default editor when editing crontabs.

When we say

$ crontab -e

we get an Emacs that's been started with a file name as an argument.
This now displays the splash screen instead of the crontab.  I don't
think that's an optimal way for Emacs to behave.

Is your mind made up that this is the way Emacs must behave, or are
there any arguments that might change your mind?

At least, with "emacs -nw" (as the crontab thing is called), it seems
counter productive to show the splash screen, in my opinion.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New start up splash screen annoyance...

[Richard Stallman]

    Is your mind made up that this is the way Emacs must behave, or are
    there any arguments that might change your mind?

My mind is made up that we must arrange that beginners who always
specify a file name argument mostly do see the splash screen
information.  I'm willing to consider other ways of doing that
as long as I think they are effective.

    At least, with "emacs -nw" (as the crontab thing is called), it seems
    counter productive to show the splash screen, in my opinion.

I expect beginners mainly use window systems, so showing the splash
screen in the tty case is not so important.  Thus, I don't mind if we
don't show the splash screen when starting Emacs with file name
arguments on a tty.

Re: New start up splash screen annoyance...

[Juri Linkov]

> My mind is made up that we must arrange that beginners who always
> specify a file name argument mostly do see the splash screen
> information.  I'm willing to consider other ways of doing that
> as long as I think they are effective.

The least obtrusive way to show the important information for beginners is
using the echo area message.  It is quite reliable channel if we take
precautions against overriding it with other messages (e.g. displaying it
at the final stage of startup).  A large message, as Kim suggested,
can't go unnoticed.  And clicking on it would display the full startup
screen.

>     At least, with "emacs -nw" (as the crontab thing is called), it seems
>     counter productive to show the splash screen, in my opinion.
>
> I expect beginners mainly use window systems, so showing the splash
> screen in the tty case is not so important.  Thus, I don't mind if we
> don't show the splash screen when starting Emacs with file name
> arguments on a tty.

In this case it would be better to display a different startup echo area
message when starting Emacs with file name arguments on a tty.  Instead of

For information about the GNU system and GNU/Linux, type C-h C-p.

display

For information about Emacs and the GNU Project, type C-h C-a.

as David suggested, because the About screen provides more additional
information than C-h C-p (and it includes a reference to the C-h C-p
info about the GNU project).

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

Re: New start up splash screen annoyance...

[Leo]

On 2007-09-20 00:46 +0100, Juri Linkov wrote:
>> My mind is made up that we must arrange that beginners who always
>> specify a file name argument mostly do see the splash screen
>> information.  I'm willing to consider other ways of doing that
>> as long as I think they are effective.
>
> The least obtrusive way to show the important information for beginners is
> using the echo area message.  It is quite reliable channel if we take
> precautions against overriding it with other messages (e.g. displaying it
> at the final stage of startup).  A large message, as Kim suggested,
> can't go unnoticed.  And clicking on it would display the full startup
> screen.

Back in the days when I was using proprietary software, I usually needed
to purchase a license to stop it from popping up a startup screen. It
would be helpful if we can do the same.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: New start up splash screen annoyance...

[Richard Stallman]

    The least obtrusive way to show the important information for beginners is
    using the echo area message.

I believe you, but that is not my goal.

Re: New start up splash screen annoyance...

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Is your mind made up that this is the way Emacs must behave, or are
>     there any arguments that might change your mind?
>
> My mind is made up that we must arrange that beginners who always
> specify a file name argument mostly do see the splash screen
> information.  

I'm all in favour of the intentions behind this decision, but my fear
is that making it too intrusive (i.e. annoying) will cause many
sysadmins and even makers of "Linux distributions" (as they
incorrectly call themselves) to simply turn off the splash-screen
altogether for _all_ users.

AFAICS, the only thing we can do to prevent that is to find a
reasonably non-annoying way to "say what we want to say".


> I expect beginners mainly use window systems, so showing the splash
> screen in the tty case is not so important.  Thus, I don't mind if we
> don't show the splash screen when starting Emacs with file name
> arguments on a tty.

Can you clarify that statement, please!

So are you saying that it is now ok to _not_ show the
splash screen when starting emacs -nw FILENAME ??


In my mind, starting emacs in a Linux Console, and starting emacs -nw
in an xterm all amounts to "starting emacs from a tty".  

For most practical uses, that's really the only way to start a
non-window emacs with a file name argument.

On a window system you typically click on a file to edit it - so (as
you say) that will typically launch a graphical emacs (which should
of course show the splash screen - in some form or another).

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

Re: New start up splash screen annoyance...

[Stefan Monnier]

How 'bout the following:

- try and display the startup buffer while starting up (i.e. display it as
  early as possible, before the .emacs and most of the arguments are
  processed.  Might not be easy to do, I agree).
- if there was a filename given, keep displaying the startup buffer for, say,
  2 seconds: not enough for someone to read it, but enough to recognize it
  as a splash screen.
- then display a "persistent" message in the echo-area about how to get back
  to the startup buffer.

In any case, I feel like a lot of the discussion here has to do with the
fact that until now almost noone ever bothered to turn off the startup
buffer in their .emacs, whereas now it will be indispensible for a regular
user to explicitly turn it off for the obvious mental health reasons.


        Stefan

Re: New start up splash screen annoyance...

[dhruva]

Hi,
 I have another idea (might be considered crazy...) Is it possible to
have something like a screen saver. On some duration of inactivity,
bring up a buffer with all the required information. When there is
mouse/keyboard activity, restore the previous active buffer. In this
way, we make the information visible in a rather non intrusive manner.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: New start up splash screen annoyance...

[Davis Herring]

>  I have another idea (might be considered crazy...) Is it possible to
> have something like a screen saver. On some duration of inactivity,
> bring up a buffer with all the required information. When there is
> mouse/keyboard activity, restore the previous active buffer. In this
> way, we make the information visible in a rather non intrusive manner.

It could be a new zone mode:
zone-gradually-replace-text-with-emacs-splash-screen

And users would have to sit through most of the transformation before they
could reliably read the instruction to dismiss it with M-x
zone-leave-me-alone... it's perfect!

Davis

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

Re: New start up splash screen annoyance...

[Bastien]

"Davis Herring" <herring@lanl.gov> writes:

>>  I have another idea (might be considered crazy...) Is it possible to
>> have something like a screen saver. On some duration of inactivity,

It would require this duration of inactivity to be very little so that
the relevant information are displayed as soon as possible.

> It could be a new zone mode:
> zone-gradually-replace-text-with-emacs-splash-screen

Hey, this is fun. But I think it doesn't solve the general problem of
the information Emacs has to display at *startup*.

-- 
Bastien

Re: New start up splash screen annoyance...

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

>  I have another idea (might be considered crazy...) Is it possible
> to have something like a screen saver. On some duration of
> inactivity, bring up a buffer with all the required
> information. When there is mouse/keyboard activity, restore the
> previous active buffer. In this way, we make the information visible
> in a rather non intrusive manner.

If the "screen saver interval" for Emacs is larger than for the
system, this might never get seen.  It is also exactly the wrong
mechanism to use for presenting information that is intended to help
people start operating Emacs.  And a large part of the splash screen
is intended to provide this kind of information.

Supplementary information about the GNU project and stuff could be
presented in this manner, and if the splash screen is shown as a
_reminder_ in this way that might also be tolerable.  But in any case,
the objective was that a user would unintentionally never get to know
about the splash screen when always starting Emacs with a file name.
And a screen-saver like method does not seem to be the best way.

In particular since _if_ the user is interested in the splash screen
links, clicking on them would not work (since the "screen saver" would
revert back to the original window content).

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Bastien]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> - if there was a filename given, keep displaying the startup buffer
>   for, say, 2 seconds: not enough for someone to read it, but enough
>   to recognize it as a splash screen.

I don't think having a non-readable startup buffer would help, even if
the new user is able to recognize it as a startup buffer.

> - then display a "persistent" message in the echo-area about how to
>   get back to the startup buffer.

I like the persistent message in the echo-area solution *very much*.

We could also consider having *several messages*, each of them being
displayed for a few seconds (say 2).

It is the best trade-off I can think of:

- it lets Emacs display a file when given as an argument;
- it lets Emacs display *all* the information you want;
- it catches the attention of the new users more efficiently.

-- 
Bastien

Re: New start up splash screen annoyance...

[Bastien]

Bastien <bzg@altern.org> writes:

> We could also consider having *several messages*, each of them being
> displayed for a few seconds (say 2).
>
> It is the best trade-off I can think of:
>
> - it lets Emacs display a file when given as an argument;
> - it lets Emacs display *all* the information you want;
> - it catches the attention of the new users more efficiently.

Does anyone here agree that *several* echo-area messages, persistently
displayed one by one at a small time interval, would catch beginners
attention more efficiently than the current static buffer solution ?

-- 
Bastien

RE: New start up splash screen annoyance...

[Drew Adams]

> > We could also consider having *several messages*, each of them being
> > displayed for a few seconds (say 2).
> >
> > It is the best trade-off I can think of:
> >
> > - it lets Emacs display a file when given as an argument;
> > - it lets Emacs display *all* the information you want;
> > - it catches the attention of the new users more efficiently.
>
> Does anyone here agree that *several* echo-area messages,
> persistently displayed one by one at a small time interval,
> would catch beginners attention more efficiently than the
> current static buffer solution ?

B
u
r
m
a

S
h
a
v
e
!

Yes!

Criss-cross the globe with tiny Emacs-noob GNU ads every few kilometers.

Raise swarms of balloons and blimps (hot-air, naturally) showing sparkling,
flashing mission statements, household tips, and other useful GNU reminders.
Drones and nano-copters too, indoors and out.

Paint barns, sky write, and drape bunting to celebrate: "The new GNU Emacs
is here!", "Le nouveau GNU Emacs est arrive!", and "Surrender Dorothy!".
(oops?)

GNU satellites orbiting our everwarming Mother Earth, beaming "Welcome!"
messages every few minutes to text-messaging teenie noobs and helpful NEWS
updates to their TeX-massaging forbears.

Marching bands and pop singers to visit every village and proclaim proudly
"GNUness Is GOOD For You", "GNU The Beautiful", "Onward GNUian Soldiers!",
"GNU Is Great", "There is Only One GNU, and Its Name Is GNU", and of course
(our anthem) "GNU Is Not UNIX". (UNIX? What's that?)

Instead of an ordinary checkbox to "See this nevermore" (too easy!), let 'em
wander the Info Desert without water in search of   h o w   t o   t u r n
i t   o f f.

That'll teach 'em to quickly come of age and metamorphose out of their
larval noobness. Only the first of many holy GNU grails: Try to banish the
splash! Just try it. And certainly not a hint about it in the Tutorial.

For ex-noobs, proud bumper stickers: "I banished it", "I survived the
Splash!", "I GNU I could do it", "My child is an honor Emacs ex-noob", and
"Emacs ex-noob on board".

Do we have an award for the longest (and splashiest) emacs-devel thread? How
long can we keep this one going? Don't break the chain, or bad luck will be
visited upon you.

Re: New start up splash screen annoyance...

[Sean Sieger]

   Do we have an award for the longest (and splashiest) emacs-devel thread? How
   long can we keep this one going? Don't break the chain, or bad luck will be
   visited upon you.

Put another way, what this thread is covering up?

Re: New start up splash screen annoyance...

[Bastien]

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

> Criss-cross the globe with tiny Emacs-noob GNU ads every few
> kilometers.

Actually I'm quite glad my poor two-cents contribution provoked such a
priceless email - thanks for it!

-- 
Bastien

Re: New start up splash screen annoyance...

[Davis Herring]

> Does anyone here agree that *several* echo-area messages, persistently
> displayed one by one at a small time interval, would catch beginners
> attention more efficiently than the current static buffer solution ?

Hmm, perhaps you have a point.  When I think about that, I think of Burma
Shave:

Emacs is GNU
Emacs is free
Type f1 C-a
And you will see

But the idea is sound: perhaps for some 30 seconds or so the echo area
should default (as in after every keystroke) not to blank but to a message
of Richard's choosing.  This would probably be easy to implement at the C
level of clearing the echo area.

Davis

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

Re: New start up splash screen annoyance...

[Richard Stallman]

I don't think this should replace the splash screen,
and we have pretty much resolved the issue of the splash screen.
But it might be nice to display these four messages in the echo area
Burma Shave style.

    Emacs is GNU
    Emacs is free
    For more information
    Type C-h C-p

Re: New start up splash screen annoyance...

[Manoj Srivastava]

On Thu, 20 Sep 2007 13:16:16 +0200, Kim F Storm <storm@cua.dk> said: 

> Richard Stallman <rms@gnu.org> writes:
>> Is your mind made up that this is the way Emacs must behave, or are
>> there any arguments that might change your mind?
>> 
>> My mind is made up that we must arrange that beginners who always
>> specify a file name argument mostly do see the splash screen
>> information.

> I'm all in favour of the intentions behind this decision, but my fear
> is that making it too intrusive (i.e. annoying) will cause many
> sysadmins and even makers of "Linux distributions" (as they
> incorrectly call themselves) to simply turn off the splash-screen
> altogether for _all_ users.

> AFAICS, the only thing we can do to prevent that is to find a
> reasonably non-annoying way to "say what we want to say".

        I am not sure I understand this viewpoint. I have been using
 Emacs since '88, so I am pretty "seasoned" -- but I don't seem to see
 the issue you are raising; and I am wondering if we are looking at the
 same thing.

        What I saw was a splash screen -- but it came with a nice
 _dismiss_ button, and even a checkbox that said "don't show this
 again".  This is not much of an annoyance -- since it only ever appears
 once, and has an easy way to dismiss the screen.

        As someone who has influence with one of the much despised
 GNU/Linux distribution makers, I can say your fears are somewhat
 overblown.

        manoj
-- 
Testing can show the presense of bugs, but not their absence. Dijkstra
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: New start up splash screen annoyance...

[David Kastrup]

Manoj Srivastava <srivasta@ieee.org> writes:

> On Thu, 20 Sep 2007 13:16:16 +0200, Kim F Storm <storm@cua.dk> said: 
>
>> AFAICS, the only thing we can do to prevent that is to find a
>> reasonably non-annoying way to "say what we want to say".
>
>         I am not sure I understand this viewpoint. I have been using
>  Emacs since '88, so I am pretty "seasoned" -- but I don't seem to
>  see the issue you are raising; and I am wondering if we are looking
>  at the same thing.

Just to make sure we are: we are talking about the case where Emacs is
called with explicit file names given on the command line and instead
of displaying those files displays the splash screen.

>         What I saw was a splash screen -- but it came with a nice
>  _dismiss_ button, and even a checkbox that said "don't show this
>  again".  This is not much of an annoyance -- since it only ever appears
>  once,

Per session.

>  and has an easy way to dismiss the screen.

We are not talking about the case where Emacs is started without
explicit file name arguments: the current static splash screen
(including dismiss button) is the result of a lot of discussion.

We are talking about the case where you, for example, do
crontab -e
and get an Emacs splash screen as a reaction.

>         As someone who has influence with one of the much despised
>  GNU/Linux distribution makers, I can say your fears are somewhat
>  overblown.

As long as we are talking about the same thing.  Are we?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Sean O'Rourke]

David Kastrup <dak@gnu.org> writes:

> Manoj Srivastava <srivasta@ieee.org> writes:
>
>>         What I saw was a splash screen -- but it came with a nice
>>  _dismiss_ button, and even a checkbox that said "don't show this
>>  again".  This is not much of an annoyance -- since it only ever appears
>>  once,
>
> Per session.

I think Manoj's suggestion is to have a "never show me this
again" checkbox on the splash screen, UNchecked by default.  The
user can press "ok" to dismiss the screen until next time, or
check the box then press "ok" to disable it permanently.  If the
user later wants to see the screen again, s/he can re-enable it.

Many programs (e.g. Firefox, iTunes) seem to be adopting this
convention, and I think it works well: When moving to a new
machine, I am annoyed at most once by the warning dialogs I
normally disable.  Novice users seem not to check the boxes, and
continue to see all the warnings.

This method is simple, ensures that novices see the message,
minimally interferes with "emacs FILENAME" invocation by experts,
and is controlled by an explicit user action.  What's not to
like?

/s

Re: New start up splash screen annoyance...

[Glenn Morris]

"Sean O'Rourke" wrote:

> I think Manoj's suggestion is to have a "never show me this
> again" checkbox on the splash screen, UNchecked by default.  The
> user can press "ok" to dismiss the screen until next time, or
> check the box then press "ok" to disable it permanently.  If the
> user later wants to see the screen again, s/he can re-enable it.

Umm, that's exactly how it works now.

Re: New start up splash screen annoyance...

[Sean O'Rourke]

Glenn Morris <rgm@gnu.org> writes:

> "Sean O'Rourke" wrote:
>
>> I think Manoj's suggestion is to have a "never show me this
>> again" checkbox on the splash screen, UNchecked by default.  The
>> user can press "ok" to dismiss the screen until next time, or
>> check the box then press "ok" to disable it permanently.  If the
>> user later wants to see the screen again, s/he can re-enable it.
>
> Umm, that's exactly how it works now.

Not that I can see.  Are you talking about the "Customize
Startup" button, which brings up a 50-line customize buffer with
eight other sometimes-obscure startup options?  I meant something
much simpler: a single "dismiss" button, and a single "make it
permanent" checkbox, both on the startup screen itself.

/s

Re: New start up splash screen annoyance...

[Glenn Morris]

"Sean O'Rourke" wrote:

> Not that I can see.  Are you talking about the "Customize
> Startup" button, which brings up a 50-line customize buffer with
> eight other sometimes-obscure startup options?  I meant something
> much simpler: a single "dismiss" button, and a single "make it
> permanent" checkbox, both on the startup screen itself.

I should have said: for the fancy splash screen only, and provided
that Emacs was started with an init file.

(I always have to make emacs bigger than normal to get the fancy splash
screen:

emacs -geometry 80x40
)

Re: New start up splash screen annoyance...

[Juri Linkov]

>> Not that I can see.  Are you talking about the "Customize
>> Startup" button, which brings up a 50-line customize buffer with
>> eight other sometimes-obscure startup options?  I meant something
>> much simpler: a single "dismiss" button, and a single "make it
>> permanent" checkbox, both on the startup screen itself.
>
> I should have said: for the fancy splash screen only, and provided
> that Emacs was started with an init file.

I think it was a mistake to add a Dismiss checkbox on the startup screen.

I want to remind that the recent changes in startup.el were caused by the
incident when a famous writer lost his invaluable masterpiece because he
finished Emacs without saving text in the *scratch* buffer.  These changes
were intended to not show the *scratch* buffer after Emacs startup.

And now after three months of discussions and changes we returned to the
initial situation: the Dismiss button invites Emacs users to easily disable
the startup screen.  I'm sure almost every Emacs beginner will be tempted
to press it.  As a result, they will see the *scratch* buffer after startup,
and again will lose their texts typed in this buffer.

The *scratch* buffer is mostly intended for the seasoned Lisp hackers,
and should be shown on the startup only when explicitly configured by
the corresponding option to show the *scratch* buffer.  Ideally, starting
Emacs without command line arguments should display the startup screen
by default and without providing a checkbox to disable it, but starting
Emacs with file name arguments should display only the specified files.

I understand that adding the Dismiss checkbox was caused by the annoying
behavior of displaying the startup screen instead of files when starting
Emacs with file name arguments.  However, this is a completely separate case
and should be treated by different means.  Perhaps we should add a separate
user option to disable the startup screen only for the case of starting
Emacs with file name arguments, and to display the Dismiss button only
in this case (unless Richard will agree to some other less annoying way
of displaying the help information with file name arguments).

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

Re: New start up splash screen annoyance...

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> Not that I can see.  Are you talking about the "Customize
>>> Startup" button, which brings up a 50-line customize buffer with
>>> eight other sometimes-obscure startup options?  I meant something
>>> much simpler: a single "dismiss" button, and a single "make it
>>> permanent" checkbox, both on the startup screen itself.
>>
>> I should have said: for the fancy splash screen only, and provided
>> that Emacs was started with an init file.
>
> I think it was a mistake to add a Dismiss checkbox on the startup screen.
>
> I want to remind that the recent changes in startup.el were caused by the
> incident when a famous writer lost his invaluable masterpiece because he
> finished Emacs without saving text in the *scratch* buffer.  These changes
> were intended to not show the *scratch* buffer after Emacs startup.
>
> And now after three months of discussions and changes we returned to the
> initial situation: the Dismiss button invites Emacs users to easily disable
> the startup screen.  I'm sure almost every Emacs beginner will be tempted
> to press it.  As a result, they will see the *scratch* buffer after startup,
> and again will lose their texts typed in this buffer.

I have not checked the latest version but I agree that any "Dismiss in
future" should only affect the splash screen when file names are given
on the command line.

There is no reason for a beginner option to disable the splash screen
when started without file name.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Richard Stallman]

    I have not checked the latest version but I agree that any "Dismiss in
    future" should only affect the splash screen when file names are given
    on the command line.

I agree.  And the "don't show this in the future" should only be
shown when there are file name args.

Would someone please implement that?

Re: New start up splash screen annoyance...

[Juri Linkov]

>     I have not checked the latest version but I agree that any "Dismiss in
>     future" should only affect the splash screen when file names are given
>     on the command line.
>
> I agree.  And the "don't show this in the future" should only be
> shown when there are file name args.
>
> Would someone please implement that?

Done.

I also swapped two windows created after displaying the startup screen
in Emacs started with a file name, i.e. now when Emacs is started on
a window system with file name arguments, then the upper window displays
the last file specified on the command line, and the lower window displays
the concise version of the startup screen (without logo) plus the
"Dismiss" button and checkbox.  So the startup screen is less annoying now
but still is visible, not indirect and persistent.

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

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sat, 22 Sep 2007 17:11:59 +0300
> Cc: emacs-devel@gnu.org
> 
> >     I have not checked the latest version but I agree that any "Dismiss in
> >     future" should only affect the splash screen when file names are given
> >     on the command line.
> >
> > I agree.  And the "don't show this in the future" should only be
> > shown when there are file name args.
> >
> > Would someone please implement that?
> 
> Done.

What about the demonstration of concept in the patch below?  I think
popping the splash screen in a separate frame is superior to dividing
the initial frame, and doing so makes all kinds of complications with
"concise" splash screen and whether splash should be in upper or lower
window, a non-issue.  IIRC, Richard agreed to the idea of a separate
frame.

Note that the patch below is just a first unpolished cut; in
particular, it doesn't yet work well with the file arguments.  I just
wanted to see if people liked it, before inverting more work.

Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.460
diff -u -r1.460 startup.el
--- lisp/startup.el	22 Sep 2007 14:02:26 -0000	1.460
+++ lisp/startup.el	22 Sep 2007 18:05:19 -0000
@@ -1460,10 +1460,29 @@
   (interactive)
   (quit-window t))
 
+(defvar splash-frame-parameters
+  '((name . "GNU Emacs")
+    (top . 150)
+    (left . 200)
+    (height . 34)
+    (width . 64)
+    (user-position . t)
+    (vertical-scroll-bars . nil)
+    (menu-bar-lines . nil)
+    (tool-bar-lines . nil)
+    (left-fringe . 0)
+    (right-fringe . 0)
+    (minibuffer . nil)
+    (cursor-type . nil)
+    (unsplittable . t)
+    (auto-raise . t))
+  "Frame parameters used for splash screen.")
+
 (defun fancy-startup-screen (&optional concise)
   "Display fancy startup screen.
 If CONCISE is non-nil, display a concise version of the
 splash screen in another window."
+  (let ((splash-frame
   (with-current-buffer (get-buffer-create "*GNU Emacs*")
     (let ((inhibit-read-only t))
       (erase-buffer)
@@ -1485,13 +1504,17 @@
     (setq buffer-read-only t)
     (if (and view-read-only (not view-mode))
 	(view-mode-enter nil 'kill-buffer))
-    (goto-char (point-min)))
+    (goto-char (point-min))
+    (make-frame splash-frame-parameters))))
+    (select-frame splash-frame)
+    (setq mode-line-format nil)
+    (set-frame-height (1- (frame-height)))
   (if (or (window-minibuffer-p)
 	  (window-dedicated-p (selected-window)))
       (pop-to-buffer (current-buffer)))
   (if concise
       (display-buffer (get-buffer "*GNU Emacs*"))
-    (switch-to-buffer "*GNU Emacs*")))
+    (switch-to-buffer "*GNU Emacs*"))))
 
 (defun fancy-about-screen ()
   "Display fancy About screen."

Re: New start up splash screen annoyance...

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@jurta.org>
>> Date: Sat, 22 Sep 2007 17:11:59 +0300
>> Cc: emacs-devel@gnu.org
>> 
>> >     I have not checked the latest version but I agree that any "Dismiss in
>> >     future" should only affect the splash screen when file names are given
>> >     on the command line.
>> >
>> > I agree.  And the "don't show this in the future" should only be
>> > shown when there are file name args.
>> >
>> > Would someone please implement that?
>> 
>> Done.
>
> What about the demonstration of concept in the patch below?  I think
> popping the splash screen in a separate frame is superior to dividing
> the initial frame, and doing so makes all kinds of complications with
> "concise" splash screen and whether splash should be in upper or lower
> window, a non-issue.  IIRC, Richard agreed to the idea of a separate
> frame.

Two frames always imply a fight: the window manager will try to find
places for them and decide on how to focus them.  Getting a separate
window tamed is the matter of C-x 0 or C-x 1.  In contrast, C-x 5 0 or
C-x 5 1 will leave one with a window configuration that might be worse
than if just one frame would have been placed.

With my personal geometry settings, not more than one Emacs frame per
workspace is really usable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Stefan Monnier]

> Two frames always imply a fight: the window manager will try to find
> places for them and decide on how to focus them.  Getting a separate
> window tamed is the matter of C-x 0 or C-x 1.  In contrast, C-x 5 0 or
> C-x 5 1 will leave one with a window configuration that might be worse
> than if just one frame would have been placed.

From all the discussions I've ever had with Emacs beginners, the need to
learn and master window-manipulation is one of the main sources of
difficulty in Emacs: most of the rest can be done in typically obvious ways
(now that we have menus and that arrows are sufficiently standard that
almost nobody needs to first learn C-p, C-n).  But once you have
a split-window display, it's not straightforward to a newbie how to get back
to the single-window he's used to (the simplest way is probably "File ->
Remove Splits").  In contrast getting rid of a second frame is easy: just
click in the `X' in top corner of your window(frame).


        Stefan

Re: New start up splash screen annoyance...

[Juri Linkov]

> From all the discussions I've ever had with Emacs beginners, the need to
> learn and master window-manipulation is one of the main sources of
> difficulty in Emacs: most of the rest can be done in typically obvious ways
> (now that we have menus and that arrows are sufficiently standard that
> almost nobody needs to first learn C-p, C-n).  But once you have
> a split-window display, it's not straightforward to a newbie how to get back
> to the single-window he's used to (the simplest way is probably "File ->
> Remove Splits").  In contrast getting rid of a second frame is easy:
> just click in the `X' in top corner of your window(frame).

They don't need immediately to get back to the single-window
configuration.  They can start editing in the selected window
while the lower window is still visible.  This is a good opportunity
for beginners to get introduced to the concept of Emacs windows.
They can use mouse to set point to the startup window, and start
clicking mouse on links, and see the result.  Eventually, they
can click on the Tutorial link in the startup window, and learn
more about multiple windows.

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

RE: New start up splash screen annoyance...

[Drew Adams]

> They don't need immediately to get back to the single-window
> configuration.  They can start editing in the selected window
> while the lower window is still visible.  This is a good opportunity
> for beginners to get introduced to the concept of Emacs windows.
> They can use mouse to set point to the startup window, and start
> clicking mouse on links, and see the result.  Eventually, they
> can click on the Tutorial link in the startup window, and learn
> more about multiple windows.

As I said:

> let 'em wander the Info Desert without water in search of
> h o w   t o   t u r n   i t   o f f.
>
> That'll teach 'em to quickly come of age and metamorphose out of
> their larval noobness. Only the first of many holy GNU grails:
> Try to banish the splash! Just try it. And certainly not a hint
> about it in the Tutorial.

Of course I was only kidding. Now we've taken it to a whole new level,
rivaling Adventure (http://en.wikipedia.org/wiki/Adventure_game): Find the
tutorial and follow it until you graduate and you know how to come back and
remove the nag window. A "good opportunity", indeed. Of course there's a
risk that a few new users might just go postal...

Keep it up; this is entertaining (and it's bad luck to stop the thread!).

BTW, Stefan, bravo for braving the anti-rodent throng:

> In contrast getting rid of a second frame is easy: just
> click in the `X' in top corner of your window(frame).

Click? You mean with a mmm mm m m o u s e ?

[Disclaimer: This is in no way an endorsement of having a separate splash
frame. My opinion on this topic is irrelevant anyway, having been foreclosed
by RMS's position. FWIW (nothing), I am in favor of putting helpful links to
learning on the Help menu (where they are already), and showing the GNU info
only in the About Emacs menu item, where people expect to find that sort of
thing. I'm generally not in favor of splash/nag screens at startup, but if
we must have one, then I'm in favor of a show-no-more checkbox (always and
for everyone). One person's helpful suggestion is another person's annoying
nag. There, I'll say no more about this.]

Re: New start up splash screen annoyance...

[Stephen J. Turnbull]

This is a one-off suggestion to emacs-devel, and y'all can do what you
want to with it.  Reply-To set to xemacs-beta where I plan to follow up.

Stefan Monnier writes:

 > > Two frames always imply a fight: the window manager will try to find
 > > places for them and decide on how to focus them.  Getting a separate
 > > window tamed is the matter of C-x 0 or C-x 1.  In contrast, C-x 5 0 or
 > > C-x 5 1 will leave one with a window configuration that might be worse
 > > than if just one frame would have been placed.

The important implication of this is that window manager or init file
settings might leave the splash screen obscured.  That's not what
Richard wants.  David's particular configuration is not a big deal
(except to him), given the goal of this decision, but the complexity
of getting the splash screen on top is.

 > But once you have a split-window display, it's not straightforward
 > to a newbie how to get back to the single-window he's used to

So how about giving them a [X] in the divider?  This lack is a UI bug
independent of the splash spiel.

RE: New start up splash screen annoyance...

[Drew Adams]

> So how about giving them a [X] in the divider?  This lack is a UI bug
> independent of the splash spiel.

I was almost going to suggest that, or something similar: Add an `X' button
to (all) mode lines at the far right, which when clicked would delete the
window. Did you mean something like that (but just for the startup display)?

But I remembered that we already have `mouse-3' on the mode-line bound to
`mouse-delete-window'. Although it's true that a new user might try to click
(mouse-1?) on the `X' and s?he might not think to use `mouse-3'. Then again,
a user might never notice the `X' or figure out what it's for.

All told, I'd say we would be going overboard with such a thing, especially
just to compensate for startup complexity that is (IMO) unnecessary.

If it's a frame with the window-manager frame-delete button that users are
already familiar with, OK, but there is no sense trying to do that for a
startup Emacs window, IMO. We are now getting into the realm of adding stuff
to patch up an already overly complicated startup.

But keep this thread rolling...

RE: New start up splash screen annoyance...

[Stephen J. Turnbull]

Drew Adams writes:

 > > So how about giving them a [X] in the divider?  This lack is a UI bug
 > > independent of the splash spiel.
 > 
 > I was almost going to suggest that, or something similar: Add an `X' button
 > to (all) mode lines at the far right,

That's pretty much what I'm suggesting.  An alternative would be a
grip that could be dragged until the smaller window disappeared, at
which point the modeline itself would go *poof*.

 > But I remembered that we already have `mouse-3' on the mode-line bound to
 > `mouse-delete-window'.

Surely you didn't type that with a straight face!  Jane Noob is going
to have the special meaning of button 3 on the modeline memorized?  I
don't think so.  It's this kind of thing that results in Dired having
4 ways to say "next line" with people suggesting adding another.

The point of a GUI is to provide ways to do common operations that are
convenient and easily visible on-screen, so you don't have to remember
them.

Emacsen have introduced some interesting, elegant, and subtle ways to
use the UI.  What they aren't is obvious or consistent with the GUI
gestures users are familiar with from the Mac or Windows.  Users (who
don't think of Emacs as the obvious way to interact with all their
applications) need to be reminded of them.

 > But keep this thread rolling...

No, I'm serious about this separate from the issue of the splash
screen.  If we want to encourage new users to learn to use (Emacs)
windows, it would be a big help if the GUI provided gestures to
operate on them in a mnemonic way.

After all, what is an Emacs frame but a tiled window manager?  We
should present it that way to the user.

Re: New start up splash screen annoyance...

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Drew Adams writes:
>
>  > But I remembered that we already have `mouse-3' on the mode-line
>  > bound to `mouse-delete-window'.
>
> Surely you didn't type that with a straight face!  Jane Noob is
> going to have the special meaning of button 3 on the modeline
> memorized?  I don't think so.

There is a tooltip on the mode line, and Emacs' tooltips are enabled
by default, usable and unobtrusive on all platforms with GUI.

However, cough cough, the tool tip reads:

mouse-1: select (drag to resize), mouse-2 = C-x 1, mouse-3 = C-x 0

So while we _have_ sort of a working announcement in place, it is
utterly useless to beginners.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    However, cough cough, the tool tip reads:

    mouse-1: select (drag to resize), mouse-2 = C-x 1, mouse-3 = C-x 0

    So while we _have_ sort of a working announcement in place, it is
    utterly useless to beginners.

I think the motive for that text was to make it shorter.
Would it be better to use

    mouse-1: select (drag to resize), mouse-2 = maximize window, mouse-3 = delete window

I am not sure whether a tooltip that long causes some sort of problem.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     However, cough cough, the tool tip reads:
>
>     mouse-1: select (drag to resize), mouse-2 = C-x 1, mouse-3 = C-x 0
>
>     So while we _have_ sort of a working announcement in place, it is
>     utterly useless to beginners.
>
> I think the motive for that text was to make it shorter.

Granted, but I think we went overboard.

> Would it be better to use
>
>     mouse-1: select (drag to resize), mouse-2 = maximize window, mouse-3 = delete window
>
> I am not sure whether a tooltip that long causes some sort of problem.

Can't tooltips be multiline?

                  For this window of the frame:
mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    Can't tooltips be multiline?

		      For this window of the frame:
    mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish

I don't know if that is possible, but that looks nice.

Re: New start up splash screen annoyance...

[David Kastrup]

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

Richard Stallman <rms@gnu.org> writes:

>     Can't tooltips be multiline?
>
> 		      For this window of the frame:
>     mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish
>
> I don't know if that is possible, but that looks nice.

Well, bindings.el contains an outcommented two-line version saying
pretty much that it does not look nice.  However, I find that with the
following patch, the resulting look seems pretty much ok for me (on
GTK+ with reasonably large fonts).  Better than a longer single-line
version, anyway.  What do others think?

[Taking off the XEmacs list from the distribution: it's rather
 off-topic there]

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 919 bytes --]

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 54a3220..b80be61 100644
*** a/lisp/bindings.el
--- b/lisp/bindings.el
***************
*** 301,307 ****
  	;; 	  "\
  	;; mouse-1: select window, mouse-2: delete others, mouse-3: delete,
  	;; drag-mouse-1: resize, C-mouse-2: split horizontally"
! 	"mouse-1: select (drag to resize), mouse-2 = C-x 1, mouse-3 = C-x 0")
         (dashes (propertize "--" 'help-echo help-echo))
         (standard-mode-line-format
  	(list
--- 301,309 ----
  	;; 	  "\
  	;; mouse-1: select window, mouse-2: delete others, mouse-3: delete,
  	;; drag-mouse-1: resize, C-mouse-2: split horizontally"
! "		For this window of the frame:
! mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish")
! ;;	"mouse-1: select (drag to resize), mouse-2 = C-x 1, mouse-3 = C-x 0")
         (dashes (propertize "--" 'help-echo help-echo))
         (standard-mode-line-format
  	(list

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: New start up splash screen annoyance...

[Richard Stallman]

    ! "		For this window of the frame:
    ! mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish")

"delete" would be better than "vanish".

Aside from that, do people like it?

RE: New start up splash screen annoyance...

[Drew Adams]

>     ! "		For this window of the frame:
>     ! mouse-1: select (drag to resize), mouse-2: maximize,
>       mouse-3: vanish")
>
> "delete" would be better than "vanish".
>
> Aside from that, do people like it?

Not I. There is rarely any need for a tooltip to use more than one line. And
this case certainly doesn't require it.

Why would a tooltip, which is already contextual, need to explain what its
context is, what it pertains to? Why would it need to say "For this window
of the frame"? If it is not clear enough without that context explanation,
then there is something wrong with the UI beyond just the tooltip text.

Re: New start up splash screen annoyance...

[David Kastrup]

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

>>     ! "		For this window of the frame:
>>     ! mouse-1: select (drag to resize), mouse-2: maximize,
>>       mouse-3: vanish")
>>
>> "delete" would be better than "vanish".
>>
>> Aside from that, do people like it?
>
> Not I. There is rarely any need for a tooltip to use more than one
> line. And this case certainly doesn't require it.

Compare the one-line and the two-line version.  The latter version is
quite narrower, and the _length_, not the height of the tooltip is
more disturbing here, in my opinion.

> Why would a tooltip, which is already contextual, need to explain
> what its context is, what it pertains to?

The context is the mode line, and it pertains to the window above the
mode line.

> Why would it need to say "For this window of the frame"? If it is
> not clear enough without that context explanation, then there is
> something wrong with the UI beyond just the tooltip text.

The mode line is not the same as the window.  "This window of the
frame" makes clear that we are not talking about the window system's
definition of a window, but about something that is nested within
frames.

By the way: this tooltip (however many lines it takes) should
absolutely not get displayed when there is only one window in the
frame: it will only confuse the user since all announced operations
are noops and there is no difference between window and frame.

-- 
David Kastrup

RE: New start up splash screen annoyance...

[Drew Adams]

> >>     ! "		For this window of the frame:
> >>     ! mouse-1: select (drag to resize), mouse-2: maximize,
> >>       mouse-3: vanish")
> >>
> >> "delete" would be better than "vanish".
> >>
> >> Aside from that, do people like it?
> >
> > Not I. There is rarely any need for a tooltip to use more than one
> > line. And this case certainly doesn't require it.
>
> Compare the one-line and the two-line version.  The latter version is
> quite narrower, and the _length_, not the height of the tooltip is
> more disturbing here, in my opinion.

Does "here" refer to the "latter", which presumably refers to the two-line
version? Are you saying that you prefer the one-line version?

We should try to keep tooltips short. If a lot really needs to be said, for
some reason, then that is an indication of a UI design problem. Let's not
try to make a tooltip do more than it is designed for; it is not a
replacement for doc.

If this particular line is too long, then we can shorten it.

 mouse: 1=select/resize, 2=max, 3=remove

 mouse: 1=select/resize, 2=max size, 3=remove (window)

 ...

There are lots of possibilities, depending on what you feel is unclear and
what information you are trying to convey.

> > Why would a tooltip, which is already contextual, need to explain
> > what its context is, what it pertains to?
>
> The context is the mode line, and it pertains to the window above the
> mode line.

This is not doc; it is a tooltip. Users will try it and find out, if unsure.
There are no hazardous materials involved here. You can try this at home,
kids.

> > Why would it need to say "For this window of the frame"? If it is
> > not clear enough without that context explanation, then there is
> > something wrong with the UI beyond just the tooltip text.
>
> The mode line is not the same as the window.  "This window of the
> frame" makes clear that we are not talking about the window system's
> definition of a window, but about something that is nested within
> frames.

Really not necessary.

"This window of the frame": "of the frame" is 100% useless, as is "this".

If we stop making an effort to keep tooltips short, thinking that we need to
add padding such as this, then our tooltips will soon become Victorian
novels.

A mode-line is tied to its window and buffer. Though a mode-line can contain
text that is unrelated to the window/buffer, most of its text is usually
related.

> By the way: this tooltip (however many lines it takes) should
> absolutely not get displayed when there is only one window in the
> frame: it will only confuse the user since all announced operations
> are noops and there is no difference between window and frame.

We do agree about that.

Re: New start up splash screen annoyance...

[David Kastrup]

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

>> >>     ! "		For this window of the frame:
>> >>     ! mouse-1: select (drag to resize), mouse-2: maximize,
>> >>       mouse-3: vanish")
>> >>
>> >> "delete" would be better than "vanish".
>> >>
>> >> Aside from that, do people like it?
>> >
>> > Not I. There is rarely any need for a tooltip to use more than one
>> > line. And this case certainly doesn't require it.
>>
>> Compare the one-line and the two-line version.  The latter version is
>> quite narrower, and the _length_, not the height of the tooltip is
>> more disturbing here, in my opinion.
>
> Does "here" refer to the "latter", which presumably refers to the
> two-line version?

No, "here" refers to comparing the one-line version with the two-line
version.

> Are you saying that you prefer the one-line version?

No.

>> > Why would a tooltip, which is already contextual, need to explain
>> > what its context is, what it pertains to?
>>
>> The context is the mode line, and it pertains to the window above
>> the mode line.
>
> This is not doc; it is a tooltip. Users will try it and find out, if
> unsure.  There are no hazardous materials involved here. You can try
> this at home, kids.

I don't think I would try out a button called "delete" if I don't have
a clue just what it will delete.

>> > Why would it need to say "For this window of the frame"? If it is
>> > not clear enough without that context explanation, then there is
>> > something wrong with the UI beyond just the tooltip text.
>>
>> The mode line is not the same as the window.  "This window of the
>> frame" makes clear that we are not talking about the window
>> system's definition of a window, but about something that is nested
>> within frames.
>
> Really not necessary.
>
> "This window of the frame": "of the frame" is 100% useless, as is
> "this".

If one knows the Emacs terminology by heart.

> If we stop making an effort to keep tooltips short, thinking that we
> need to add padding such as this, then our tooltips will soon become
> Victorian novels.

The first line is shorter than the second one.  Further shortening it
will actually worsen the visual appearance, so there is no point in
omitting helpful content.

> A mode-line is tied to its window and buffer. Though a mode-line can
> contain text that is unrelated to the window/buffer, most of its
> text is usually related.

Tooltips are not primarily for seasoned users.

>> By the way: this tooltip (however many lines it takes) should
>> absolutely not get displayed when there is only one window in the
>> frame: it will only confuse the user since all announced operations
>> are noops and there is no difference between window and frame.
>
> We do agree about that.

Well, at least some common point.  Apart from the first letter of our
name, I doubt we will find many more.  I guess I have said most of
what I have to say about this matter.  If you do what is needed to
feel the same, we can just let the others possibly chime in and let
Richard sort out the mess with a decision.

Or something.

All the best,

-- 
David Kastrup

RE: New start up splash screen annoyance...

[Drew Adams]

> I don't think I would try out a button called "delete" if I don't have
> a clue just what it will delete.

"remove" is better here than "delete", BTW, for just that reason.

But the point is that you can only do so much in a tooltip, and to try to do
more than what it is designed for defeats the purpose.

Sure, it's a judgment call. If you think it is very important to mention
"window", then do so. But adding padding such as "this window of the frame"
is counterproductive. It confuses more that it helps (Why "this"? Is it
trying to tell me something about some other window too? Why "of the frame"?
Is there some window I should worry about that is not in the frame? Is there
some other frame that is involved here?)

If we don't pay attention to this, soon we will have text such as "This
window of the frame, which is just above the place where you just clicked
with your mouse just now." And perhaps we'll start explaining what a frame
is and the difference between Emacs windows and window-manager windows, to
avoid confusion by newbies.

> >> > Why would it need to say "For this window of the frame"? If it is
> >> > not clear enough without that context explanation, then there is
> >> > something wrong with the UI beyond just the tooltip text.
> >>
> >> The mode line is not the same as the window.  "This window of the
> >> frame" makes clear that we are not talking about the window
> >> system's definition of a window, but about something that is nested
> >> within frames.
> >
> > Really not necessary.
> >
> > "This window of the frame": "of the frame" is 100% useless, as is
> > "this".
>
> If one knows the Emacs terminology by heart.

See above - will you explain windows and frames in every tooltip that
involves either? Does what you wrote actually explain anything about windows
and frames? I think it only adds confusion.

> > If we stop making an effort to keep tooltips short, thinking that we
> > need to add padding such as this, then our tooltips will soon become
> > Victorian novels.
>
> The first line is shorter than the second one.  Further shortening it
> will actually worsen the visual appearance, so there is no point in
> omitting helpful content.

The content I spoke of is not helpful. It is 100% fluff. It adds only
confusion.

> > A mode-line is tied to its window and buffer. Though a mode-line can
> > contain text that is unrelated to the window/buffer, most of its
> > text is usually related.
>
> Tooltips are not primarily for seasoned users.

And? Does your additional text actually help unseasoned users? I don't think
so. If the extra padding does anything at all, it adds confusion, IMO.

> >> By the way: this tooltip (however many lines it takes) should
> >> absolutely not get displayed when there is only one window in the
> >> frame: it will only confuse the user since all announced operations
> >> are noops and there is no difference between window and frame.
> >
> > We do agree about that.
>
> Well, at least some common point.  Apart from the first letter of our
> name, I doubt we will find many more.  I guess I have said most of
> what I have to say about this matter.  If you do what is needed to
> feel the same, we can just let the others possibly chime in and let
> Richard sort out the mess with a decision.
>
> Or something.

OK. We've each made our point.

Re: New start up splash screen annoyance...

[Kenichi Handa]

In article <86ps064mi0.fsf@lola.quinscape.zz>, David Kastrup <dak@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>>> ! "		For this window of the frame:
>>> ! mouse-1: select (drag to resize), mouse-2: maximize,
>>> mouse-3: vanish")
>>> 
>>> "delete" would be better than "vanish".
>>> 
>>> Aside from that, do people like it?
> >
> > Not I. There is rarely any need for a tooltip to use more than one
> > line. And this case certainly doesn't require it.

> Compare the one-line and the two-line version.  The latter version is
> quite narrower, and the _length_, not the height of the tooltip is
> more disturbing here, in my opinion.

I agree, and I even more like three lines tooltip as this
for this case:

	mouse-1: select (drag to resize)
	mouse-2: maximize
	mouse-3: delete

But, for echo area, I prefer one line tooltip.

---
Kenichi Handa
handa@m17n.org

Re: New start up splash screen annoyance...

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> I agree, and I even more like three lines tooltip as this
> for this case:
>
> 	mouse-1: select (drag to resize)
> 	mouse-2: maximize
> 	mouse-3: delete

Probably "select/resize" is sufficient.  Resizing by dragging is a
pretty ubiquitous mouse gesture.

> But, for echo area, I prefer one line tooltip.

One could use the same with "\n" replaced by "  " and fill-wrapping to
the length of the echo area.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Stefan Monnier]

> I agree, and I even more like three lines tooltip as this
> for this case:

> 	mouse-1: select (drag to resize)
> 	mouse-2: maximize
> 	mouse-3: delete

> But, for echo area, I prefer one line tooltip.

I think that echo-area tooltips deserve to be massaged to avoid this kind of
mess: Drew uses a single-line vry-long minibuffer-only frame, so any
multiline message in the echo area is undesirable.  David OTOH seems to use
the more common 80-columns frame with its own resizable echo-area, so long
text is bad but multiple lines are not.

To deal with both situations, we'll need for Emacs to automatically adjust
the message's format to the minibuffer's shape.
E.g. the messages could be spread over several lines and an option would
make Emacs put those lines back together with something like

  (mapconcat 'identity (split-string MSG "\n") " | ")

this way, Drew (and myself as well since I use a similar setup) could just
set this variable and not suffer from other people's preference for
multiple lines.


        Stefan

Re: New start up splash screen annoyance...

[David Kastrup]

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

>> I agree, and I even more like three lines tooltip as this
>> for this case:
>
>> 	mouse-1: select (drag to resize)
>> 	mouse-2: maximize
>> 	mouse-3: delete
>
>> But, for echo area, I prefer one line tooltip.
>
> I think that echo-area tooltips deserve to be massaged to avoid this kind of
> mess: Drew uses a single-line vry-long minibuffer-only frame, so any
> multiline message in the echo area is undesirable.  David OTOH seems to use
> the more common 80-columns frame with its own resizable echo-area, so long
> text is bad but multiple lines are not.

Oh, not at all: _iff_ I were using the echo area for tooltips, I would
want the tool tip to be as long as the echo area.  But I am using
popup frame tooltips, and for those, a single long line is quite ugly.

And I think it perfectly fine to generally use as few lines as
possible for echo-area tooltips.  But for the _regular_ tooltips,
that's not pretty.

-- 
David Kastrup

RE: New start up splash screen annoyance...

[Drew Adams]

> Oh, not at all: _iff_ I were using the echo area for tooltips, I would
> want the tool tip to be as long as the echo area.  But I am using
> popup frame tooltips, and for those, a single long line is quite ugly.
>
> And I think it perfectly fine to generally use as few lines as
> possible for echo-area tooltips.  But for the _regular_ tooltips,
> that's not pretty.

I think we might all be close. It sounds like we might agree on these things
(however they might be implemented):

. Tooltip/echo area text should generally be kept to a minimum.

. When used in the echo area, it should minimize the number of newlines,
adding them only when they really add clarity. No assumptions should be made
about the width or height of a user's echo area. In particular, no filling -
let the window resize itself or wrap the text if it is too long.

. When used as a tooltip, it should use newlines as appropriate to make the
text as clear as possible.

Re: New start up splash screen annoyance...

[Richard Stallman]

    . When used in the echo area, it should minimize the number of newlines,
    adding them only when they really add clarity. No assumptions should be made
    about the width or height of a user's echo area. In particular, no filling -
    let the window resize itself or wrap the text if it is too long.

    . When used as a tooltip, it should use newlines as appropriate to make the
    text as clear as possible.

This suggests that we put in newlines for the tooltip case,
and repace them with spaces for display in the echo area.

RE: New start up splash screen annoyance...

[Drew Adams]

> > I agree, and I even more like three lines tooltip as this
> > for this case:
>
> > 	mouse-1: select (drag to resize)
> > 	mouse-2: maximize
> > 	mouse-3: delete
>
> > But, for echo area, I prefer one line tooltip.
>
> I think that echo-area tooltips deserve to be massaged to avoid
> this kind of mess: Drew uses a single-line vry-long
> minibuffer-only frame, so any multiline message in the echo area
> is undesirable.  David OTOH seems to use the more common
> 80-columns frame with its own resizable echo-area, so long
> text is bad but multiple lines are not.
>
> To deal with both situations, we'll need for Emacs to automatically adjust
> the message's format to the minibuffer's shape.
> E.g. the messages could be spread over several lines and an option would
> make Emacs put those lines back together with something like
>
>   (mapconcat 'identity (split-string MSG "\n") " | ")
>
> this way, Drew (and myself as well since I use a similar setup) could just
> set this variable and not suffer from other people's preference for
> multiple lines.

Good point, and sounds good to me. Whatever the solution design, you've
expressed the echo-area concern well.

It's also good that you separated two of the strands of the discussion. Much
of what I was saying was not about single vs multiple lines or echo area vs
tooltip. It was about keeping the text for this kind of help to a minimum -
not adding unnecessary verbage.

I mixed in a request to not add newlines gratuitously that was more
pertinent to the echo-area point that you clarified, and doing so I confused
things.

Re: New start up splash screen annoyance...

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     ! "		For this window of the frame:
  >     ! mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish")
  > 
  > "delete" would be better than "vanish".
  > 
  > Aside from that, do people like it?

I do (provided "vanish" is replaced with something better).
Even more, I think we should consider examining all the mode line
tooltips and try to improve them in a similar way (for example the
coding system one is not very clear). 

Re: New start up splash screen annoyance...

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>   >     ! "		For this window of the frame:
>   >     ! mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish")
>   > 
>   > "delete" would be better than "vanish".
>   > 
>   > Aside from that, do people like it?
>
> I do (provided "vanish" is replaced with something better).

Let me just explain the motivation for "vanish" here so that perhaps
someone can come up with a better term: "delete", "remove" or "close"
(which I also considered) could make the naive user worry that his
buffer or even his file will get deleted.  While "close" at least does
not cause this worry for the _file_, it might still surprise the user
that the buffer stays around.  "evaporate" does not really help.
"hide" might be an idea.  "unmap" is probably most accurate, but I am
not sure whether it might be somewhat too technical.

But it's probably the best I can think of, at least better than
"vanish".

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Juri Linkov]

>     ! "		For this window of the frame:
>     ! mouse-1: select (drag to resize), mouse-2: maximize, mouse-3: vanish")
>
> "delete" would be better than "vanish".
>
> Aside from that, do people like it?

Multi-line tooltips don't work with (tooltip-mode -1) or
if `tooltip-use-echo-area' is non-nil, because only the first line
of the tooltip is displayed in the echo area:

"		For this window of the frame:"

and nothing more.

And resizing the echo area is not an option too because when the echo area
gets resized, the mode line of the lower window moves away from the
mouse pointer upward immediately after placing the mouse pointer on it.

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

RE: New start up splash screen annoyance...

[Drew Adams]

> I think the motive for that text was to make it shorter.
> Would it be better to use
>
>     mouse-1: select (drag to resize), mouse-2 = maximize window,
>     mouse-3 = delete window
>
> I am not sure whether a tooltip that long causes some sort of problem.

It is definitely better to refer to what happens, rather than to a key
binding.

Here, you refer to `window' for mouse-2 and -3, but not for -1. You also
have both `:' and ` =', inconsistently.

If space is not a problem (which I would guess), then this is better:

 mouse-1: drag window, mouse-2: maximize window, mouse-3: delete window

If space is a problem, then use this:

 Window - mouse-1: resize, mouse-2: maximize, mouse-3: delete

or even the same without "Window -".

Re: New start up splash screen annoyance...

[Richard Stallman]

     Window - mouse-1: resize, mouse-2: maximize, mouse-3: delete

That might be good.  Or this:

     Window above - mouse-1: select/resize, mouse-2: maximize, mouse-3: delete

Re: New start up splash screen annoyance...

[David Reitter]

On 23 Sep 2007, at 16:05, Richard Stallman wrote:

>     mouse-1: select (drag to resize), mouse-2 = maximize window,  
> mouse-3 = delete window

Better, but are you aware that new users have no idea what "mouse-2"  
or "mouse-3" means?
Some common hardware has only one or two mouse buttons, and in the  
case of two buttons, "mouse-1" is known as "left click", and  
"mouse-3" (or "mouse-2") are known as "right click". Can the tooltip  
refer to the key from which a "mouse-n" event results?

(I don't know the world of GNU/Linux GUI desktops well, since I use a  
tty for that, but perhaps mouse-3 is actually well known there, in  
which case it would be less of a problem.)

Re: New start up splash screen annoyance...

[Richard Stallman]

    Better, but are you aware that new users have no idea what "mouse-2"  
    or "mouse-3" means?

Do people agree with this?  We could call them "left", "middle", and
"right" in all our tooltips, if that is correct.

However, ISTR that this correspondence is not uniform.  Which number
button is the right button on a two-button mouse?

Re: New start up splash screen annoyance...

[Davis Herring]

> Do people agree with this?  We could call them "left", "middle", and
> "right" in all our tooltips, if that is correct.

The problem is what to do about mouse-4 and so forth: they will look quite
out of place without 1, 2, and 3 coming before them.

> However, ISTR that this correspondence is not uniform.  Which number
> button is the right button on a two-button mouse?

It may have once been variable, but I believe the standard now is that it
is mouse-3.  Often with such a mouse the two buttons may be pressed
simultaneously to get mouse-2.

Davis

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

RE: New start up splash screen annoyance...

[Drew Adams]

> > Do people agree with this?  We could call them "left", "middle", and
> > "right" in all our tooltips, if that is correct.

No, I disagree. `mouse-1' etc. are clear, whether or not one has encountered
them previously.

Another common naming system uses `MB1' or `MB-1' etc. ("MB" for "mouse
button"). It is not difficult for users to understand `mouse-1', IMO, and, I
believe that, as Robert mentioned, some systems (or mouse drivers?) let you
flip left and right behaviors without flipping the underlying names (e.g.
`mouse-1').

Re: New start up splash screen annoyance...

[Richard Stallman]

    > Do people agree with this?  We could call them "left", "middle", and
    > "right" in all our tooltips, if that is correct.

    The problem is what to do about mouse-4 and so forth: they will look quite
    out of place without 1, 2, and 3 coming before them.

We have no standard bindings for mouse-4 except in Artist mode.
And no tooltips mention it.

    > However, ISTR that this correspondence is not uniform.  Which number
    > button is the right button on a two-button mouse?

    It may have once been variable, but I believe the standard now is that it
    is mouse-3.  Often with such a mouse the two buttons may be pressed
    simultaneously to get mouse-2.

In that case, I guess we are ok changing mouse-1 to left and mouse-3
to right.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > Do people agree with this?  We could call them "left", "middle", and
>     > "right" in all our tooltips, if that is correct.
>
>     The problem is what to do about mouse-4 and so forth: they will look quite
>     out of place without 1, 2, and 3 coming before them.
>
> We have no standard bindings for mouse-4 except in Artist mode.
> And no tooltips mention it.

<mouse-4> (translated from <down-mouse-4> <down-mouse-4> <mouse-4>) at that spot runs the command mwheel-scroll
  which is an interactive compiled Lisp function in `mwheel.el'.
It is bound to <mouse-5>, <S-mouse-5>, <C-mouse-5>, <mouse-4>, <S-mouse-4>, <C-mouse-4>.
(mwheel-scroll EVENT)

Scroll up or down according to the EVENT.
This should only be bound to mouse buttons 4 and 5.

[back]

> In that case, I guess we are ok changing mouse-1 to left and mouse-3
> to right.

I don't think that the purportive win in clarity offsets the
divergence from the actually used event names.  I think that we stand
no chance of winning any user to Emacs who would be at a loss about
what to think about mouse-1, mouse-2, mouse-3.

-- 
David Kastrup

RE: New start up splash screen annoyance...

[Drew Adams]

> In that case, I guess we are ok changing mouse-1 to left and mouse-3
> to right.

I don't understand why we would do that. The doc everywhere uses `mouse-1'
etc., and that nomenclature is clear. There is absolutely nothing to be
gained by changing to `left' etc.

On the contrary: `mouse-1' is just an identifier; it signifies nothing about
physical button location. `Left' implies a spatial relation that might not
be correct. This renaming is a mistake, IMO.

Re: New start up splash screen annoyance...

[David Reitter]

On 25 Sep 2007, at 19:38, Drew Adams wrote:

> The doc everywhere uses `mouse-1'
> etc.,

That is indeed a problem! It should be consistent across the board.

> and that nomenclature is clear. There is absolutely nothing to be
> gained by changing to `left' etc.

No, it is not clear. A typical user has two mouse buttons. It is  
absolutely not obvious that the right mouse button is mapped to mouse-3.

> On the contrary: `mouse-1' is just an identifier; it signifies  
> nothing about
> physical button location. `Left' implies a spatial relation that  
> might not
> be correct.

It will be correct unless the user has remapped it, in which case  
they'd know.
Actually, I think "click" and "right click"/"secondary click" would  
be good, too, because mouse-1 is usually the default, no matter  
whether the user is a leftie. (Remember that on Macs, there is no  
right mouse button - control-click is used instead!)

If the user customizes this in Emacs, I presume we don't display  
`mouse-n', but the actual binding, right? Or is that tooltip hardcoded?

But while we are debating whether to call it mouse-1 and -3, I'd like  
to point out that a good UI will normally do what is most obvious and  
what the user expects. That means that the right mouse button should  
bring up a context menu and not delete something - this is the  
standard on most systems and platforms, I believe.

At least on the Mac and on Windows, the middle mouse-button is mapped  
centrally to something else. I have it mapped to a double-click.

Applications interpret a left click to set the text cursor, mark text  
(dragging), activate/toggle buttons and follow links. The secondary  
mouse button always brings up a context menu - I can't think of a  
common application that doesn't do that (except Emacs).
Double-clicks open or start things, usually in a new frame or window.  
I don't know what it means in the context of Emacs. One thing it  
translates to is showing *Messages* on double-click in the echo area,  
not on a simple mouse-1 (which can happen by chance occasionally).

Doing something such as closing a window requires clicking on an  
explicit closer button. The idea to have that in the mode-line was,  
thus, a good one, even though it'll close the window above and not  
below (the button that is displayed can make that clear graphically).

RE: New start up splash screen annoyance...

[Drew Adams]

> > The doc everywhere uses `mouse-1' etc.,
>
> That is indeed a problem! It should be consistent across the board.

And the problem is? "Everywhere uses" means that it _is_ consistent. Emacs
has internal consistency in this regard. Internal consistency is much more
important for a UI than is being consistent with things outside it.

However, if other things were equal, then we would also want consistency
with the larger world.

> > and that nomenclature is clear. There is absolutely nothing to be
> > gained by changing to `left' etc.
>
> No, it is not clear. A typical user has two mouse buttons.

Really? Ask a computer store or manufacturer how many 2-button mice they
sell.

I don't know. I tried to google a bit, but this is all I came up with (it's
for Mac ;-)):
http://www.macosxhints.com/polls/index.php?qid=mousebutton&aid=-1. This is
what it shows for Mac users (and AFAIK, Apple still ships with a one-button
mouse, unless you request otherwise):

 What type of mouse do you use with your Mac?

 No mouse, just the built-in trackpad (laptops)  448 (15.35%)
 Some other non-mouse device (ShuttlePro, tablet...)  128 (4.39%)
 Apple's one-button mouse  423 (14.50%)
 Apple's Bluetooth mouse  192 (6.58%)
 Non-Apple one-button mouse  5 (0.17%)
 Two-button mouse  366 (12.54%)
 Three-button mouse  632 (21.66%)
 Four-button mouse  123 (4.22%)
 Five-button mouse  333 (11.41%)
 Six-button mouse  52 (1.78%)
 Seven-button mouse  85 (2.91%)
 'Too many buttons to count' mouse  131 (4.49%)
 2,918 votes

This is probably not a representative sample, but it's all I found. I guess
the bluetooth mouse has one button? If so, this sample shows 620 for 1
button, 366 for 2 buttons, 632 for 3 buttons, and 434 for over 3 buttons.

> It is absolutely not obvious that the right mouse button is
> mapped to mouse-3.

AFAIK, the right button (whatever and wherever it might be) is not
necessarily mapped to `mouse-3'; one of the mouse buttons is mapped to
`mouse-3' - perhaps typically by default the one that is on the right.

The name `mouse-3' does not imply a spatial relation such as "on the right",
and that is the beauty of it: it represents something logical; it does not
(directly) represent something physical.

Now, maybe we should have a short doc section saying what typical relations
there are between the `mouse-1' etc. logical buttons and physical buttons
for different systems etc. Where `mouse-2' is if you have only two buttons,
etc. (Perhaps we have that already?) But that's not a reason to rename to
`left' etc.

> > On the contrary: `mouse-1' is just an identifier; it signifies
> > nothing about physical button location. `Left' implies a spatial
> > relation that might not be correct.
>
> It will be correct unless the user has remapped it, in which case
> they'd know.

Maybe, maybe not. And even when it is accurate, it is not the right way to
refer to it in the doc. At least not a doc that also involves Emacs Lisp and
customization. It is OK to speak of `right' button informally in some parts
of the Emacs user doc, but it is more accurate to mention the defined
(Emacs-Lisp) name for this: `mouse-3'. And it would be wrong, IMO, to change
that Lisp name to `right'.

> Actually, I think "click" and "right click"/"secondary click" would
> be good, too, because mouse-1 is usually the default, no matter
> whether the user is a leftie. (Remember that on Macs, there is no
> right mouse button - control-click is used instead!)

Good for what - do you mean as substitutes for `mouse-1' and `mouse-3'? If
so, then I disagree. A button identifier should not imply any specific
action. You can do more with a mouse button than just click it.

It is true that the actions `right-click' and `click' (being understood as
`left-click') refer to physical button positions, which is not strictly
correct. But it is common usage. It might be clearer to always say "click
`mouse-3'" but casual use of `right-click' is OK now and then, IMO.

> If the user customizes this in Emacs, I presume we don't display
> `mouse-n', but the actual binding, right? Or is that tooltip hardcoded?

Dunno. I hope it depends on whether we are referring to the operation
associated with the particular mouse action or to the mouse button itself.
There is nothing wrong with "Click `mouse-2' to paste copied text".

> But while we are debating whether to call it mouse-1 and -3, I'd like
> to point out that a good UI will normally do what is most obvious and
> what the user expects.

Agreed. That is, what the user expects and should expect in the context of a
given application and its UI.

Expectations of Internet Explorer users are pertinent only to a limited
degree for an application such as Emacs. We should accomodate them only when
that doesn't interfere with the best UI possible for what users need to be
able to do in Emacs.

> That means that the right mouse button should
> bring up a context menu and not delete something

That doesn't follow.

> - this is the standard on most systems and platforms, I believe.

Oh, OK. Yes, it is common, at least.

I too favor more use of `mouse-3' context menus, but remember that the Emacs
UI is particular in many respects. Its mouse use is different (superior) in
several ways, and Emacs has the particularity that nearly every key and
button combination can be (and is) exploited in some way. Emacs need not be
drawn down systematically to the lowest-common-denominator of inferior UIs
in the name of consistency or the principle of least surprise for new users.
Trying to accomodate external convention and new users is one consideration,
but not the only one.

I am in favor of more mouse menus (`mouse-3'), but they should not interfere
with other, more important mouse uses. For example, in text editing,
`mouse-3' should not bring up a menu; it should continue to extend and kill
the region. For that reason, in Emacs, `mouse-3' context menus should in
many contexts involve a modifier key, e.g., `C-mouse-3' and not just
`mouse-3'.

> At least on the Mac and on Windows, the middle mouse-button is mapped
> centrally to something else. I have it mapped to a double-click.
>
> Applications interpret a left click to set the text cursor, mark text
> (dragging), activate/toggle buttons and follow links. The secondary
> mouse button always brings up a context menu - I can't think of a
> common application that doesn't do that (except Emacs).

I can't think of an application that does what Emacs does, in general. Its
UI is bound to differ. We must not slavishly copy what exists elsewhere, but
we can accomodate convention when it does not detract from useful Emacs
features and fits harmoniously with the rest of Emacs.

> Double-clicks open or start things, usually in a new frame or window.

Double- and triple-clicks also often select different text entities, in many
UIs, and that since mice have existed.

> I don't know what it means in the context of Emacs. One thing it
> translates to is showing *Messages* on double-click in the echo area,
> not on a simple mouse-1 (which can happen by chance occasionally).

I don't have a strong opinion about that. But I don't see the objection to a
single-click in an environment where a single-click is not otherwise useful.
What is gained by requiring a double-click? Your argument seems to be that
because "double-clicks open or start things" in general, a user should be
required to double-click to bring up *Messages* from the minibuffer. I don't
follow that.

IIRC, this feature was added because users often try to click in the
minibuffer to put the cursor there, as if they could activate it that way,
or, even more typically, they try to select text that is part of a message
in the echo area. For that, it is entirely appropriate to show them
*Messages* as soon as they have clicked (not double-clicked) there.

[FWIW, in my own code, a `mouse-2' click in an inactive minibuffer brings up
`M-x'. It is a shortcut to entering a command.]

> Doing something such as closing a window requires clicking on an
> explicit closer button. The idea to have that in the mode-line was,
> thus, a good one, even though it'll close the window above and not
> below (the button that is displayed can make that clear graphically).

Agreed, though I'm not convinced that a directional graphic is that
necessary. I have nothing against it, however, if it is clear. The advantage
of `X' is that it is commonly recognized to mean close or delete. (I liked
David's suggestion to turn the `X' upside down.)

Re: New start up splash screen annoyance...

[David Reitter]

Drew,

On 25 Sep 2007, at 22:03, Drew Adams wrote:

>>> The doc everywhere uses `mouse-1' etc.,
>>
>> That is indeed a problem! It should be consistent across the board.
>
> And the problem is? "Everywhere uses" means that it _is_  
> consistent. Emacs
> has internal consistency in this regard.

You misunderstood me. The problem is that using something like "left  
click" in a single tooltip is inconsistent with the documentation.  
And I believe that is what you alluded to in the first place. That's  
what I acknowledged.

> Emacs need not be
> drawn down systematically to the lowest-common-denominator of  
> inferior UIs
> in the name of consistency or the principle of least surprise for  
> new users.
> Trying to accomodate external convention and new users is one  
> consideration,
> but not the only one.

Of course it is not the only consideration that counts and nobody  
ever said that.
I'm not getting drawn into such a fruitless discussion again.

About jumping to *Messages*:

> I don't have a strong opinion about that. But I don't see the  
> objection to a
> single-click in an environment where a single-click is not  
> otherwise useful.

I often find myself clicking on the echo area by accident. Perhaps  
that has to do with the fact that when the minibuffer is active, a  
click there will put the focus there. But if I'm the only one who  
makes that mistake, never mind.

> The advantage
> of `X' is that it is commonly recognized to mean close or delete.  
> (I liked
> David's suggestion to turn the `X' upside down.)

Funny!

RE: New start up splash screen annoyance...

[Drew Adams]

> >>> The doc everywhere uses `mouse-1' etc.,
> >>
> >> That is indeed a problem! It should be consistent across the board.
> >
> > And the problem is? "Everywhere uses" means that it _is_
> > consistent. Emacs has internal consistency in this regard.
>
> You misunderstood me. The problem is that using something like "left
> click" in a single tooltip is inconsistent with the documentation.
> And I believe that is what you alluded to in the first place. That's
> what I acknowledged.

Sorry for misunderstanding. I didn't realize that some tooltip mentioned
"left click". Yes, to be consistent it would say "click `mouse-1'".
(Complete consistency is not the only goal, of course.)

> About jumping to *Messages*:
>
> > I don't have a strong opinion about that. But I don't see the
> > objection to a single-click in an environment where a
> > single-click is not otherwise useful.
>
> I often find myself clicking on the echo area by accident. Perhaps
> that has to do with the fact that when the minibuffer is active, a
> click there will put the focus there. But if I'm the only one who
> makes that mistake, never mind.

You're not the only one. I've said the same thing. I too am not crazy about
the new behavior of bringing up *Messages*. In fact, I find that it causes
me more effort in the long run (especially since I use frames), since I then
have to close the *Messages* window/frame.

I understand why the new behavior was added, and that was especially because
of some such "accidents", in particular, mistaken attempts to select
echo-area output. Double-clicking will not help here however, IMO. I
personally prefer the old behavior (just an error message), but on n'arrete
pas le progres...

Re: New start up splash screen annoyance...

[David Reitter]

On 26 Sep 2007, at 15:59, Drew Adams wrote:

> Sorry for misunderstanding. I didn't realize that some tooltip  
> mentioned
> "left click". Yes, to be consistent it would say "click `mouse-1'".
> (Complete consistency is not the only goal, of course.)

Only a hypothetical tooltip. I suggested to use "click" or "left  
click", actually, and what may have fooled you is that I agreed that  
the inconsistency is a problem for my own suggestion. I maintain that  
"left click" would be more natural even if wrong in very rare cases  
where users re-map this somewhere else, but I concede it would also  
have to be consistent with the rest of the documentation. Maybe we'll  
just respectfully disagree - the discussion won't bring up anything new!

RE: New start up splash screen annoyance...

[Drew Adams]

> > Sorry for misunderstanding. I didn't realize that some tooltip
> > mentioned "left click". Yes, to be consistent it would say
> > "click `mouse-1'". (Complete consistency is not the only goal,
> > of course.)
>
> Only a hypothetical tooltip. I suggested to use "click" or "left
> click", actually, and what may have fooled you is that I agreed that
> the inconsistency is a problem for my own suggestion. I maintain that
> "left click" would be more natural even if wrong in very rare cases
> where users re-map this somewhere else, but I concede it would also
> have to be consistent with the rest of the documentation. Maybe we'll
> just respectfully disagree - the discussion won't bring up anything new!

I'm not sure we disagree (unless it's disagreeing about whether we disagree,
and we might even agree about that disagreement!).

We seem to agree that consistency is generally good but that there can be
exceptions. And we seem to agree that "click" in a tooltip (instead of
"click `mouse-1'") is a reasonable exception. And we seem to agree that this
discussion has probably already yielded anything of value that it had to
offer. ;-)

echo area clicks: *Messages*

[David Reitter]

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

On 26 Sep 2007, at 15:59, Drew Adams wrote:

>> I often find myself clicking on the echo area by accident. Perhaps
>> that has to do with the fact that when the minibuffer is active, a
>> click there will put the focus there. But if I'm the only one who
>> makes that mistake, never mind.
>
> You're not the only one. I've said the same thing. I too am not  
> crazy about
> the new behavior of bringing up *Messages*. In fact, I find that it  
> causes
> me more effort in the long run (especially since I use frames),  
> since I then
> have to close the *Messages* window/frame.
>
> I understand why the new behavior was added, and that was  
> especially because
> of some such "accidents", in particular, mistaken attempts to select
> echo-area output. Double-clicking will not help here however, IMO. I
> personally prefer the old behavior (just an error message), but on  
> n'arrete
> pas le progres...

Normally, when a user action has no assigned function, the  
application does not react at all. Examples include pressing an  
unbound key, or clicking on, say the desktop background (on my system  
at least). I can see why a click on a message would lead to  
*Messages*, but a click into empty space? Even an error message seems  
to distract.

You might be interested in the attached patch, which will require a  
double-click to bring up *Messages*. I find that more consistent with  
other UIs, where double-clicks open something like a new window.



[-- Attachment #2: mouse-echo.patch --]
[-- Type: application/octet-stream, Size: 2801 bytes --]

*** lisp/mouse.el	25 Jul 2007 05:47:12 +0100	1.315.2.3
--- lisp/mouse.el	26 Sep 2007 14:01:20 +0100	
***************
*** 630,639 ****
    "Move point to the position clicked on with the mouse.
  This should be bound to a mouse click event type."
    (interactive "e")
!   (mouse-minibuffer-check event)
!   ;; Use event-end in case called from mouse-drag-region.
!   ;; If EVENT is a click, event-end and event-start give same value.
!   (posn-set-point (event-end event)))
  
  (defvar mouse-last-region-beg nil)
  (defvar mouse-last-region-end nil)
--- 630,642 ----
    "Move point to the position clicked on with the mouse.
  This should be bound to a mouse click event type."
    (interactive "e")
!   (condition-case nil ;; prevent error message from mouse-minibuffer-check
!       (progn 
! 	(mouse-minibuffer-check event)
! 	;; Use event-end in case called from mouse-drag-region.
! 	;; If EVENT is a click, event-end and event-start give same value.
! 	(posn-set-point (event-end event)))
!     (error nil)))
  
  (defvar mouse-last-region-beg nil)
  (defvar mouse-last-region-end nil)
***************
*** 756,775 ****
  In Transient Mark mode, the highlighting remains as long as the mark
  remains active.  Otherwise, it remains until the next input event.
  
! If the click is in the echo area, display the `*Messages*' buffer."
    (interactive "e")
!   (let ((w (posn-window (event-start start-event))))
!     (if (and (window-minibuffer-p w)
! 	     (not (minibuffer-window-active-p w)))
! 	(save-excursion
! 	  ;; Swallow the up-event.
! 	  (read-event)
! 	  (set-buffer (get-buffer-create "*Messages*"))
! 	  (goto-char (point-max))
! 	  (display-buffer (current-buffer)))
!       ;; Give temporary modes such as isearch a chance to turn off.
!       (run-hooks 'mouse-leave-buffer-hook)
!       (mouse-drag-track start-event t))))
  
  
  (defun mouse-posn-property (pos property)
--- 759,782 ----
  In Transient Mark mode, the highlighting remains as long as the mark
  remains active.  Otherwise, it remains until the next input event.
  
! In case of a double click in the echo area, display the `*Messages*' 
! buffer."
    (interactive "e")
!   
!   (let ((click-count (1- (event-click-count start-event))))
!     (let ((w (posn-window (event-start start-event))))
!       (if (and (window-minibuffer-p w)
! 	       (not (minibuffer-window-active-p w)))
! 	  (save-excursion
! 	    (if (= click-count 1)
! 		(progn
! 		  (set-buffer (get-buffer-create "*Messages*"))
! 		  (read-event) ;; Swallow the up-event.
! 		  (goto-char (point-max))
! 		  (display-buffer (current-buffer)))))
! 	;; Give temporary modes such as isearch a chance to turn off.
! 	(run-hooks 'mouse-leave-buffer-hook)
! 	(mouse-drag-track start-event t)))))
  
  
  (defun mouse-posn-property (pos property)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: echo area clicks: *Messages*

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> You might be interested in the attached patch, which will require a
> double-click to bring up *Messages*. I find that more consistent
> with other UIs, where double-clicks open something like a new
> window.

I think it should be possible to select and yank a region by
click-and-drag on the message area.  It would not be the same
click-and-drag elsewhere since point and mark don't really exist since
there is no window involved.  But at least as far as the
highlighting/dragging/yanking is involved, we should get analogous
behavior to the real thing.

Double click for *Messages* is an ok idea, too.  But the current
single-click behavior is more or less a copout for offering the user
something different from what he actually wanted and/or expected, but
which might be close enough.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Robert J. Chassell]

    We could call them "left", "middle", and "right" ...

Except that I have seen window managers that permit me to change
"left" to "right" and vice-versa; the intent is to permit people to
shift to a mirrored mouse on the left.

What does anyone mean when he or she says "left"?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: New start up splash screen annoyance...

[Richard Stallman]

    Except that I have seen window managers that permit me to change
    "left" to "right" and vice-versa; the intent is to permit people to
    shift to a mirrored mouse on the left.

If you did that, you would know it.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Except that I have seen window managers that permit me to change
>     "left" to "right" and vice-versa; the intent is to permit people to
>     shift to a mirrored mouse on the left.
>
> If you did that, you would know it.

I think "mouse-1" "mouse-2" "mouse-3" is enough of a hint to get
people going.  At least those kind of people that would stand a chance
to ever get along with Emacs.  I can't imagine someone plugging three
mice into his computer in order to delete a window (ok, more likely he
will try a triple-click, in particular if he is using a Mac).  I think
we should just take the chance.  If we get a bug report, we can still
think about acting on it.

XEmacs calls the respective events [button1] [button2] [button3].  It
may be argued that this would be more understandable to beginners.
Personally, I don't think that the difference in understandability
warrants a change in the event definition, and I think that the event
symbol is not so cryptic as to make it a good idea to use anything but
the event symbol in the help text.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Manoj Srivastava]

On Mon, 24 Sep 2007 14:19:50 -0400, Richard Stallman <rms@gnu.org> said: 

>     Better, but are you aware that new users have no idea what
>     "mouse-2" or "mouse-3" means?

> Do people agree with this?  We could call them "left", "middle", and
> "right" in all our tooltips, if that is correct.

        I have a vertical mouse, bought when I was worried about the
 effect of long hours on my wrist.  The mouse sits upright, with all the
 buttons on the right hand side (you can also get left handed vertical
 mice).  The correct names would be "Top", "middle", "scroll", "Bottom"
 and "Thumb" for the buttons on this mouse.

> However, ISTR that this correspondence is not uniform.  Which number
> button is the right button on a two-button mouse?

        I have a number of mice where the number of buttons is neither 2
 nor three; and the left most button is not button 1.

        manoj
-- 
A fanatic is one who can't change his mind and won't change the
subject. Winston Churchill
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: New start up splash screen annoyance...

[Richard Stallman]

	    I have a vertical mouse, bought when I was worried about the
     effect of long hours on my wrist.  The mouse sits upright, with all the
     buttons on the right hand side (you can also get left handed vertical
     mice).  The correct names would be "Top", "middle", "scroll", "Bottom"
     and "Thumb" for the buttons on this mouse.

I think it is ok to say that anyone using such an unusual mouse has
the responsibility to know how to translate the usual button names for
it.

	    I have a number of mice where the number of buttons is neither 2
     nor three; and the left most button is not button 1.

I am curious what they do; but again I think that we need not concern
ourselves with whether tooltips are correct for such strange devices.

The two-button mouse is the main issue.  That is a common case,
so it is important.

Re: New start up splash screen annoyance...

[Didier Verna]

Stephen J. Turnbull wrote:

> Drew Adams writes:
>
>  > > So how about giving them a [X] in the divider?  This lack is a UI bug
>  > > independent of the splash spiel.
>  > 
>  > I was almost going to suggest that, or something similar: Add an
>  > `X' button to (all) mode lines at the far right,
>
> That's pretty much what I'm suggesting.  An alternative would be a
> grip that could be dragged until the smaller window disappeared, at
> which point the modeline itself would go *poof*.

  Note that you can already resize windows by dragging modelines, so
it's a matter of a threshold on window-height before closing one. But
anyway, I'm not sure this is really needed. If you happen to be unaware
of the C-x 0/1 bindings, I find it quite natural to go to the View menu
and get what you're looking for. This is pretty much compliant with what
Windows or Mac users would expect from a well behaving GUI.


>  > But I remembered that we already have `mouse-3' on the mode-line bound to
>  > `mouse-delete-window'.

   That is such an awful binding BTW ! At least, this menu could be a
sub-part of every contextual menu popped up by Mouse-3 in *windows*, and
mouse-3 on the modeline should pop up a modeline specific
contextual-menu.


> After all, what is an Emacs frame but a tiled window manager?  We
> should present it that way to the user.

  Actually, Emacs windows are an obsolete concept that today brings us
nothing but additional and unwanted complexity. There should be no
windows. There should be only frames, and if you like the tiling effect,
then Emacs should kindly ask the window manager to place and size its
frames exactly where and how Emacs wants them to be placed and sized.

-- 
New @-quartet featured CD Review !!
http://www.indie-music.com/modules.php?name=News&file=article&sid=6457

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

RE: New start up splash screen annoyance...

[Drew Adams]

> >  > But I remembered that we already have `mouse-3' on the
> >  > mode-line bound to `mouse-delete-window'.
>
> That is such an awful binding BTW ! At least, this menu could be a
> sub-part of every contextual menu popped up by Mouse-3 in *windows*, and
> mouse-3 on the modeline should pop up a modeline specific
> contextual-menu.

I don't disagree with either having this in a mouse-3 menu or adding an [X]
button to the mode-line. I imagine, however, that some people will want to
keep a single-click window-removal, whatever the binding might be.

> > After all, what is an Emacs frame but a tiled window manager?  We
> > should present it that way to the user.
>
> Actually, Emacs windows are an obsolete concept that today brings us
> nothing but additional and unwanted complexity. There should be no
> windows. There should be only frames, and if you like the tiling effect,
> then Emacs should kindly ask the window manager to place and size its
> frames exactly where and how Emacs wants them to be placed and sized.

Let's not open that can of worms, please. Before discussing the benefits or
disadvantages of throwing windows out the window, let's try to get Emacs
working well with frames. That's a large enough struggle.

Re: New start up splash screen annoyance...

[Stefan Monnier]

>   Note that you can already resize windows by dragging modelines, so
> it's a matter of a threshold on window-height before closing one. But

It'd probably be an acceptable option, but only if we can resuscitate
a window after it disappeared since the user may accidentally move the
modeline further than she intended.

> anyway, I'm not sure this is really needed. If you happen to be unaware
> of the C-x 0/1 bindings, I find it quite natural to go to the View menu
> and get what you're looking for. This is pretty much compliant with what
> Windows or Mac users would expect from a well behaving GUI.

Could be.  My beginners didn't find it obvious at all.  They expect to
manage such visual elements in a more direct manner.  Especially since you
otherwise (i.e. if you use a menu bar entry) have to somehow specify which
window you want to delete.

>   Actually, Emacs windows are an obsolete concept that today brings us
> nothing but additional and unwanted complexity.

Not when running in a tty.


        Stefan

RE: New start up splash screen annoyance...

[Drew Adams]

> >   Note that you can already resize windows by dragging modelines, so
> > it's a matter of a threshold on window-height before closing one. But
>
> It'd probably be an acceptable option, but only if we can resuscitate
> a window after it disappeared since the user may accidentally move the
> modeline further than she intended.

This is madness. We are going overboard, trying to compensate for things
that we never should have done in the first place. Who will try to close a
window by resizing it to infinitessimal oblivion?

And yes, Stefan is right if we go down that road. Are we going to have a
whole UI dialog to find out whether a user really meant to close the window?
Or allow a special kind of undo for window-closing-by-dragging?

I really think we've gone off the deep end on this. Stefan's choice of
"resuscitate" is telling ;-). Overboard and sinking fast...

(But keep this thread alive... We will look back on this 5 years from now
with nostalgia and amusement.)

Re: New start up splash screen annoyance...

[Stefan Monnier]

> This is madness. We are going overboard, trying to compensate for things
> that we never should have done in the first place. Who will try to close a
> window by resizing it to infinitessimal oblivion?

I would.  Based on experience with many other applications where you drag
separators to resize various areas.

> And yes, Stefan is right if we go down that road.  Are we going to have a
> whole UI dialog to find out whether a user really meant to close the window?
> Or allow a special kind of undo for window-closing-by-dragging?

I only meant to allow resuscitate when done as part of the same drag
operation (i.e. once you release the button, there's no going back).


        Stefan

RE: New start up splash screen annoyance...

[Drew Adams]

> > This is madness. We are going overboard, trying to compensate for things
> > that we never should have done in the first place. Who will try
> > to close a window by resizing it to infinitessimal oblivion?
>
> I would.  Based on experience with many other applications where you drag
> separators to resize various areas.

Fair enough. I admit that I too have done that (many, no; some, yes). But
only after having first looked for a button or menu item to remove the pane.
I've felt that UIs that have that as the only way to hide a pane are poorly
designed. Such behavior is not obvious to a new user, IMO. Imagine if that
were the only way to close a frame: shrink it down to nothing.

You say you would try doing that based on experience, and I think that's the
point here. Eventually, trial and error led to learning the workaround, and
once learned, it's ready to try on another app that also has no visible
indicator (button etc.). I'd rather we offer something more obvious.

Re: New start up splash screen annoyance...

[Juri Linkov]

>    That is such an awful binding BTW ! At least, this menu could be a
> sub-part of every contextual menu popped up by Mouse-3 in *windows*, and
> mouse-3 on the modeline should pop up a modeline specific
> contextual-menu.

I agree.  Mouse-3 is a standard button for pop-up context menus nowadays.

>   Actually, Emacs windows are an obsolete concept that today brings us
> nothing but additional and unwanted complexity.

Not true.  Most modern applications use tiled windows inside a frame,
and open additional frames only optionally when specially requested
as Emacs already does.

Look at modern IDEs - they usually have a window with a class browser,
a window with class members, windows with source files; all in one frame.
Look at modern mailers - they have a window with folders, with messages;
all in one frame.  Look at modern Web browsers - they have a window for
bookmarks, history, and Web pages arranged in tabs.  Even M$ that for a
long time insisted on the concept "one page - one frame" now implemented
tabs in the latest IE.

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

Re: New start up splash screen annoyance...

[Davis Herring]

>> After all, what is an Emacs frame but a tiled window manager?  We
>> should present it that way to the user.
>
>   Actually, Emacs windows are an obsolete concept that today brings us
> nothing but additional and unwanted complexity. There should be no
> windows. There should be only frames, and if you like the tiling effect,
> then Emacs should kindly ask the window manager to place and size its
> frames exactly where and how Emacs wants them to be placed and sized.

Creating new frames sometimes takes much longer than creating windows --
with a slow X connection, or when using a window manager like twm where
every frame created requires user interaction.  And Emacs makes good use
of its frames: `other-buffer' considers buffers recently but not currently
visible -- on the current frame.  And it makes no sense at all to support
rolling up or iconifying one of two side-by-side frames linked with
`follow-mode'; having just one frame prevents that.

Some window managers may treat unselected frames less favorably: rendering
them as partially transparent, or preventing a program from automatically
giving them focus (as we would then very often want to do with C-x 5 o, or
rather just C-x o).  Furthermore, reimplementing such things as C-x + to
use frames would be quite complicated, and we would have to have notions
of "frame subtrees" that were entirely invisible to the window manager and
yet critical to sane behavior.  (And what happens if the user moves or
resizes one out of 4 tile-frames, then asks Emacs to
rebalance/resize/delete some of those tiles?  Do we introduce M-x
sorry-emacs-just-kidding-you-can-move-this-frame-back?)

Finally, of course, there are issues of widget explosion -- giving each
window/frame a toolbar, a menu bar, a title bar, and whatever other
decorations takes up a lot of screen real estate, and neither 20 "Emacs
..." buttons nor one "Emacs (20)" button in a panel or so is useful. 
(Imagine what the Dock on OS X would look like if you iconified them all!)
 Of course, it would be possible to suppress some or all of the
decorations, perhaps including the panel button, but how is a simple Lisp
program that currently calls `display-buffer' supposed to decide whether,
if it creates a new window/frame, that window/frame is supposed to get a
tool bar or not?  Do we introduce levels of toolbar-desire so the user can
say just how badly they want to have tool bars even if they might take up
lots of space for very little use (in, say, *Messages*)?

If you really don't like windows, there are plenty of people (I believe
Stefan is one, and perhaps the Aqaumacs people) who use `pop-up-frames'
and prefer one frame per buffer, and they'd probably be happy to discuss
how to best arrange an all-frames Emacs.  But it seems somewhat confused
to even talk about -removing- windows from Emacs.

Davis

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

Re: New start up splash screen annoyance...

[Didier Verna]

"Davis Herring" <herring@lanl.gov> wrote:

> If you really don't like windows, there are plenty of people (I
> believe Stefan is one, and perhaps the Aqaumacs people) who use
> `pop-up-frames' and prefer one frame per buffer, and they'd probably
> be happy to discuss how to best arrange an all-frames Emacs. But it
> seems somewhat confused to even talk about -removing- windows from
> Emacs.

  Sorry, I forgot the smiley :-;

-- 
New @-quartet featured CD Review !!
http://www.indie-music.com/modules.php?name=News&file=article&sid=6457

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

Re: New start up splash screen annoyance...

[Richard Stallman]

    I was almost going to suggest that, or something similar: Add an `X' button
    to (all) mode lines at the far right, which when clicked would delete the
    window. Did you mean something like that (but just for the startup display)?

This is a good idea, in a general way, but I have one concern.
Normally the X to close a window is at the TOP right corner.
If there is an X at the right on a mode line, I think users
might suppose it refers to the window below it.  Then when
it instead deletes the window above the mode line, they
will be surprised.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I was almost going to suggest that, or something similar: Add an
>     `X' button to (all) mode lines at the far right, which when
>     clicked would delete the window. Did you mean something like
>     that (but just for the startup display)?
>
> This is a good idea, in a general way, but I have one concern.
> Normally the X to close a window is at the TOP right corner.
> If there is an X at the right on a mode line, I think users
> might suppose it refers to the window below it.  Then when
> it instead deletes the window above the mode line, they
> will be surprised.

We could display [X] upside down to show the difference.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: New start up splash screen annoyance...

[Drew Adams]

> > I think users might suppose it refers to the window below it.
> 
> We could display [X] upside down to show the difference.

;-D

Re: New start up splash screen annoyance...

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>>     I was almost going to suggest that, or something similar: Add an
>>     `X' button to (all) mode lines at the far right, which when
>>     clicked would delete the window. Did you mean something like
>>     that (but just for the startup display)?
>>
>> This is a good idea, in a general way, but I have one concern.
>> Normally the X to close a window is at the TOP right corner.
>> If there is an X at the right on a mode line, I think users
>> might suppose it refers to the window below it.  Then when
>> it instead deletes the window above the mode line, they
>> will be surprised.
>
> We could display [X] upside down to show the difference.

I think this definitely should be included in the DEVEL.HUMOR file.

cheers
sascha
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

RE: New start up splash screen annoyance...

[Drew Adams]

>     I was almost going to suggest that, or something similar: Add
>     an `X' button to (all) mode lines at the far right, which
>     when clicked would delete the window.
>
> This is a good idea, in a general way, but I have one concern.
> Normally the X to close a window is at the TOP right corner.
> If there is an X at the right on a mode line, I think users
> might suppose it refers to the window below it.  Then when
> it instead deletes the window above the mode line, they
> will be surprised.

That is a good point. I don't see a way around that potential gotcha. The
good news is that the damage from user error is not great, and we would all
learn quickly ;-).

Some window managers (at least used to) put the `X' (or equivalent icon) at
the frame upper left instead of the upper right. But that would not be
appropriate anyway for a mode-line.

Question: Are we discussing this as a possible addition or a possible
replacement for the `mouse-3' mode-line binding? If that binding is
replaced, I agree with someone's suggestion that `Delete Window' should be
added to a mode-line `mouse-3' context menu.

An `X' button has the disadvantages that (1) in a narrow window it might not
be visible (or else it might occlude other mode-line info) and (2) it
requires more precise mouse positioning than simply clicking the mode-line
(e.g. to choose from a menu of actions). If the `X' is in addition to some
other mouse means of deleting the window, then it is OK. If it is a
replacement (no `mouse-3' and no context menu item), then I think it is not
adequate.

Re: New start up splash screen annoyance...

[Richard Stallman]

    Question: Are we discussing this as a possible addition or a possible
    replacement for the `mouse-3' mode-line binding?

Mouse-3 already deletes the window.  We are just discussing
a change in its tooltip.

Re: New start up splash screen annoyance...

[Didier Verna]

Richard Stallman wrote:

> This is a good idea, in a general way, but I have one concern. 
> Normally the X to close a window is at the TOP right corner. If there
> is an X at the right on a mode line, I think users might suppose it
> refers to the window below it.

  I would be surprised if they did. The modeline is clearly associated
with one window, so I don't think there should be any ambiguity.

-- 
New @-quartet featured CD Review !!
http://www.indie-music.com/modules.php?name=News&file=article&sid=6457

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

mode line [X]

[Richard Stallman]

      I would be surprised if they did. The modeline is clearly associated
    with one window, so I don't think there should be any ambiguity.

We could try it and see.  Would someone like to implement the [X]?

Re: New start up splash screen annoyance...

[Didier Verna]

Stephen J. Turnbull wrote:

> This is a one-off suggestion to emacs-devel, and y'all can do what you
> want to with it.  Reply-To set to xemacs-beta where I plan to follow up.
>
> Stefan Monnier writes:
>
>  > > Two frames always imply a fight: the window manager will try to find
>  > > places for them and decide on how to focus them.  Getting a separate
>  > > window tamed is the matter of C-x 0 or C-x 1.  In contrast, C-x 5 0 or
>  > > C-x 5 1 will leave one with a window configuration that might be worse
>  > > than if just one frame would have been placed.
>
> The important implication of this is that window manager or init file
> settings might leave the splash screen obscured.  That's not what
> Richard wants.  David's particular configuration is not a big deal
> (except to him), given the goal of this decision, but the complexity
> of getting the splash screen on top is.

  AFAICR, we talked about this several years ago, and I think my opinion
was already that a so-called splash screen should be an
override-redirect window (not managed by the window manager), centered
on the screen[1], that stays for a while (see below), or until there's a
mouse click on it.

But note that it's different from a user calling display-splash-frame
which should probably stay as it is. I really don't think most users
make an actual use of the splash screen at startup (but prove me wrong). 
However, when someone calls d-s-f, it's probably to do something with it
(click the about buttons and stuff). So the splash screen need not be
interactive IMO.


Footnotes: 
[1]  that would also have the advantage of giving time to setup all the
faces and stuff *before* the first frame is actually displayed, and only
then, popup something ready to use.

-- 
New @-quartet featured CD Review !!
http://www.indie-music.com/modules.php?name=News&file=article&sid=6457

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

Re: New start up splash screen annoyance...

[Juri Linkov]

> What about the demonstration of concept in the patch below?  I think
> popping the splash screen in a separate frame is superior to dividing
> the initial frame, and doing so makes all kinds of complications with
> "concise" splash screen and whether splash should be in upper or lower
> window, a non-issue.  IIRC, Richard agreed to the idea of a separate
> frame.

I think creating a separate frame is only appropriate when the user
explicitly customized the option pop-up-frames.  And indeed currently
this already works: when pop-up-frames is non-nil, the startup screen is
displayed in the separate frame due to using the function `display-buffer'.

However, when pop-up-frames is non-nil, it would be very annoying to
insist on creating a separate frame.  For instance, I use the full-screen
single frame configuration which doesn't work with a separate startup frame.

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

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Juri Linkov <juri@jurta.org>
> Date: Sat, 22 Sep 2007 23:01:42 +0300
> 
> However, when pop-up-frames is non-nil, it would be very annoying to
> insist on creating a separate frame.  For instance, I use the full-screen
> single frame configuration which doesn't work with a separate startup frame.

You forget that you are not the target of this feature.  Those who are
probably won't customize pop-up-frames without also customizing away
the splash screen.

As for other technical arguments against the separate frame: we have
enough means in Emacs, I think, to force the splash screen to the
foreground.

Also, most other programs that display splash screen do that in a
separate frame.  I don't see why can't we.

Re: New start up splash screen annoyance...

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Also, most other programs that display splash screen do that in a
> separate frame.  I don't see why can't we.

The question is not why we can't, but why we should: "most other
programs" don't even have the option to display in a separate window
rather than a separate frame.  So of _course_ they display in a
separate frame.

We have the option to use a separate window instead.  For me, a
separate window would be less noisome.  It also would give the splash
screen a longer expected time of survival since the splash screen does
not have to be immediately dismissed (or a window rearrangement bout
started) before being able to commence any work.

Your mileage may vary.  That's why we are discussing here, and it is
of course a somewhat theoretic discussion since every person here will
not want to get bothered by a splash screen unless there is no useful
other screen content, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Juri Linkov]

>> However, when pop-up-frames is non-nil, it would be very annoying to
>> insist on creating a separate frame.  For instance, I use the full-screen
>> single frame configuration which doesn't work with a separate startup frame.
>
> You forget that you are not the target of this feature.  Those who are
> probably won't customize pop-up-frames without also customizing away
> the splash screen.
>
> As for other technical arguments against the separate frame: we have
> enough means in Emacs, I think, to force the splash screen to the
> foreground.

As I understand, there are two goals (not necessarily contradicting)
we are trying to achieve now:

1. Bring the information about Emacs and the GNU project to beginners
   in a way that is hard to miss.
2. Do this in a way that makes no harm to non-beginners.

Creating a separate foreground frame is very annoying since you
need to move the mouse pointer to the [X] button and click on it
before you can start editing a file specified in the command line.
And this feature requires significant efforts and tests to display
a separate frame correctly with different window managers and
configurations.  What a thankless work would be to implement a feature
that will annoy many users.

However, I'm sure this is not how most beginners run Emacs.  Nowadays
most beginners select the Emacs icon from the program menu provided
by the desktop environment, and starting Emacs without command line
arguments already does what you want: it displays a separate single
Emacs frame with the startup screen inside.  So I think we have nothing
to bother about now.

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

Re: New start up splash screen annoyance...

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> As I understand, there are two goals (not necessarily contradicting)
> we are trying to achieve now:
>
> 1. Bring the information about Emacs and the GNU project to beginners
>    in a way that is hard to miss.

So maybe we should display the splash screen only on non-GNU systems :-)

If I installed Emacs on GNU/Linux, Emacs doesn't have to go out of its
tell me about GNU.

> 2. Do this in a way that makes no harm to non-beginners.

Maybe the splash screen on M$ Windoze should read something like this:

  You are currently using a non-free operating system that is specifically
  designed to take away your freedom and put restrictions on what you can
  and cannot do with your computer.

  However, by starting GNU Emacs, you have entered the GNU project's world
  of free software, where the GNU Public License (GPL) protects your freedom
  to use, modify, and distribute software.  

  For more information about the GNU project, type C-h C-p

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

Re: New start up splash screen annoyance...

[David Kastrup]

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

> Juri Linkov <juri@jurta.org> writes:
>
>> As I understand, there are two goals (not necessarily contradicting)
>> we are trying to achieve now:
>>
>> 1. Bring the information about Emacs and the GNU project to beginners
>>    in a way that is hard to miss.
>
> So maybe we should display the splash screen only on non-GNU systems :-)
>
> If I installed Emacs on GNU/Linux, Emacs doesn't have to go out of
> its tell me about GNU.

IIRC, pretty much the main point about the educational messages was to
make ignorant users of GNU aware of what they are using.

Teaching the value of freedom is particularly important to those that
already enjoy it, since they are least likely to cherish it.

>> 2. Do this in a way that makes no harm to non-beginners.
>
> Maybe the splash screen on M$ Windoze should read something like this:
>
>   You are currently using a non-free operating system that is specifically
>   designed to take away your freedom and put restrictions on what you can
>   and cannot do with your computer.
>
>   However, by starting GNU Emacs, you have entered the GNU project's world
>   of free software, where the GNU Public License (GPL) protects your freedom
>   to use, modify, and distribute software.  
>
>   For more information about the GNU project, type C-h C-p

I don't think that we should take the fun out of using Emacs in that
solemn manner on the splash screen.  Using Emacs should be doing more
to let people appreciate freedom than reading the splash screen.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    If I installed Emacs on GNU/Linux, Emacs doesn't have to go out of its
    tell me about GNU.

Yes it does.  Most of the users of those systems think the system is
Linux.  They don't know it is basically GNU.

    Maybe the splash screen on M$ Windoze should read something like this:

      You are currently using a non-free operating system that is specifically
      designed to take away your freedom and put restrictions on what you can
      and cannot do with your computer.

      However, by starting GNU Emacs, you have entered the GNU project's world
      of free software, where the GNU Public License (GPL) protects your freedom
      to use, modify, and distribute software.  

      For more information about the GNU project, type C-h C-p

I like the idea.  It is just a matter of whether we can fit this in
the available space.

Re: New start up splash screen annoyance...

[Richard Stallman]

    What about the demonstration of concept in the patch below?  I think
    popping the splash screen in a separate frame is superior to dividing
    the initial frame, and doing so makes all kinds of complications with
    "concise" splash screen and whether splash should be in upper or lower
    window, a non-issue.  IIRC, Richard agreed to the idea of a separate
    frame.

Can you set it up conditionally on a variable, whose default is nil,
and then install it?  That way we can take a look at both options.

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: juri@jurta.org, emacs-devel@gnu.org
> Date: Sun, 23 Sep 2007 11:05:06 -0400
> 
>     What about the demonstration of concept in the patch below?  I think
>     popping the splash screen in a separate frame is superior to dividing
>     the initial frame, and doing so makes all kinds of complications with
>     "concise" splash screen and whether splash should be in upper or lower
>     window, a non-issue.  IIRC, Richard agreed to the idea of a separate
>     frame.
> 
> Can you set it up conditionally on a variable, whose default is nil,
> and then install it?

Yes.

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sat, 22 Sep 2007 17:11:59 +0300
> Cc: emacs-devel@gnu.org
> 
> I also swapped two windows created after displaying the startup screen
> in Emacs started with a file name, i.e. now when Emacs is started on
> a window system with file name arguments, then the upper window displays
> the last file specified on the command line, and the lower window displays
> the concise version of the startup screen (without logo) plus the
> "Dismiss" button and checkbox.  So the startup screen is less annoying now
> but still is visible, not indirect and persistent.

Btw, the tooltips shown when one moves the mouse to the various links
in the splash screen are not very helpful to newbies.  "Push this
button" doesn't make any sense to someone who doesn't know that the
links are buttons.

Re: New start up splash screen annoyance...

[Juri Linkov]

> Btw, the tooltips shown when one moves the mouse to the various links
> in the splash screen are not very helpful to newbies.  "Push this
> button" doesn't make any sense to someone who doesn't know that the
> links are buttons.

I agree.  It would be better to display more appropriate help echo messages.

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

Re: New start up splash screen annoyance...

[Juri Linkov]

> Btw, the tooltips shown when one moves the mouse to the various links
> in the splash screen are not very helpful to newbies.  "Push this
> button" doesn't make any sense to someone who doesn't know that the
> links are buttons.

Fixed.

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

Re: New start up splash screen annoyance...

[Juri Linkov]

While trying to use the command line option `--no-splash' I noticed one bug:
using it with some other options (for instance, "emacs -debug-init --no-splash")
causes Emacs to fail with the following error message:

command-line-1: Unknown option `-debug-init'

That's because `--no-splash' has a higher priority that options processed
in `command-line', but it is processed later in `command-line-1', thus
preventing options with lower priorities from processing in `command-line'.

The following patch should fix this bug if I understand the priority
system correctly.  It decreases the priority of `--no-splash' to the low
priority 3, but which is higher than the priority 1 of the action options
("-f", "-file", etc) processed in the same function `command-line-1'.
It also adds `--no-desktop' with the same low priority.

Index: src/emacs.c
===================================================================
RCS file: /sources/emacs/emacs/src/emacs.c,v
retrieving revision 1.407
diff -u -r1.407 emacs.c
--- src/emacs.c	29 Aug 2007 05:27:54 -0000	1.407
+++ src/emacs.c	22 Sep 2007 22:52:18 -0000
@@ -1822,7 +1822,6 @@
   { "-q", "--no-init-file", 50, 0 },
   { "-no-init-file", 0, 50, 0 },
   { "-no-site-file", "--no-site-file", 40, 0 },
-  { "-no-splash", "--no-splash", 40, 0 },
   { "-u", "--user", 30, 1 },
   { "-user", 0, 30, 1 },
   { "-debug-init", "--debug-init", 20, 0 },
@@ -1857,6 +1856,8 @@
   { "-hb", "--horizontal-scroll-bars", 5, 0 },
   { "-vb", "--vertical-scroll-bars", 5, 0 },
   { "-color", "--color", 5, 0},
+  { "-no-splash", "--no-splash", 3, 0 },
+  { "-no-desktop", "--no-desktop", 3, 0 },
   /* These have the same priority as ordinary file name args,
      so they are not reordered with respect to those.  */
   { "-L", "--directory", 0, 1 },

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

Re: New start up splash screen annoyance...

[Juri Linkov]

There was a criticism on this thread in regard to inconsistence of the new
user option `initial-buffer-choice'.  I now realized what is wrong and how
to fix this inconsistence.

This option can't coexist with `inhibit-startup-screen' because it mostly
duplicates the purpose of `inhibit-startup-screen' and thus causes confusion.

Much better would be to remove this new user option, and allow string values
in `inhibit-startup-screen'.  So if its value is a string then instead of
displaying the startup screen, visit the specified file or directory using
the same logic of displaying the startup screen window (taking into account
command line arguments, etc.)  The value t completely inhibits the
startup screen.  A special value for displaying the *scratch* buffer is
not needed, because when `inhibit-startup-screen' is t, the *scratch* buffer
is displayed anyway as the last buffer created on the Emacs startup.

Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.460
diff -c -r1.460 startup.el
*** lisp/startup.el	22 Sep 2007 14:02:26 -0000	1.460
--- lisp/startup.el	22 Sep 2007 22:11:00 -0000
***************
*** 47,72 ****
    "Emacs start-up procedure."
    :group 'environment)
  
- (defcustom initial-buffer-choice nil
-   "Buffer to show after starting Emacs.
- If the value is nil and `inhibit-startup-screen' is nil, show the
- startup screen.  If the value is string, visit the specified file or
- directory using `find-file'.  If t, open the `*scratch*' buffer."
-   :type '(choice
- 	  (const     :tag "Startup screen" nil)
- 	  (directory :tag "Directory" :value "~/")
- 	  (file      :tag "File" :value "~/file.txt")
- 	  (const     :tag "Lisp scratch buffer" t))
-   :version "23.1"
-   :group 'initialization)
- 
  (defcustom inhibit-startup-screen nil
    "Non-nil inhibits the startup screen.
  It also inhibits display of the initial message in the `*scratch*' buffer.
  
  This is for use in your personal init file (but NOT site-start.el), once
  you are familiar with the contents of the startup screen."
!   :type 'boolean
    :group 'initialization)
  
  (defvaralias 'inhibit-splash-screen 'inhibit-startup-screen)
--- 47,69 ----
    "Emacs start-up procedure."
    :group 'environment)
  
  (defcustom inhibit-startup-screen nil
    "Non-nil inhibits the startup screen.
  It also inhibits display of the initial message in the `*scratch*' buffer.
  
+ If the value is nil, show the startup screen.  If the value is string,
+ then instead of displaying the startup screen visit the specified file
+ or directory using `find-file'.  If the value is t, then completely
+ inhibit any special display, thus leave Emacs showing the buffer that
+ happens to be the last visited buffer after the Emacs startup procedure.
+ 
  This is for use in your personal init file (but NOT site-start.el), once
  you are familiar with the contents of the startup screen."
!   :type '(choice
! 	  (const     :tag "Startup screen" nil)
! 	  (directory :tag "Directory" :value "~/")
! 	  (file      :tag "File" :value "~/file.txt")
! 	  (const     :tag "No startup screen" t))
    :group 'initialization)
  
  (defvaralias 'inhibit-splash-screen 'inhibit-startup-screen)
***************
*** 1904,1914 ****
  
  If CONCISE is non-nil, display a concise version of the startup
  screen."
!   ;; Prevent recursive calls from server-process-filter.
!   (if (not (get-buffer "*GNU Emacs*"))
!       (if (use-fancy-splash-screens-p)
!       	  (fancy-startup-screen concise)
!       	(normal-splash-screen t))))
  
  (defun display-about-screen ()
    "Display the *About GNU Emacs* buffer.
--- 1901,1917 ----
  
  If CONCISE is non-nil, display a concise version of the startup
  screen."
!   (cond
!    ((stringp inhibit-startup-screen)
!     (if concise
! 	(display-buffer (find-file-noselect inhibit-startup-screen))
!       (find-file inhibit-startup-screen)))
!    ((null inhibit-startup-screen)
!     ;; Prevent recursive calls from server-process-filter.
!     (if (not (get-buffer "*GNU Emacs*"))
! 	(if (use-fancy-splash-screens-p)
! 	    (fancy-startup-screen concise)
! 	  (normal-splash-screen t))))))
  
  (defun display-about-screen ()
    "Display the *About GNU Emacs* buffer.
***************
*** 2139,2152 ****
  	    ;; abort later.
  	    (unless (frame-live-p (selected-frame)) (kill-emacs nil))))))
  
!     (when initial-buffer-choice
!       (cond ((eq initial-buffer-choice t)
! 	     (switch-to-buffer (get-buffer-create "*scratch*")))
! 	    ((stringp initial-buffer-choice)
! 	     (find-file initial-buffer-choice))))
! 
!     (if (or inhibit-startup-screen
! 	    initial-buffer-choice
  	    noninteractive
  	    emacs-quick-startup)
  
--- 2142,2148 ----
  	    ;; abort later.
  	    (unless (frame-live-p (selected-frame)) (kill-emacs nil))))))
  
!     (if (or (eq inhibit-startup-screen t)
  	    noninteractive
  	    emacs-quick-startup)

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

Re: New start up splash screen annoyance...

[Richard Stallman]

Please do not make the change.  I think the current code is basically
right.  `inhibit-startup-screen' would be the wrong name for a variable
with all those options.  Having the two variables is not a bad thing.

The idea to change the meaning of t would be ok, but the doc should
add that this normally shows the *scratch* buffer.

Re: New start up splash screen annoyance...

[Juri Linkov]

> Please do not make the change.  I think the current code is basically
> right.  `inhibit-startup-screen' would be the wrong name for a variable
> with all those options.  Having the two variables is not a bad thing.

There is only one additional option type - a string that specifies what
file or directory to visit instead of the startup screen.  So its
semantics is to say how to inhibit the startup screen - by displaying
a file or directory instead.

> The idea to change the meaning of t would be ok, but the doc should
> add that this normally shows the *scratch* buffer.

My previous patch doesn't change the meaning of t of the variable
`inhibit-startup-screen'.  t still inhibits the startup screen completely,
and this fact could be documented in its doc string.

I think one variable is less confusion.  However, if you still want two
variables, then I think the second variable should be renamed to e.g.
`startup-screen-choice' because I now realized that displaying a file
or directory instead of the startup screen should follow the logic of
displaying the startup screen, i.e. when Emacs is started with a file name
command line argument then even if configured to display a home directory,
it still should visit the specified file instead.  So the command line
should have a priority over the option, because by using the command line
the user overrides the option.

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

Re: New start up splash screen annoyance...

[Richard Stallman]

    There is only one additional option type - a string that specifies what
    file or directory to visit instead of the startup screen.  So its
    semantics is to say how to inhibit the startup screen - by displaying
    a file or directory instead.

I don't look at it that way.  Please let it drop.

Re: New start up splash screen annoyance...

[Richard Stallman]

    I also swapped two windows created after displaying the startup screen
    in Emacs started with a file name, i.e. now when Emacs is started on
    a window system with file name arguments, then the upper window displays
    the last file specified on the command line, and the lower window displays
    the concise version of the startup screen (without logo) plus the
    "Dismiss" button and checkbox.  So the startup screen is less annoying now
    but still is visible, not indirect and persistent.

Thanks.

Re: New start up splash screen annoyance...

[Sean O'Rourke]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> Glenn Morris <rgm@gnu.org> writes:
>> Umm, that's exactly how it works now.
>
> Not that I can see.  [...]

Sorry for the noise.  My Emacs was about 2 weeks out of date.
The latest code implements my preferred behavior.

/s

Re: New start up splash screen annoyance...

[Manoj Srivastava]

On Thu, 20 Sep 2007 20:35:58 +0200, David Kastrup <dak@gnu.org> said: 

> Manoj Srivastava <srivasta@ieee.org> writes:
>> On Thu, 20 Sep 2007 13:16:16 +0200, Kim F Storm <storm@cua.dk> said:
>> 
>>> AFAICS, the only thing we can do to prevent that is to find a
>>> reasonably non-annoying way to "say what we want to say".
>> 
>> I am not sure I understand this viewpoint. I have been using Emacs
>> since '88, so I am pretty "seasoned" -- but I don't seem to see the
>> issue you are raising; and I am wondering if we are looking at the
>> same thing.

> Just to make sure we are: we are talking about the case where Emacs is
> called with explicit file names given on the command line and instead
> of displaying those files displays the splash screen.

>> What I saw was a splash screen -- but it came with a nice _dismiss_
>> button, and even a checkbox that said "don't show this again".  This
>> is not much of an annoyance -- since it only ever appears once,

> Per session.

        Hmm. I am seeing two different behaviours here, which might be
 the cause of some confusion.  When I just call:
  % emacs /tmp/foo.sh
 I get a split screen; the top half has a splash screen, with these
 lines at the bottom:
--8<---------------cut here---------------start------------->8---
If an Emacs session crashed recently, type Meta-x recover-session RET
to recover the files you were editing.

Dismiss   [] Don't show this message again.
--8<---------------cut here---------------end--------------->8---
 The bottom half has the /tmp/foo.sh buffer.

        I imagine that if I check the box, and then it dismiss, I'll
 never see the splash again.

        Now, if I start emacs -nw,
  % emacs -nw /tmp/bar.sh
 I am still getting the split again, except that there does not seem to
 be a dismiss button, nor is there a checkbox.

        So, I find the X based splash screen not to be an annoyance; but
 I do find the emacs -nw splash screen deficient.

        This is the latest CVS emacs in Miles Bader's GNU/Arch mirror.

        Is this the behaviour you see?

>> As someone who has influence with one of the much despised GNU/Linux
>> distribution makers, I can say your fears are somewhat overblown.

> As long as we are talking about the same thing.  Are we?

        Well, I think turning off the splash screen for Debian is not
 something that will happen very readily.

        manoj
-- 
On-line, adj.: The idea that a human being should always be accessible
to a computer.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: New start up splash screen annoyance...

[Richard Stallman]

	    So, I find the X based splash screen not to be an annoyance; but
     I do find the emacs -nw splash screen deficient.

We can turn off the splash screen on ttys when file arguments are
specified.  Would someone like to implement that?

Re: New start up splash screen annoyance...

[Juri Linkov]

> 	    So, I find the X based splash screen not to be an annoyance; but
>      I do find the emacs -nw splash screen deficient.
>
> We can turn off the splash screen on ttys when file arguments are
> specified.  Would someone like to implement that?

Done.

The splash screen is turned off on ttys, as well as after starting Emacs
with command line options "-f", "-funcall", "-e", "-eval", "-execute",
"-insert", "-find-file", "-file", "-visit", because beginners don't start
Emacs with these arguments.  So now Emacs displays the startup screen
only when started with a file name like "emacs FILE..." on a window system.

This required to change the echo area startup message from

For information about the GNU system and GNU/Linux, type C-h C-p.

to

For information about GNU Emacs and the GNU system, type C-h C-a.

where C-h C-a is used to display the About screen which contains links
to the description of the GNU project, GNU/Linux operating system
and other help information.

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

Re: New start up splash screen annoyance...

[Richard Stallman]

    > We can turn off the splash screen on ttys when file arguments are
    > specified.  Would someone like to implement that?

    Done.

    The splash screen is turned off on ttys, as well as after starting Emacs
    with command line options "-f", "-funcall", "-e", "-eval", "-execute",
    "-insert", "-find-file", "-file", "-visit", because beginners don't start
    Emacs with these arguments.  So now Emacs displays the startup screen
    only when started with a file name like "emacs FILE..." on a window system.

You went a little too far.  Starting Emacs on a tty with no arguments
SHOULD show the startup screen.

Would someone please fix that, then ack?

    This required to change the echo area startup message from

    For information about the GNU system and GNU/Linux, type C-h C-p.

    to

    For information about GNU Emacs and the GNU system, type C-h C-a.

Please change that back.

Re: New start up splash screen annoyance...

[Juri Linkov]

> You went a little too far.  Starting Emacs on a tty with no arguments
> SHOULD show the startup screen.

Yes, this is exactly as it already works now: starting Emacs on a tty
with no arguments shows the startup screen.  I don't understand why this
doesn't work for you.

>     This required to change the echo area startup message from
>
>     For information about the GNU system and GNU/Linux, type C-h C-p.
>
>     to
>
>     For information about GNU Emacs and the GNU system, type C-h C-a.
>
> Please change that back.

I'm surprised that you don't want to direct users to the About screen
that provides more information about Emacs, GNU/Linux and the GNU system.
Or perhaps I misunderstood you and really you want to change only text back
to the old text but with a new keybinding that displays the About screen:

For information about the GNU system and GNU/Linux, type C-h C-a.
                                                         =======

Please confirm is it what you want?

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

Re: New start up splash screen annoyance...

[Richard Stallman]

    > You went a little too far.  Starting Emacs on a tty with no arguments
    > SHOULD show the startup screen.

    Yes, this is exactly as it already works now: starting Emacs on a tty
    with no arguments shows the startup screen.

That is good.

						 I don't understand why this
    doesn't work for you.

I didn't try it myself, I just believed your message:

    The splash screen is turned off on ttys, as well as after starting Emacs
    with command line options "-f", "-funcall", "-e", "-eval", "-execute",
    "-insert", "-find-file", "-file", "-visit", because beginners don't start
    Emacs with these arguments.  So now Emacs displays the startup screen
    only when started with a file name like "emacs FILE..." on a window system.

I tried it now, and it seems to be good.

I guess the echo area change is ok.  So you don't have to undo it.

Re: New start up splash screen annoyance...

[Juri Linkov]

>     The splash screen is turned off on ttys, as well as after starting Emacs
>     with command line options "-f", "-funcall", "-e", "-eval", "-execute",
>     "-insert", "-find-file", "-file", "-visit", because beginners don't start
>     Emacs with these arguments.  So now Emacs displays the startup screen
>     only when started with a file name like "emacs FILE..." on a window system.
>
> I tried it now, and it seems to be good.
>
> I guess the echo area change is ok.  So you don't have to undo it.

Please confirm should the same changes be made in Emacs-22?  There were
complaints about the undesired behavior of the startup screen in the
released version.  It would be good to fix this for Emacs-22.2.

What would be the minimal set of necessary changes for the Emacs-22 branch?
To turn the startup screen off on ttys, turn it off with non-file action command
line arguments, something more?

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

Re: New start up splash screen annoyance...

[Richard Stallman]

    What would be the minimal set of necessary changes for the Emacs-22 branch?
    To turn the startup screen off on ttys,

That is too far!  The startup screen should be displayed
on ttys when there are no arguments!

					    turn it off with non-file action command
    line arguments, something more?

Once all these changes have settled down, in a week or so,
it is ok to put them all into Emacs 22, if you make sure
you really got them all.

Re: New start up splash screen annoyance...

[Juri Linkov]

>     What would be the minimal set of necessary changes for the Emacs-22 branch?
>     To turn the startup screen off on ttys,
>
> That is too far!  The startup screen should be displayed
> on ttys when there are no arguments!

Sorry for the incompleteness of my statement, but I meant exactly the same.

> 					    turn it off with non-file action command
>     line arguments, something more?
>
> Once all these changes have settled down, in a week or so,
> it is ok to put them all into Emacs 22, if you make sure
> you really got them all.

OK.

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

Re: New start up splash screen annoyance...

[Mathias Megyei]

Richard Stallman writes:
 >     Is your mind made up that this is the way Emacs must behave, or are
 >     there any arguments that might change your mind?
 > 
 > My mind is made up that we must arrange that beginners who always
 > specify a file name argument mostly do see the splash screen
 > information.  I'm willing to consider other ways of doing that
 > as long as I think they are effective.

I've seen a couple of new Emacs users the last 17 years.
After few month all of them have begun to start Emacs without
file name argument, when they have learned to use more features
(dired for instance).

Does it really matter if they see the splash screen few month
after the first start of Emacs?
Or do you think my experience with new users is not the usual
case?

Re: New start up splash screen annoyance...

[Richard Stallman]

    I've seen a couple of new Emacs users the last 17 years.
    After few month all of them have begun to start Emacs without
    file name argument, when they have learned to use more features
    (dired for instance).

I don't know what fraction of Emacs users learn this.

Re: New start up splash screen annoyance...

[Bill Wohler]

Following on Lars example, *any* command which uses EDITOR or VISUAL
or DISPLAY will run "emacs <file>".

Or, consider running "emacs file -f do-something-with-current-buffer".
The do-something-with-current-buffer function would rather operate on
`file' than the splash screen.

Richard Stallman <rms@gnu.org> writes:

> I won't give in to bullying, so you may as well stop it.

Perhaps you can suggest how we can persuade you. Sheer numbers and
overwhelming counter-examples do not seem to be enough: Only two
people on this list do not think that "emacs <file>" is as legitimate
as "emacs" in the first place, which is the root of the problem.

A splash screen that occludes the work that a beginner wants to do
will only confuse them, annoy long-time Emacs users, and break things
as noted above. A separate frame or tooltip (with a Don't show me this
again checkbox or other clear way to stop it) or a line or two in the
minibuffer in a tty or not at all with the -nw option would be fine
alternatives.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: New start up splash screen annoyance...

[Richard Stallman]

    Perhaps you can suggest how we can persuade you. Sheer numbers and
    overwhelming counter-examples do not seem to be enough:

What a condescending and insulting thing to say!  If I don't agree
with you, you have no right to make me agree.  If you try, you will
only make me angry at you.

One thing you might be able to do -- if you want to -- is propose
another solution that I find good enough.  That would mean working
with me instead of trying to pressure me.  It would mean accepting the
goal I'm trying to achieve, instead of trying make me drop it.

You can't do both--you have to choose one path or the other.  But the
path of "how can I persuade you" will not get you anywhere.

I will continue to consider new proposals, when they represent serious
attempts to work with me to find a solution, and are stated without
derision, bullying, pressure, quibbling, etc.

Re: New start up splash screen annoyance...

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Mon, 17 Sep 2007 18:24:22 -0400

       Unfortunately, it isn't an exaggeration.

   You're taking a hostile tack which I consider unjust, so I will not
   give weight to whatever is based on it.  You may as well not repeat
   it.

a good hint is strong but oblique.  if it is not strong, it is
missed.  if it is not oblique, it is refuted.

here's another idea:

startup-echo-area-message is displayed even w/ a FILE specified on
the command line (iirc -- if not, we can make it do so again).  so
the mechanism to implement "always show the user a hint" can be
extended like so:

(global-set-key "\C-h\C-a" 'display-splash-screen)

(defun startup-echo-area-message ()
  (let ((fyi "For information about ")
        (gnu (if (eq (key-binding "\C-h\C-p") 'describe-project)
                 "C-h C-p"
               (substitute-command-keys "\\[describe-project]"))) 
        (emacs (if (eq (key-binding "\C-h\C-a") 'display-splash-screen)
                   "C-h C-a"
                 (substitute-command-keys "\\[display-splash-screen]")))
        (type ", type "))
    (concat fyi "the GNU system and GNU/Linux" type gnu ".\n"
            fyi "GNU Emacs" type emacs ".")))

in this way we show contemporaneously the FILE to be edited as
well as all the hints we wish to give.  true, there are two lines
in the echo area, which may disturb some people when the mode line
moves down on keypress, but i think that's livable.

thi

Re: New start up splash screen annoyance...

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>     I find that that's what I'm looking for, and I type
>
>     # emacs M-.
>
> That is something an advanced user will do occasionally.
> Advanced users can easily turn off the splash screen.

This is something I do when sysadmining.  I'd have to alter root's
.emacs file on all the 80+ GNU Linux machines we have here to get rid of
the splash screen.

I just feel that this change is kinda annoying, and I think it's going
to be annoying (and confusing) for lots of people who have a similar
usage pattern.  (I.e., people who don't use Emacs for programming or
writing big texts, but people who ssh to a machine, do a tiny tweak to a
specific file, and then log out again.  Which is typical when doing
sysadmin tasks.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New start up splash screen annoyance...

[Davis Herring]

> There are nonetheless beginners who habitually run Emacs with a file
> name argument, and would never see the splash screen if it only
> appeared with no argument.  The reason I made that change is that
> I discovered this phenomenon.

How are there (Emacs) beginners who "habitually run Emacs" at all?  In any
case, one could make the splash screen appear regardless the very first
time Emacs were run, in that if no .emacs were present it would
automatically write one that suppressed the splash-screen-with-arguments
behavior.

Of course, even that test is imperfect; borrowing someone else's machine
or account for whatever reason does not make one a beginner.  And creating
files without being asked is not very good behavior.  But neither is
making it inordinately difficult to edit a file.

Davis

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

RE: New start up splash screen annoyance...

[Drew Adams]

> one could make the splash screen appear regardless the very first
> time Emacs were run, in that if no .emacs were present it would
> automatically write one that suppressed the splash-screen-with-arguments
> behavior.

Yes, the splash screen is useful for a first use of Emacs, and its
usefulness diminishes over time.

FWIW, I do something similar to give new Icicles users a help reminder in
the prompt. It is there only for N Emacs sessions, but a user can override
this behavior. FWIW, this is what I do:

(defcustom icicle-reminder-prompt-flag 7
  "*Whether to include a help reminder in minibuffer prompt.
nil means never use the reminder.
Non-nil means use the reminder, if space permits:
 An integer value means use only for that many Emacs sessions.
 t means always use it."
  :type
  '(choice
    (const   :tag "Never use a reminder in the prompt" nil)
    (const   :tag "Always use a reminder in the prompt" t)
    (integer :tag "Use a reminder in the prompt for this sessions"
             :value 7))
  :group 'Icicles-Minibuffer-Display)

Icicle minor mode then adds/removes `icicle-control-reminder-prompt' to/from
`kill-emacs-hook'.

(defun icicle-control-reminder-prompt ()
  "If `icicle-reminder-prompt-flag' > 0, decrement it and save it.
Used in `kill-emacs-hook'."
  (when (and (wholenump icicle-reminder-prompt-flag)
             (> icicle-reminder-prompt-flag 0))
    (condition-case nil ; Because it's on `kill-emacs-hook.
        (customize-save-variable
          'icicle-reminder-prompt-flag
          (1- icicle-reminder-prompt-flag))
      (error nil))))

Re: New start up splash screen annoyance...

[David Kastrup]

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

>> one could make the splash screen appear regardless the very first
>> time Emacs were run, in that if no .emacs were present it would
>> automatically write one that suppressed the splash-screen-with-arguments
>> behavior.
>
> Yes, the splash screen is useful for a first use of Emacs, and its
> usefulness diminishes over time.
>
> FWIW, I do something similar to give new Icicles users a help reminder in
> the prompt. It is there only for N Emacs sessions, but a user can override
> this behavior. FWIW, this is what I do:
>
> (defcustom icicle-reminder-prompt-flag 7

I don't think that is a good idea: the user can very well skip the
screen and decide "I'll read this next time when I need it".  How
often he will skip it before reading it, we can't know.

We should really try finding a behavior that will put the information
in obvious and easy reach to the user every time, and won't be
annoying.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[dhruva]

Hi,

On 9/18/07, David Kastrup <dak@gnu.org> wrote:
> We should really try finding a behavior that will put the information
> in obvious and easy reach to the user every time, and won't be
> annoying.

It may sound crazy but.... Once we have tiling Emacs, we could set all
the information we want as a background image and make the
transparency increase progressively (maybe between days instead of
invocations) and finally fade off (unless turned off/on explicitly
through dotemacs).

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: New start up splash screen annoyance...

[Mathias Megyei]

Richard Stallman writes:
 >     There are cases where starting Emacs with a file name command line argument
 >     is fully justified: for instance, logging into a remote computer only to
 >     fix one config file.  Many users preferred using vi for such tasks because
 >     vi was faster to start.  However, on modern hardware emacs startup time is
 >     comparable to vi.
 > 
 > When I want to do this, I start Emacs and then visit the file.
 > What's the advantage of specifying the file name as a command arg?

 It saves key strokes.

 Eg. to compare two log files with ediff-buffers.
 (Our log files at work are sometimes really big, loading them
 one by one is much less convenient than typing
 emacs FILE FILE2. Until emacs has finished loading them the user
 can do something else.)

Another example: One experienced Emacs user at work often starts
Emacs with 3 or more arguments when he's starting to work in a
specific project evironment, because he knows, he will work on
all that files the next hours.

Mathias

Ps: I like the new splash screen.

PPs: The splash screen doesn't show up, when Emacs is started
     with the '-f' option and a non-existing name.
     Eg: emacs <file> -f grhrjr.
     Is this supposed to be a workaround of the "splash screen
     annoyance"? ;-)

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Mathias Megyei <mathias@mnet-mail.de>
> Date: Sat, 15 Sep 2007 12:17:23 +0200
> Cc: Juri Linkov <juri@jurta.org>, wilde@sha-bang.de, hannes@saeurebad.de,
> 	emacs-devel@gnu.org
> 
>  > When I want to do this, I start Emacs and then visit the file.
>  > What's the advantage of specifying the file name as a command arg?
> 
>  It saves key strokes.

You mean, the 1-key SPC vs the 3-key "C-x C-f"?  I think these savings
are too small to be significant.

>  (Our log files at work are sometimes really big, loading them
>  one by one is much less convenient than typing
>  emacs FILE FILE2. Until emacs has finished loading them the user
>  can do something else.)

Don't those log files have something in common enough for specifying a
single wildcard argument to "C-x C-f"?

> Another example: One experienced Emacs user at work often starts
> Emacs with 3 or more arguments when he's starting to work in a
> specific project evironment, because he knows, he will work on
> all that files the next hours.

The same can be accomplished by C-x C-f from inside a running Emacs.

Re: New start up splash screen annoyance...

[Mathias Megyei]

Hello Eli,

[I think you're doing a great job for Emacs and for the Emacs
 community. Thank you very much.
 Writing in english isn't easy for me. It takes time. Sometimes I
 don't find the right words and don't explain enough or clear.
 I would like to ask please don't assume I'm stupid or I don't
 use Emacs in an efficient way.]

Eli Zaretskii writes:
 > > From: Mathias Megyei <mathias@mnet-mail.de>
 > > Date: Sat, 15 Sep 2007 12:17:23 +0200
 > > Cc: Juri Linkov <juri@jurta.org>, wilde@sha-bang.de, hannes@saeurebad.de,
 > > 	emacs-devel@gnu.org
 > > 
 > >  > When I want to do this, I start Emacs and then visit the file.
 > >  > What's the advantage of specifying the file name as a command arg?
 > > 
 > >  It saves key strokes.

 It saves key strokes _and_ time (which is even more important).

 > You mean, the 1-key SPC vs the 3-key "C-x C-f"?  I think these savings
 > are too small to be significant.

 No. See above and below.

 > >  (Our log files at work are sometimes really big, loading them
 > >  one by one is much less convenient than typing
 > >  emacs FILE FILE2. Until emacs has finished loading them the user
 > >  can do something else.)
 > 
 > Don't those log files have something in common enough for specifying a
 > single wildcard argument to "C-x C-f"?

Sometimes. Often the file names are identical but are located in
completely different directories. (One file is in the workspace
of a different user or belongs to a related but different
project....)
When the user starts Emacs with file argument then he has already
some information about the file. Perhaps the file is already
available via shell features.
(Eg. perhaps he can use M-. (yank-last-arg) in Bash to get the
 path, which is much shorter than typing the
 absolute path after C-x C-f even using completion.)

There are many possiblities how pathnames are easy available
outside Emacs. Eg. by using Bash functions, Git user know about
'git ls-files', etc. Why shouldn't someone start Emacs with file
argument when he has the file more easily available in the shell?
(Of course we're using these tools in a *shell* buffer when we
have an Emacs already running in the right environment.)

 > > Another example: One experienced Emacs user at work often starts
 > > Emacs with 3 or more arguments when he's starting to work in a
 > > specific project evironment, because he knows, he will work on
 > > all that files the next hours.
 > 
 > The same can be accomplished by C-x C-f from inside a running Emacs.

Sigh. We're working on different projects. Each project has its
own environment. We have to start Emacs in the right project
environment in order to have write access to the project's data.
(In some cases we need to start Emacs in the right project
environment even for read access.)

We often use Bash functions to setup specific project environment
_and_ start Emacs. (Useful option for Emacs is to load the
project specific bookmark file.)
When I start the Bash function with name of the logfile that is
passed to Emacs, I can continue my previous work. When I come
back to this Emacs and see the splash screen, then I have to
think why did I start this Emacs?

We also use a batch-queuing system (SGE from Sun) to start
applications with specific needs on suitable hosts.
Sometimes we need to look at or even edit files with size of 300
or 400 MBs. This cannot be done on the local host with 1 GB
memory running 32 bit linux.
When the user submits his (interactive) job it takes several
seconds, a minute until the job gets started.

The workflow you're proposing would be in this case:
- submit Emacs job
- wait several seconds
- C-x C-f FILE
- wait longer

Our workflow is:
- submit Emacs with FILE as argument
- do something else
- come back to this Emacs if you have finished the other task

The "good habit" in Emacs' sense requires 2 user actions with
delay in between. It is less efficient than our usage.

Best Regards,

Mathias

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> From: Mathias Megyei <mathias@mnet-mail.de>
> Date: Sat, 15 Sep 2007 20:55:55 +0200
> Cc: rms@gnu.org,juri@jurta.org,wilde@sha-bang.de,hannes@saeurebad.de,emacs-devel@gnu.org
> 
> There are many possiblities how pathnames are easy available
> outside Emacs. Eg. by using Bash functions, Git user know about
> 'git ls-files', etc. Why shouldn't someone start Emacs with file
> argument when he has the file more easily available in the shell?

Well, if you build a lot on top of shell features, then it's clear why
you would prefer file arguments from the command line.

Me, I live inside Emacs and build almost everything on its features.
Starting Emacs without arguments is so hardwired into my brain that I
don't even think of any other possibility.

Which doesn't mean I like the current CVS behavior of displaying the
splash screen when a file argument was given.  I think I stated my
opinions on this well enough in this thread.

> When I come back to this Emacs and see the splash screen, then I
> have to think why did I start this Emacs?

As I said, I, too, don't like this behavior.

> We also use a batch-queuing system (SGE from Sun) to start
> applications with specific needs on suitable hosts.
> Sometimes we need to look at or even edit files with size of 300
> or 400 MBs. This cannot be done on the local host with 1 GB
> memory running 32 bit linux.
> When the user submits his (interactive) job it takes several
> seconds, a minute until the job gets started.
> 
> The workflow you're proposing would be in this case:
> - submit Emacs job
> - wait several seconds
> - C-x C-f FILE
> - wait longer

No.  For these use cases, I'd use emacsclient, and leave Emacs running
at all times.

But again, those are _my_ habits; YMMV.  We don't have to agree on
habits.

Re: New start up splash screen annoyance...

[Richard Stallman]

     > The same can be accomplished by C-x C-f from inside a running Emacs.

    Sigh. We're working on different projects. Each project has its
    own environment. We have to start Emacs in the right project
    environment in order to have write access to the project's data.
    (In some cases we need to start Emacs in the right project
    environment even for read access.)

That is very strange.  Could you explain?

It ought to be possible to use the same Emacs for multiple
projects, and if it is not, we should try to do something about that.

    The workflow you're proposing would be in this case:
    - submit Emacs job
    - wait several seconds
    - C-x C-f FILE
    - wait longer

No, I'm proposing that you always have an Emacs running, so when you
want to use it you can connect to it.

I am surprised by the clever uses that a few of you have found for
file name args, but that isn't really relevant to the issue.  You're
an experienced user, and you have seen the info in the splash screen.
If you don't want it to appear, turn it off.

Re: New start up splash screen annoyance...

[Mathias Megyei]

Richard Stallman writes:
 >      > The same can be accomplished by C-x C-f from inside a running Emacs.
 > 
 >     Sigh. We're working on different projects. Each project has its
 >     own environment. We have to start Emacs in the right project
 >     environment in order to have write access to the project's data.
 >     (In some cases we need to start Emacs in the right project
 >     environment even for read access.)
 > 
 > That is very strange.  Could you explain?
 > 
 > It ought to be possible to use the same Emacs for multiple
 > projects, and if it is not, we should try to do something
 > about that.

Our projects are organized in directory trees. For security
reasons the root directory of each project is protected by ACLs.
Write access is limited to the member of the projects' group.
When somebody starts working on a project he has to start a setup
script. This starts new shell, sets the projects' group to the
primary group, and sets several environment variables.
Then the user normally starts an Emacs and keeps it running until
he has to reboot his computer.

 >     The workflow you're proposing would be in this case:
 >     - submit Emacs job
 >     - wait several seconds
 >     - C-x C-f FILE
 >     - wait longer
 > 
 > No, I'm proposing that you always have an Emacs running, so when you
 > want to use it you can connect to it.

Yes we do so whenever it is possible. The above lines describe
the situation when we don't have an Emacs running on a 64 bit
host.

Re: New start up splash screen annoyance...

[Richard Stallman]

    Our projects are organized in directory trees. For security
    reasons the root directory of each project is protected by ACLs.
    Write access is limited to the member of the projects' group.
    When somebody starts working on a project he has to start a setup
    script. This starts new shell, sets the projects' group to the
    primary group, and sets several environment variables.
    Then the user normally starts an Emacs and keeps it running until
    he has to reboot his computer.

It must be rather inconvenient to have to run multiple Emacs jobs
if you are working on different projects.  If you can think
of Emacs changes that would enable you to avoid that, we could
consider them.

Re: New start up splash screen annoyance...

[Mathias Megyei]

Hello Eli,

[I think you're doing a great job for Emacs and for the Emacs
 community. Thank you very much.
 Writing in english isn't easy for me. It takes time. Sometimes I
 don't find the right words and don't explain enough or clear.
 I would like to ask please don't assume I'm stupid or I don't
 use Emacs in an efficient way.]

Eli Zaretskii writes:
 > > From: Mathias Megyei <mathias@mnet-mail.de>
 > > Date: Sat, 15 Sep 2007 12:17:23 +0200
 > > Cc: Juri Linkov <juri@jurta.org>, wilde@sha-bang.de, hannes@saeurebad.de,
 > > 	emacs-devel@gnu.org
 > > 
 > >  > When I want to do this, I start Emacs and then visit the file.
 > >  > What's the advantage of specifying the file name as a command arg?
 > > 
 > >  It saves key strokes.

 It saves key strokes _and_ time (which is even more important).

 > You mean, the 1-key SPC vs the 3-key "C-x C-f"?  I think these savings
 > are too small to be significant.

 No. See above and below.

 > >  (Our log files at work are sometimes really big, loading them
 > >  one by one is much less convenient than typing
 > >  emacs FILE FILE2. Until emacs has finished loading them the user
 > >  can do something else.)
 > 
 > Don't those log files have something in common enough for specifying a
 > single wildcard argument to "C-x C-f"?

Sometimes. Often the file names are identical but are located in
completely different directories. (One file is in the workspace
of a different user or belongs to a related but different
project....)
When the user starts Emacs with file argument then he has already
some information about the file. Perhaps the file is already
available via shell features.
(Eg. perhaps he can use M-. (yank-last-arg) in Bash to get the
 path, which is much shorter than typing the
 absolute path after C-x C-f even using completion.)

There are many possiblities how pathnames are easy available
outside Emacs. Eg. by using Bash functions, Git user know about
'git ls-files', etc. Why shouldn't someone start Emacs with file
argument when he has the file more easily available in the shell?
(Of course we're using these tools in a *shell* buffer when we
have an Emacs already running in the right environment.)

 > > Another example: One experienced Emacs user at work often starts
 > > Emacs with 3 or more arguments when he's starting to work in a
 > > specific project evironment, because he knows, he will work on
 > > all that files the next hours.
 > 
 > The same can be accomplished by C-x C-f from inside a running Emacs.

Sigh. We're working on different projects. Each project has its
own environment. We have to start Emacs in the right project
environment in order to have write access to the project's data.
(In some cases we need to start Emacs in the right project
environment even for read access.)

We often use Bash functions to setup specific project environment
_and_ start Emacs. (Useful option for Emacs is to load the
project specific bookmark file.)
When I start the Bash function with name of the logfile that is
passed to Emacs, I can continue my previous work. When I come
back to this Emacs and see the splash screen, then I have to
think why did I start this Emacs?

We also use a batch-queuing system (SGE from Sun) to start
applications with specific needs on suitable hosts.
Sometimes we need to look at or even edit files with size of 300
or 400 MBs. This cannot be done on the local host with 1 GB
memory running 32 bit linux.
When the user submits his (interactive) job it takes several
seconds, a minute until the job gets started.

The workflow you're proposing would be in this case:
- submit Emacs job
- wait several seconds
- C-x C-f FILE
- wait longer

Our workflow is:
- submit Emacs with FILE as argument
- do something else
- come back to this Emacs if you have finished the other task

The "good habit" in Emacs' sense requires 2 user actions with
delay in between. It is less efficient than our usage.

Best Regards,

Mathias

Re: New start up splash screen annoyance...

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Sep 15, 2007 at 01:40:53PM +0300, Eli Zaretskii wrote:
> > From: Mathias Megyei <mathias@mnet-mail.de>

[...]

> >  > When I want to do this, I start Emacs and then visit the file.
> >  > What's the advantage of specifying the file name as a command arg?
> > 
> >  It saves key strokes.
> 
> You mean, the 1-key SPC vs the 3-key "C-x C-f"?  I think these savings
> are too small to be significant.

To elaborate Mathias's point (he expressed it as "save time", but I
think the core is still unclear), it is not 1 keystroke versus 3 keystrokes.

It's rather

  emacs <filename>

versus

  emacs [wait until Emacs is up] C-x C-f <filename>

This wait time in the middle of doing something is IMHO the annoying
part here. For me, it is the main reason to just use vim when working
from a shell. And that's why the problem doesn't show up for people who
always work from "within" Emacs.

The issue becomes somewhat grotesque when calling Emacs from some other
process, e.g. via the EDITOR shell variable (that's why I have
EDITOR=vim in my environment).

YMMV, of course.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFG7LPlBcgs9XrR2kYRAhc8AJoCdnaKxzumy3YOL9Lkx0jjIu4DawCdE/+A
yP/HR14JUqUrt0Zxb/MkOBk=
=Bi2I
-----END PGP SIGNATURE-----

Re: New start up splash screen annoyance...

[Eli Zaretskii]

> Date: Sun, 16 Sep 2007 04:41:09 +0000
> Cc: Mathias Megyei <mathias@mnet-mail.de>, juri@jurta.org,
> 	wilde@sha-bang.de, emacs-devel@gnu.org, rms@gnu.org,
> 	hannes@saeurebad.de
> From: tomas@tuxteam.de
> 
> It's rather
> 
>   emacs <filename>
> 
> versus
> 
>   emacs [wait until Emacs is up] C-x C-f <filename>

Why would you need to wait for Emacs to come up on a modern machine?
The only use case I can think of that really causes a long startup is
when you use desktop.el to save and restore the last session.  But in
that case, you probably don't want to specify a file on the command
line anyway, since desktop.el would already visit the files you want.

But if there are use cases that I'm missing, how about using
emacsclient instead, as I suggested?

> The issue becomes somewhat grotesque when calling Emacs from some other
> process, e.g. via the EDITOR shell variable (that's why I have
> EDITOR=vim in my environment).

Now, _that_ is precisely what emacsclient is for.  We even say so in
the manual (see the node "Emacs Server").

Re: New start up splash screen annoyance...

[Mathias Megyei]

Eli Zaretskii writes:
 > > Date: Sun, 16 Sep 2007 04:41:09 +0000
 > > Cc: Mathias Megyei <mathias@mnet-mail.de>, juri@jurta.org,
 > > 	wilde@sha-bang.de, emacs-devel@gnu.org, rms@gnu.org,
 > > 	hannes@saeurebad.de
 > > From: tomas@tuxteam.de
 > > 
 > > It's rather
 > > 
 > >   emacs <filename>
 > > 
 > > versus
 > > 
 > >   emacs [wait until Emacs is up] C-x C-f <filename>
 > 
 > Why would you need to wait for Emacs to come up on a modern
 > machine?

We have Emacs installed centrally on a fileserver. This
slows down the startup somewhat compared to local installation.

 > But if there are use cases that I'm missing, how about using
 > emacsclient instead, as I suggested?

As I wrote in my previous mail we have to start Emacs in the
interesting project environment. When we have such an Emacs
running, then we do everything in that Emacs. We don't start a
second one.
(I have to support 8 projects currently and have Emacs always
running for the "most active" projects.)

Re: New start up splash screen annoyance...

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Sep 16, 2007 at 10:15:34PM +0200, Eli Zaretskii wrote:

[...]

> >   emacs [wait until Emacs is up] C-x C-f <filename>
> 
> Why would you need to wait for Emacs to come up on a modern machine?

On my fastest machine it takes about two seconds. Not all machines I
work with are that fast.

> The only use case I can think of that really causes a long startup is
> when you use desktop.el to save and restore the last session.  But in
> that case, you probably don't want to specify a file on the command
> line anyway, since desktop.el would already visit the files you want.

You are quite right on that...

> But if there are use cases that I'm missing, how about using
> emacsclient instead, as I suggested?

In some cases it makes sense: when it's my work machine. In others not
so much: a server I log in ocassionally via SSH (where I just decide
spontaneously to view/edit a configuration file). There, all the
preparations to make Emacs the way I'd prefer do not seem worth the
hassle and I just use vim.

(Note that the delay mentioned by me above is not bad because it's too
long -- even a couple of seconds is annoying when they are "in the
middle" of a conceptual action, like "I'd like to edit/view this file").

If you "live" whithin Emacs, you won't see the problem, but coming from
a shell, you will.

> > The issue becomes somewhat grotesque when calling Emacs from some other
> > process, e.g. via the EDITOR shell variable (that's why I have
> > EDITOR=vim in my environment).
> 
> Now, _that_ is precisely what emacsclient is for.  We even say so in
> the manual (see the node "Emacs Server").

I'll give that a try, thanks. It'll at least cover the cases for the
machines I work regularly on.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFG7fy9Bcgs9XrR2kYRAqMOAJ0fQNf41hDz7wdeHWjqZOIHH43X5QCfRv3X
8FTtAv1JTfFl28JbATbp+C8=
=JgLv
-----END PGP SIGNATURE-----

Re: New start up splash screen annoyance...

[Richard Stallman]

    PPs: The splash screen doesn't show up, when Emacs is started
	 with the '-f' option and a non-existing name.
	 Eg: emacs <file> -f grhrjr.
	 Is this supposed to be a workaround of the "splash screen
	 annoyance"? ;-)

No.  However, I don't think there are many beginners who
always use -f when they start Emacs.  So there is no need
to show the splash screen in such cases.

Re: New start up splash screen annoyance...

[Davis Herring]

> When I want to do this, I start Emacs and then visit the file.
> What's the advantage of specifying the file name as a command arg?

$ type -a foobar
foobar is /usr/bin/foobar
$ file `type -p foobar`
/usr/bin/foobar: a bash script text executable
$ emacs !$

After the second command, the user thinks "Oh!  I can view/edit this!". 
Especially as the path can be arbitrarily long, it can be quite useful to
have the shell (or file(1), or...) generate it.

Davis

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

Re: New start up splash screen annoyance...

[Sascha Wilde]

Richard Stallman <rms@gnu.org> wrote:
>     > Experienced Emacs users generally don't do it anyway.
>
>     Huh?  If I start Emacs, why should I not specify what file I want to
>     edit as an experienced user?
>
> Because nearly always you already have an Emacs running.
> It is a bad idea to teach yourself habits that presume
> you don't have an Emacs running, because that would lead
> you to kill Emacs and restart it, or to start multiple Emacs jobs.

Basically I agree here.  It is worthwhile trying to teach new Emacs
users that one Emacs running is enough (and with the multi-tty stuff
merged in, this is even more true).[0]

BUT there are two reasons why I still think that annoying users when
using the file name argument is no good:

1. New users, having the habit to give the file name on the command
   line should not get the first impression, that Emacs is worse than
   the editors they already know.  It's easier to teach them better
   ways of using Emacs, if they are not annoyed by the first
   encounter.

2. Experienced users, just wanting to edit one file on a machine they
   will leave immediately after this.  In this case giving the file
   name on the command line safes some key strokes, but only if you
   don't have to waste them on getting rid of the nag screen.  I'm a
   system administrator you know, saving key strokes is our Holy
   Grail...

cheers
sascha

[0] btw, a shortcut for `emacsclient -a emacs' would be handy, maybe
    it should be even the default behavior, for it is what one usally
    wants to do: if there is an Emacs running: use it, else: start
    one.
-- 
Sascha Wilde
    "Computers are good at following instructions,
     but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

Re: New start up splash screen annoyance...

[David Kastrup]

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

> BUT there are two reasons why I still think that annoying users when
> using the file name argument is no good:
>
[...]
>
> 2. Experienced users, just wanting to edit one file on a machine they
>    will leave immediately after this.

No, that is not all.  Even an Emacs session of a dozen weeks can start
by editing one file.  It is not a good omen if it starts with a kick
in the shin.

Being able to _start_ Emacs with a file name does _not_ imply that one
leaves Emacs after finishing with that file.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Richard Stallman]

    BUT there are two reasons why I still think that annoying users when
    using the file name argument is no good:

The purpose of this change is to make sure that people who always
start Emacs with a file name argument (as many beginners do) do see
the splash screen.

If you refer to it as "annoying users", you misrepresent my
intentions, and you express hostility.  I will make sure 
to cater to such hostility.

Re: New start up splash screen annoyance...

[Jason Rumney]

Richard Stallman wrote:
> If you refer to it as "annoying users", you misrepresent my
> intentions, and you express hostility.  I will make sure 
> to cater to such hostility.
>   

As I was the first to bring up "annoying users", I would like to
reassure you that I was trying to bring the EFFECT of those changes to
your attention, not to make a comment on your intentions.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     BUT there are two reasons why I still think that annoying users when
>     using the file name argument is no good:
>
> The purpose of this change is to make sure that people who always
> start Emacs with a file name argument (as many beginners do) do see
> the splash screen.
>
> If you refer to it as "annoying users", you misrepresent my
> intentions,

A user's annoyance does not depend on your intentions.  It just
depends on what Emacs does or does not do.

> and you express hostility.  I will make sure to cater to such
> hostility.

Sorry, I can't follow you here.  Whatever your intentions are, users
_are_ annoyed at software that does not do what it is told.  I don't
see that is has anything to do with "hostility" if people try to
figure out how to serve both your as well as the users' wishes best.

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Richard Stallman]

    The way other programs handle this is to (1) display the splash screen
    in a small, floating X window, (2) provide a check box on the splash
    screen saying "Display splash screen on startup" or something similar,
    and (3) a prominent button saying "OK" or similar to dismiss the
    splash screen.

There is no room in a small floating window for the info we
want to present in the splash screen.

As for the box that says "Display splash screen on startup",
we could do something like that.  I agreed to reinstallation
of the "Customize startup" link, given a way to make it fit.
We could replace that with "Don't show this screen again".
If users would like that better, let's make that replacement.

A button to dismiss the splash screen would be fine in principle.
I don't see how there is room for it.  Do you think you see
where it could go?

Re: New start up splash screen annoyance...

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     The way other programs handle this is to (1) display the splash screen
>     in a small, floating X window, (2) provide a check box on the splash
>     screen saying "Display splash screen on startup" or something similar,
>     and (3) a prominent button saying "OK" or similar to dismiss the
>     splash screen.
>
> There is no room in a small floating window for the info we
> want to present in the splash screen.
>
> As for the box that says "Display splash screen on startup",
> we could do something like that.  I agreed to reinstallation
> of the "Customize startup" link, given a way to make it fit.
> We could replace that with "Don't show this screen again".
> If users would like that better, let's make that replacement.
>
> A button to dismiss the splash screen would be fine in principle.
> I don't see how there is room for it.  Do you think you see
> where it could go?

I found a way of making this fit.  I'll implement it in the next
couple of days.

Re: New start up splash screen annoyance...

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>> A button to dismiss the splash screen would be fine in principle.
>> I don't see how there is room for it.  Do you think you see
>> where it could go?
>
> I found a way of making this fit.  I'll implement it in the next
> couple of days.

Checked into the trunk.  This basically involves omitting the big
graphical logo when a command line filename is specified.  The splash
screen now displays a "Dismiss" button with a checkbox for inhibiting
future splash screens.

Please to test.

Re: New start up splash screen annoyance...

[Leo]

On 2007-09-10 23:07 +0100, Chong Yidong wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>
>>> A button to dismiss the splash screen would be fine in principle.
>>> I don't see how there is room for it.  Do you think you see
>>> where it could go?
>>
>> I found a way of making this fit.  I'll implement it in the next
>> couple of days.
>
> Checked into the trunk.  This basically involves omitting the big
> graphical logo when a command line filename is specified.  The splash
> screen now displays a "Dismiss" button with a checkbox for inhibiting
> future splash screens.
>
> Please to test.

I can see the Dismiss button but not the checkbox.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: New start up splash screen annoyance...

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> On 2007-09-10 23:07 +0100, Chong Yidong wrote:
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>
>>>> A button to dismiss the splash screen would be fine in principle.
>>>> I don't see how there is room for it.  Do you think you see
>>>> where it could go?
>>>
>>> I found a way of making this fit.  I'll implement it in the next
>>> couple of days.
>>
>> Checked into the trunk.  This basically involves omitting the big
>> graphical logo when a command line filename is specified.  The splash
>> screen now displays a "Dismiss" button with a checkbox for inhibiting
>> future splash screens.
>>
>> Please to test.
>
> I can see the Dismiss button but not the checkbox.

Are you running with emacs -q?  In that case, the checkbox is not
displayed, since there is no way to save the option.

Re: New start up splash screen annoyance...

[Leo]

On 2007-09-11 00:19 +0100, Chong Yidong wrote:
> Leo <sdl.web@gmail.com> writes:
>
>> On 2007-09-10 23:07 +0100, Chong Yidong wrote:
>>> Chong Yidong <cyd@stupidchicken.com> writes:
>>>
>>>>> A button to dismiss the splash screen would be fine in principle.
>>>>> I don't see how there is room for it.  Do you think you see
>>>>> where it could go?
>>>>
>>>> I found a way of making this fit.  I'll implement it in the next
>>>> couple of days.
>>>
>>> Checked into the trunk.  This basically involves omitting the big
>>> graphical logo when a command line filename is specified.  The splash
>>> screen now displays a "Dismiss" button with a checkbox for inhibiting
>>> future splash screens.
>>>
>>> Please to test.
>>
>> I can see the Dismiss button but not the checkbox.
>
> Are you running with emacs -q?  In that case, the checkbox is not
> displayed, since there is no way to save the option.

Yes.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: New start up splash screen annoyance...

[Glenn Morris]

Chong Yidong wrote:

> graphical logo when a command line filename is specified.  The splash
> screen now displays a "Dismiss" button with a checkbox for inhibiting
> future splash screens.

If you're going to use a line for this "Dismiss" link, I think you may
as well use the rest of the line to explain what following said link does.

I don't know if this is related to these changes, but I get this
message on startup now:

  For information about the GNU system and GNU/Linux, type C-h C-p.
  Invalid face reference: quote [40 times]

Re: New start up splash screen annoyance...

[Glenn Morris]

Glenn Morris wrote:

> If you're going to use a line for this "Dismiss" link, I think you may
> as well use the rest of the line to explain what following said link does.

Sorry, ignore that. I was testing with emacs -q, I see it's different
if there is an init-file.

> I don't know if this is related to these changes, but I get this
> message on startup now:
>
>   For information about the GNU system and GNU/Linux, type C-h C-p.
>   Invalid face reference: quote [40 times]

I think I fixed that.

Re: New start up splash screen annoyance...

[Jason Rumney]

Richard Stallman wrote:
> I changed this because I want beginners to see the splash screen,
> and beginners often have the habit of passing a file name.
>   

In the past, that may have been true, but now I think beginners are more
likely to start Emacs from a menu on their desktop. Especially now that
the startup screen does not disappear on the first input event,
displaying it when the user gives a filename on the command-line is
annoying, and annoying your users is not a good way to get a message across.

RE: New start up splash screen annoyance...

[Drew Adams]

> displaying it when the user gives a filename on the command-line is
> annoying, and annoying your users is not a good way to get a 
> message across.

Add me to the list of those who agree.

Re: New start up splash screen annoyance...

[Richard Stallman]

    > I changed this because I want beginners to see the splash screen,
    > and beginners often have the habit of passing a file name.
    >   

    In the past, that may have been true, but now I think beginners are more
    likely to start Emacs from a menu on their desktop.

The feature of showing the splash screen when you specify a file name
affects people who specify a file name.  Beginners coming from other
editors are the ones who tend to do that.  It is important for them
to see the splash screen.

If there are beginners that don't specify file name args, so what?
This question won't affect them anyway.  Why bring them up?x

This is just an explanation for a decision previously made.

'Nuff said.

Re: New start up splash screen annoyance...

[Juri Linkov]

>     I would like to have the old behavior back:  if a file name was given
>     on the command line the user definitely wants to edit that file, and
>     so any editing/movement/redraw command should switch to that files
>     buffer immediately.
>
> I changed this because I want beginners to see the splash screen,
> and beginners often have the habit of passing a file name.

Most beginners start Emacs from a menu on modern desktop environments
nowadays.  Beginners that manage to start Emacs from the command line with
a file name are smart enough to figure out where to find the necessary
help.  Due to a good established convention that the Help menu on the
right side of the menu bar contains menu items that help learning the
program, this is how most users get acquainted with a new program.

Furthermore, since now the About screen shares much help information with
the startup screen (links to the Emacs tutorial, Emacs Guided Tour, etc.),
any beginner can now find this information.  So even a very small percent
of beginners started Emacs with a file name will be able to get help.

OTOH, the current behavior is very annoying for all non-beginners.
This is like visiting a Web site where the first page displays a big Flash
screen, and only clicking on a special link proceeds to the main page.
I never visit such sites because this is very annoying.  It's a pity that
Emacs does the same.

In summary, displaying the startup screen when the user requests
to display a file does more harm than good.

>       In case people don't agree on that, the splash
>     screen should at least mention how to enter the buffer.
>
> That is a good point.  We should make this easier.  Maybe typing SPC
> on the splash screen should bury or kill it.  Also, we should say how
> to do this, if we can fit it in.

It is not a question what key is better to type to get rid of the
startup screen.  It is the fact that the user explicitly requested
visiting a file but instead of this Emacs displays the screen that
the user have already seen thousand times.

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

Re: New start up splash screen annoyance...

[KingBolete]

The new splash screen is like one of those horrible features that MS tends to
inflict on users.  The first thing you want to do is figure out how to
disable the "feature".  I wandered through the customization menus but
couldn't find any way to do it (it might be there, but things are rather
hard to find there).  I probably would have got around to searching through
the info, but I might not have ever searched for "splash screen" since it is
so unlike the ones I'm used to (i.e., they usually go away quickly once the
app is launched).

I would add in the splash screen text both info on how to get out of the
screen and how to disable it in the future.  Often I want to take a quick
look at a file and adding another operation is definitely annoying!

Never the less, Emacs is still the one-true-editer.
-- 
View this message in context: http://www.nabble.com/New-start-up-splash-screen-annoyance...-tf4409371.html#a13026901
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: New start up splash screen annoyance...

[Richard Stallman]

    The new splash screen is like one of those horrible features that MS tends to
    inflict on users.  The first thing you want to do is figure out how to
    disable the "feature".

Why, precisely, does it bother you?  What command do you use to start
Emacs?

Re: New start up splash screen annoyance...

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Oct 04, 2007 at 01:27:18PM -0400, Richard Stallman wrote:
>     The new splash screen is like one of those horrible features that MS tends to
>     inflict on users.  The first thing you want to do is figure out how to
>     disable the "feature".
> 
> Why, precisely, does it bother you?  What command do you use to start
> Emacs?

Well, since we haven't seen the OP's answer here, I'll offer my POV,
which will be similar to his:

when just calling Emacs in a command line (or invoking it from a GUI menu
or similar), the splash screen is definitely no problem. When calling
"emacs foo" (or likewise when Emacs is called from a GUI program with a
filename argument, as from a GUI program or a mail program), it is a
definite annoyance.

As a more concrete example: I'm using Pine as a mail user agent. Just
imagine having to go through the Emacs splash screen for every mail I
compose.

Regards
- - tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHCa8eBcgs9XrR2kYRAvKPAJoCtwVUja80loVfJ4teJec+L85MoQCfeqI1
ZMokmlg1BMVgNgCBKpr07qY=
=DTl+
-----END PGP SIGNATURE-----

Re: New start up splash screen annoyance...

[Juri Linkov]

> when just calling Emacs in a command line (or invoking it from a GUI menu
> or similar), the splash screen is definitely no problem. When calling
> "emacs foo" (or likewise when Emacs is called from a GUI program with a
> filename argument, as from a GUI program or a mail program), it is a
> definite annoyance.
>
> As a more concrete example: I'm using Pine as a mail user agent. Just
> imagine having to go through the Emacs splash screen for every mail I
> compose.

I believe this is not a problem anymore.  And Richard also asked
to put all recent changes into Emacs 22 after they have settled down.

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

Re: New start up splash screen annoyance...

[Richard Stallman]

    I believe this is not a problem anymore.  And Richard also asked
    to put all recent changes into Emacs 22 after they have settled down.

I think they have settled down, since no more changes have been made
in a few weeks.  Could someone please install them in Emacs 22 if they
have not yet been?

Re: New start up splash screen annoyance...

[Juri Linkov]

>     I believe this is not a problem anymore.  And Richard also asked
>     to put all recent changes into Emacs 22 after they have settled down.
>
> I think they have settled down, since no more changes have been made
> in a few weeks.  Could someone please install them in Emacs 22 if they
> have not yet been?

Installed in Emacs 22 all startup screen related changes, except
a new controversial user option `initial-buffer-choice' (needs more
ideas how to fix its inconsistencies), and except links "Authors" and
"Contributing" (need moving corresponding files to etc/, don't feel
necessary for Emacs 22).

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

Pure space overflow in Emacs 22 (was: Re: New start up splash screen annoyance...)

[Sven Joachim]

Juri Linkov <juri@jurta.org> writes:

> Installed in Emacs 22 all startup screen related changes, except
> a new controversial user option `initial-buffer-choice' (needs more
> ideas how to fix its inconsistencies), and except links "Authors" and
> "Contributing" (need moving corresponding files to etc/, don't feel
> necessary for Emacs 22).

These changes led to pure space overflow on my system with this build:

GNU Emacs 22.1.50.9 (i686-pc-linux-gnu, GTK+ Version 2.12.1)
 of 2007-11-10 on debian
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--with-gtk''

emacs:0:Pure Lisp storage overflow (approx. 1126273 bytes needed)

Re: Pure space overflow in Emacs 22

[Juri Linkov]

>> Installed in Emacs 22 all startup screen related changes, except
>> a new controversial user option `initial-buffer-choice' (needs more
>> ideas how to fix its inconsistencies), and except links "Authors" and
>> "Contributing" (need moving corresponding files to etc/, don't feel
>> necessary for Emacs 22).
>
> These changes led to pure space overflow on my system with this build:
>
> GNU Emacs 22.1.50.9 (i686-pc-linux-gnu, GTK+ Version 2.12.1)
>  of 2007-11-10 on debian
> Windowing system distributor `The X.Org Foundation', version 11.0.10300000
> configured using `configure  '--with-gtk''
>
> emacs:0:Pure Lisp storage overflow (approx. 1126273 bytes needed)

Thanks for the report.  Now increased PURESIZE from 1120000 to 1130000.

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

Re: New start up splash screen annoyance...

[Richard Stallman]

Have you tried it in the development sources?

Re: New start up splash screen annoyance...

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Oct 08, 2007 at 09:14:45PM -0400, Richard Stallman wrote:
> Have you tried it in the development sources?

I'll do so asap and report back.

Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHCyISBcgs9XrR2kYRAhrIAJ4hjD65EFlBFU1beWV3HvPMBfzJzQCeK0Un
JJUepd2/sGsbvBOVUvADVcA=
=nrJj
-----END PGP SIGNATURE-----

Re: New start up splash screen annoyance...

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 09, 2007 at 06:39:14AM +0000, tomas@tuxteam.de wrote:
> On Mon, Oct 08, 2007 at 09:14:45PM -0400, Richard Stallman wrote:
> > Have you tried it in the development sources?
> 
> I'll do so asap and report back.

Done. Behaviour is fine now :-)

Thanks to all
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHIXljBcgs9XrR2kYRArMQAJ9BsiRa/twrkNJA3Qwbjxth5IsxogCfcXXI
SOrVTHbxi86ge2hv7q5e7GA=
=/y9c
-----END PGP SIGNATURE-----

Re: New start up splash screen annoyance...

[Juri Linkov]

> - First and most annoying: starting Emacs with an file to visit as
>   argument no longer works as expected.  Without doing any configuration
>   you always get the new splash screen and of cause C-l or starting
>   editing doesn't make it go away.  You can switch to the buffer with
>   the file using C-x C-b, but the splash screen doesn't tell you that.

Using C-l to quit the startup screen was a perverted idea.  C-l is used
to *redisplay* the current buffer, not to switch to other buffer.
So the first key Emacs taught the beginner to type was misleading.

> I would like to have the old behavior back:  if a file name was given
> on the command line the user definitely wants to edit that file, and
> so any editing/movement/redraw command should switch to that files
> buffer immediately.

The old behavior was dangerous.  Typing a key on a buffer that you don't
see may lead to disastrous results.

> In case people don't agree on that, the splash screen should at least
> mention how to enter the buffer.
>
> - Second, and maybe even worse: None of the settings for
>   initial-buffer-choice restores the old behavior.  One might expect,
>   that setting initial-buffer-choice to t (open *scratch* buffer)
>   would be the right choice, but it isn't.  If set that way, the
>   annoying behavior described above stays with the only differences,
>   that the *scratch* buffer is opened and stays, even if a file to
>   edit was given on start-up.

If we all convince Richard that displaying the startup screen instead of
a file is a bad thing, any changes won't be necessary.

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

Re: New start up splash screen annoyance...

[Stefan Monnier]

> If we all convince Richard that displaying the startup screen instead of
> a file is a bad thing, any changes won't be necessary.

Richard has made up his mind, I doubt there exist a way to change his
opinion on that.  So since the startup screen will be displayed, the only
way out of this is to display both the startup buffer and the file buffer.


        Stefan

Re: New start up splash screen annoyance...

[David Kastrup]

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

>> If we all convince Richard that displaying the startup screen
>> instead of a file is a bad thing, any changes won't be necessary.
>
> Richard has made up his mind, I doubt there exist a way to change
> his opinion on that.  So since the startup screen will be displayed,
> the only way out of this is to display both the startup buffer and
> the file buffer.

But Richard did not demand that we create a splash screen that does
not even go away when you press a key or other event even when started
with a file name, did he?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    But Richard did not demand that we create a splash screen that does
    not even go away when you press a key or other event even when started
    with a file name, did he?

The reason we made it not go away
is so the user can follow the links.

Re: New start up splash screen annoyance...

[Richard Stallman]

    Richard has made up his mind, I doubt there exist a way to change his
    opinion on that.  So since the startup screen will be displayed, the only
    way out of this is to display both the startup buffer and the file buffer.

There is no room for both in an ordinary size terminal.
(It was a struggle just to get the startup buffer to fit.)
So this is a non-starter.

Re: New start up splash screen annoyance...

[Stefan Monnier]

>     Richard has made up his mind, I doubt there exist a way to change his
>     opinion on that.  So since the startup screen will be displayed, the
>     only way out of this is to display both the startup buffer and the
>     file buffer.

> There is no room for both in an ordinary size terminal.
> (It was a struggle just to get the startup buffer to fit.)
> So this is a non-starter.

You mean that you added the constraint that even when started with
a filename and even on a small terminal, the startup screen should
be immediately visible in its entirety?


        Stefan


PS: What is an "ordinary size terminal" nowadays?  I never use terminals
smaller than about 50 lines by 80columns, even when working on the console,
and even when working on my good old amber-screen HDS terminal (50x132)

Re: New start up splash screen annoyance...

[David Kastrup]

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

>>     Richard has made up his mind, I doubt there exist a way to change his
>>     opinion on that.  So since the startup screen will be displayed, the
>>     only way out of this is to display both the startup buffer and the
>>     file buffer.
>
>> There is no room for both in an ordinary size terminal.
>> (It was a struggle just to get the startup buffer to fit.)
>> So this is a non-starter.
>
> You mean that you added the constraint that even when started with
> a filename and even on a small terminal, the startup screen should
> be immediately visible in its entirety?
>
>
>         Stefan
>
>
> PS: What is an "ordinary size terminal" nowadays?

80x24 is the default startup for most, and that needs to work.

If we start Emacs with a file name, how about having a clickable
excerpt of your file (with the obvious implication) instead of the
logo?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New start up splash screen annoyance...

[Richard Stallman]

    You mean that you added the constraint that even when started with
    a filename and even on a small terminal, the startup screen should
    be immediately visible in its entirety?

It is nothing new.  This was the case before the recent changes.

    PS: What is an "ordinary size terminal" nowadays?

The default for xterm is 24 lines.  I think that is the usual case.
Of course, more experienced people may customize the height, but we
need to aim to do the best thing for when it is not customized.

tramp

[Miles Bader]

Is tramp in the current emacs CVS (2002-08-02) supposed to work?

I've tried a bunch of different filenames, and invariably tramp gets
confused and just hangs waiting for a prompt or something.  When I use
^G to interrupt it, and look at the `*tramp...*' buffer, I see a shell
prompt (but apparently tramp never realized it).


For instance, visiting:

`/sudo:root@localhost:/etc':

   Shows the following messages:

      tramp: Opening connection for `root' using `sudo'...
      tramp: Processing actions
      tramp: Waiting 60s for prompt from remote shell
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Found remote shell prompt.
      tramp: Waiting 30s for remote `/bin/sh' to come up...
      Quit

  [Seeing `Found remote shell prompt' immediately followed by 
   `Waiting 30s for remote `/bin/sh' to come up' seems ... odd.]

  Looking in the `*tramp/sudo root@localhost*' buffer, I see:

     sh-2.05b# 


`/su:root@localhost:/etc':

   Shows the following messages:

      tramp: Opening connection for `root' using `su'...
      tramp: Processing actions
      tramp: Waiting 60s for prompt from remote shell
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      Password: 
      Password: .
      Password: ..
      Password: .......
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      Quit

   [Note that even though the above appears as if it's asking a user
    question, it doesn't seem to accept any input; I have to interrupt
    it to do anything]

   Looking in the `*tramp/su root@localhost*' buffer, I see:


      mcspd15:~# 

   [that's a blank line at the beginning].


Trying to use the `ssh' method to connect to `fp-ssh.gnu.org' gives
similar results to the latter, but without the password prompt (I have
ssh setup to not require a password).

Thanks,

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Is tramp in the current emacs CVS (2002-08-02) supposed to work?
>
> I've tried a bunch of different filenames, and invariably tramp gets
> confused and just hangs waiting for a prompt or something.  When I use
> ^G to interrupt it, and look at the `*tramp...*' buffer, I see a shell
> prompt (but apparently tramp never realized it).

Yes, I think so.

> For instance, visiting:
>
> `/sudo:root@localhost:/etc':
>
>    Shows the following messages:
>
>       tramp: Opening connection for `root' using `sudo'...
>       tramp: Processing actions
>       tramp: Waiting 60s for prompt from remote shell
>       tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
>       tramp: Looking for pattern .*ogin: *
>       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*

This looks like your shell-prompt-pattern.  Is it?

>       tramp: Found remote shell prompt.
>       tramp: Waiting 30s for remote `/bin/sh' to come up...
>       Quit
>
>   [Seeing `Found remote shell prompt' immediately followed by 
>    `Waiting 30s for remote `/bin/sh' to come up' seems ... odd.]

Heh :-)  First, Tramp logs in to the remote system and waits for any
old shell prompt.  But for proper operation, Tramp needs a Bourneish
shell, so it issues "exec /bin/sh" first thing.  Of course, after
this Tramp again has to wait for a shell prompt...

Maybe I should make this clearer in the messages.  But how?

>   Looking in the `*tramp/sudo root@localhost*' buffer, I see:
>
>      sh-2.05b# 

At this point, Tramp is again waiting for shell-prompt-pattern, and
this shell prompt does not match the regexp above.

Could this be the case?

It used to be that Tramp tried to grok some common shell prompts in
addition to shell-prompt-pattern.  Maybe I should re-add this feature.

>       tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
>       Quit
>
>    [Note that even though the above appears as if it's asking a user
>     question, it doesn't seem to accept any input; I have to interrupt
>     it to do anything]

Hm.  Maybe this "looking for pattern" stuff should be removed from
the default debugging messages.

>    Looking in the `*tramp/su root@localhost*' buffer, I see:
>
>
>       mcspd15:~# 
>
>    [that's a blank line at the beginning].

Looks like the same shell prompt problem.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
> 
> This looks like your shell-prompt-pattern.  Is it?

Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
I had forgotten that I had one.  However, in this case it's still clearly
wrong, since it's not _my_ shell that's being started, but root's.

> At this point, Tramp is again waiting for shell-prompt-pattern, and
> this shell prompt does not match the regexp above.
> 
> It used to be that Tramp tried to grok some common shell prompts in
> addition to shell-prompt-pattern.  Maybe I should re-add this feature.

I think it _definitely_ should match common shell prompts, as
`shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
above:

 (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

 (2) In many cases, a shell started by tramp will be in a `different
     context' than a normal user-shell, and so will have a different
     prompt anyway.

Probably it ought to be possible to modify this on a per-connection-type and
per-machine basis (but presumably that will be handled by the whizzy config
mechanism that will added to address other problems, right?).

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
>> 
>> This looks like your shell-prompt-pattern.  Is it?
>
> Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
> I had forgotten that I had one.  However, in this case it's still clearly
> wrong, since it's not _my_ shell that's being started, but root's.

Right.

>> At this point, Tramp is again waiting for shell-prompt-pattern, and
>> this shell prompt does not match the regexp above.
>> 
>> It used to be that Tramp tried to grok some common shell prompts in
>> addition to shell-prompt-pattern.  Maybe I should re-add this feature.
>
> I think it _definitely_ should match common shell prompts, as
> `shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
> above:

Okay, Tramp now has its own variable, tramp-shell-prompt-pattern,
that users can set.  The default value is the same as the default
value for shell-prompt-pattern, so it should match the prompts that
your examples showed.

>  (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

Ah.  Hm.  shell-mode just assumes that everything on the last line is
a prompt, right?  Hm.  But I think it's not possible for Tramp to
assume something similar.

It is vital for Tramp to wait until it sees a shell prompt before
sending something to the remote shell.  If you send input to the
remote shell too early, things go wrong in a quite horrible way
(depending on the remote login program that you are using).

But maybe waiting for the shell prompt is not the right thing to do.
What could Tramp do instead?

(After Tramp has ascertained that it is indeed talking to the remote
shell, it sets the shell prompt to a special value and then uses
that, and this mechanism works well.  I haven't heard any complaints,
yet, at least :-)

>  (2) In many cases, a shell started by tramp will be in a `different
>      context' than a normal user-shell, and so will have a different
>      prompt anyway.
>
> Probably it ought to be possible to modify this on a per-connection-type and
> per-machine basis (but presumably that will be handled by the whizzy config
> mechanism that will added to address other problems, right?).

Is it really necessary to modify the regexp like this?  Isn't it
enough for the user to set one value which covers all alternatives?

If possible, I would like to avoid having too many parameters that
are based on method or machine.

But I'm having similar arguments about tramp-remote-path.  It's also
just one variable, and people are requesting me to make it
configurable on a per-host basis.  But I think it is sufficient to
have one global value which contains all the directories on all the
hosts.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Tramp now has its own variable, tramp-shell-prompt-pattern, that users
> can set.  The default value is the same as the default value for
> shell-prompt-pattern, so it should match the prompts that your examples
> showed.

I just tried tramp /su:localhost:/etc again today, and it works!

Startup's a bit slow though; it'd be nice if all the file-downloading
&c could be omitted on a local connection (presumably that couldn't be
the default, but it could be configurable).  Actually it would be nice
to be able to say, for _any_ specific host/user/method combo `I've
already installed tools x&y, here's where you can find them.  Yet
another job for the whizzy per-method/machine/user configuration alist.
[I guess there are probably variables for this; I've not checked.]

> shell-mode just assumes that everything on the last line is a prompt,
> right?  Hm.  But I think it's not possible for Tramp to assume something
> similar.

Probably not.

> It is vital for Tramp to wait until it sees a shell prompt before
> sending something to the remote shell.  If you send input to the
> remote shell too early, things go wrong in a quite horrible way
> (depending on the remote login program that you are using).
> 
> But maybe waiting for the shell prompt is not the right thing to do.
> What could Tramp do instead?

I don't know; is simply waiting for _some_ output too optimistic?

> >  (2) In many cases, a shell started by tramp will be in a `different
> >      context' than a normal user-shell, and so will have a different
> >      prompt anyway.
> >
> > Probably it ought to be possible to modify this on a
> > per-connection-type and per-machine basis (but presumably that will be
> > handled by the whizzy config mechanism that will added to address
> > other problems, right?).
> 
> Is it really necessary to modify the regexp like this?  Isn't it
> enough for the user to set one value which covers all alternatives?

Perhaps, but I think for me, it's more natural to think in little bits,
for concrete cases, rather than trying to cover all cases with one mondo
regexp.

It's also possible that there will in fact be conflicts, though I haven't
any personal experience of any (e.g., host X uses a shell prompt that
actually matches some other non-shell prompt login output on host Y).

> If possible, I would like to avoid having too many parameters that
> are based on method or machine.
> 
> But I'm having similar arguments about tramp-remote-path.  It's also
> just one variable, and people are requesting me to make it configurable
> on a per-host basis.  But I think it is sufficient to have one global
> value which contains all the directories on all the hosts.

I think this is a much more dangerous assumption than in the prompt case,
since what is a trusted directory on one host may not be on another.

Since there definitely are parameters which will have to be host/method
specific, and that you're better off simply making a general mechanism by
which _all_ parameters can be set on a host/method specific manner.

E.g., just an alist containing machine/method/user specs, and variables
and values, which tramp will run down and do
  (set (make-local-variable VAR) val)
inside the tramp work buffer.  Then the code can use simple variables,
but the user still gets max flexibility where needed.

An example format might be:

  ((SPEC (VAR . VAL) ...) ...)

where SPEC is either a regexp matching the hostname, or a tuple like
(HOST USER METHOD) where the components are regexps or nil (meaning
match anything).

That's what I want.

[I haven't looked at tramp's code though, so perhaps the above is not a
workable solution.]

Thanks,

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: tramp

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Since there definitely are parameters which will have to be host/method
> specific, and that you're better off simply making a general mechanism by
> which _all_ parameters can be set on a host/method specific manner.
> 
> E.g., just an alist containing machine/method/user specs, and variables
> and values, which tramp will run down and do
>   (set (make-local-variable VAR) val)
> inside the tramp work buffer.  Then the code can use simple variables,
> but the user still gets max flexibility where needed.
> 
> An example format might be:
> 
>   ((SPEC (VAR . VAL) ...) ...)
> 
> where SPEC is either a regexp matching the hostname, or a tuple like
> (HOST USER METHOD) where the components are regexps or nil (meaning
> match anything).
> 
> That's what I want.
> 

So do I.

I have actually very few remote machines I connect to, so I would
like to be able to configure tramp for each of those with the
optimal set of parameters (and faster connect times).

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