unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
@ 2009-03-30 13:57 Damien Cassou
  2012-04-20 10:05 ` Chong Yidong
  0 siblings, 1 reply; 11+ messages in thread
From: Damien Cassou @ 2009-03-30 13:57 UTC (permalink / raw)
  To: emacs-pretest-bug

Hi,

the new variable initial-buffer-choice seems useless when using emacs
as a daemon and emacsclient. This variable probably sets the initial
frame of the daemon, but does not affect the emacs clients. The buffer
is opened but not visible, the *scratch* buffer is opened instead.

Thank you

-- 
Damien Cassou
http://damiencassou.seasidehosting.st






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
@ 2009-04-10  2:25 Chong Yidong
  0 siblings, 0 replies; 11+ messages in thread
From: Chong Yidong @ 2009-04-10  2:25 UTC (permalink / raw)
  To: emacs-devel; +Cc: 2825

> the new variable initial-buffer-choice seems useless when using emacs
> as a daemon and emacsclient. This variable probably sets the initial
> frame of the daemon, but does not affect the emacs clients. The buffer
> is opened but not visible, the *scratch* buffer is opened instead.

Currently, server-create-tty-frame and server-create-window-system-frame
are hardcoded to display *scratch* if no emacsclient argument is given.
In bug #2825, Damien Cassou has argued that they should obey
initial-buffer-choice.

Are there any objections?






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
       [not found] <87ocv5mei7.fsf@cyd.mit.edu>
@ 2009-04-11 15:13 ` Dan Nicolaescu
       [not found] ` <200904111513.n3BFD6fp012593@godzilla.ics.uci.edu>
  1 sibling, 0 replies; 11+ messages in thread
From: Dan Nicolaescu @ 2009-04-11 15:13 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 2825, emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:

  > > the new variable initial-buffer-choice seems useless when using emacs
  > > as a daemon and emacsclient. This variable probably sets the initial
  > > frame of the daemon, but does not affect the emacs clients. The buffer
  > > is opened but not visible, the *scratch* buffer is opened instead.
  > 
  > Currently, server-create-tty-frame and server-create-window-system-frame
  > are hardcoded to display *scratch* if no emacsclient argument is given.
  > In bug #2825, Damien Cassou has argued that they should obey
  > initial-buffer-choice.
  > 
  > Are there any objections?

Showing the startup screen every time when connecting to the server can
be seriously annoying for the user.

This situation is not equivalent with showing the startup screen when
starting emacs because we assume that emacs is not started very often.
Connecting/disconnecting to the server is a much more frequent action
for some use cases.

So changing this at this point does not sound like a good idea.  If it
needs to be changed at all it can wait until 23.2.  If many people don't
like it we'll generate yet another very long discussion (like all
discussions about the startup screen), and it's simply not worth it when
trying to get a release out.






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
       [not found] ` <200904111513.n3BFD6fp012593@godzilla.ics.uci.edu>
@ 2009-04-11 18:34   ` Stefan Monnier
  2009-04-11 23:34     ` Dan Nicolaescu
       [not found]     ` <200904112334.n3BNYwuE019572@godzilla.ics.uci.edu>
  0 siblings, 2 replies; 11+ messages in thread
From: Stefan Monnier @ 2009-04-11 18:34 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Chong Yidong, 2825, emacs-devel

>> > the new variable initial-buffer-choice seems useless when using emacs
>> > as a daemon and emacsclient. This variable probably sets the initial
>> > frame of the daemon, but does not affect the emacs clients. The buffer
>> > is opened but not visible, the *scratch* buffer is opened instead.
>> 
>> Currently, server-create-tty-frame and server-create-window-system-frame
>> are hardcoded to display *scratch* if no emacsclient argument is given.
>> In bug #2825, Damien Cassou has argued that they should obey
>> initial-buffer-choice.
>> 
>> Are there any objections?

> Showing the startup screen every time when connecting to the server can
> be seriously annoying for the user.

I'm not sure what you mean by "the startup screen", but if a user
prefers to start with a (dired "~/") than with *scratch*, I can't think
of a good reason why we should disregard this preference when connecting
via the emacsclient.


        Stefan






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
  2009-04-11 18:34   ` Stefan Monnier
@ 2009-04-11 23:34     ` Dan Nicolaescu
       [not found]     ` <200904112334.n3BNYwuE019572@godzilla.ics.uci.edu>
  1 sibling, 0 replies; 11+ messages in thread
From: Dan Nicolaescu @ 2009-04-11 23:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Chong Yidong, 2825, emacs-devel

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

  > >> > the new variable initial-buffer-choice seems useless when using emacs
  > >> > as a daemon and emacsclient. This variable probably sets the initial
  > >> > frame of the daemon, but does not affect the emacs clients. The buffer
  > >> > is opened but not visible, the *scratch* buffer is opened instead.
  > >> 
  > >> Currently, server-create-tty-frame and server-create-window-system-frame
  > >> are hardcoded to display *scratch* if no emacsclient argument is given.
  > >> In bug #2825, Damien Cassou has argued that they should obey
  > >> initial-buffer-choice.
  > >> 
  > >> Are there any objections?
  > 
  > > Showing the startup screen every time when connecting to the server can
  > > be seriously annoying for the user.
  > 
  > I'm not sure what you mean by "the startup screen", but if a user
  > prefers to start with a (dired "~/") than with *scratch*, I can't think
  > of a good reason why we should disregard this preference when connecting
  > via the emacsclient.

The startup screen is what `display-startup-screen' displays. 
And that's my point too, *scratch* is a fine choice for now.






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
       [not found]     ` <200904112334.n3BNYwuE019572@godzilla.ics.uci.edu>
@ 2009-04-13 17:51       ` Stefan Monnier
  2009-04-13 18:13         ` Dan Nicolaescu
       [not found]         ` <200904131813.n3DIDinI026826@godzilla.ics.uci.edu>
  0 siblings, 2 replies; 11+ messages in thread
From: Stefan Monnier @ 2009-04-13 17:51 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Chong Yidong, 2825, emacs-devel

>> I'm not sure what you mean by "the startup screen", but if a user
>> prefers to start with a (dired "~/") than with *scratch*, I can't think
>> of a good reason why we should disregard this preference when connecting
>> via the emacsclient.

> The startup screen is what `display-startup-screen' displays. 
> And that's my point too, *scratch* is a fine choice for now.

What does this have to do with the question at hand.  IIUC th question
at hand is: why should the server.el code show "*scratch*" when the user
has set initial-buffer-choice to some file name?


        Stefan






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
  2009-04-13 17:51       ` Stefan Monnier
@ 2009-04-13 18:13         ` Dan Nicolaescu
       [not found]         ` <200904131813.n3DIDinI026826@godzilla.ics.uci.edu>
  1 sibling, 0 replies; 11+ messages in thread
From: Dan Nicolaescu @ 2009-04-13 18:13 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Chong Yidong, 2825, emacs-devel

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

  > >> I'm not sure what you mean by "the startup screen", but if a user
  > >> prefers to start with a (dired "~/") than with *scratch*, I can't think
  > >> of a good reason why we should disregard this preference when connecting
  > >> via the emacsclient.
  > 
  > > The startup screen is what `display-startup-screen' displays. 
  > > And that's my point too, *scratch* is a fine choice for now.
  > 
  > What does this have to do with the question at hand.  IIUC th question
  > at hand is: why should the server.el code show "*scratch*" when the user
  > has set initial-buffer-choice to some file name?

NEWS says:

** New user option `initial-buffer-choice' specifies what to display
after starting Emacs: startup screen, *scratch* buffer, visiting a
file or directory.

if the code is changed so that emacsclient called with no arguments
displays the startup screen __by default__, then we might have yet
another long discussion if this is the right thing to do.






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
       [not found]         ` <200904131813.n3DIDinI026826@godzilla.ics.uci.edu>
@ 2009-04-14  2:07           ` Stefan Monnier
  2009-04-14  2:35             ` Dan Nicolaescu
       [not found]             ` <200904140235.n3E2Zp0J008505@godzilla.ics.uci.edu>
  0 siblings, 2 replies; 11+ messages in thread
From: Stefan Monnier @ 2009-04-14  2:07 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Chong Yidong, 2825, emacs-devel

>> >> I'm not sure what you mean by "the startup screen", but if a user
>> >> prefers to start with a (dired "~/") than with *scratch*, I can't think
>> >> of a good reason why we should disregard this preference when connecting
>> >> via the emacsclient.
>> 
>> > The startup screen is what `display-startup-screen' displays. 
>> > And that's my point too, *scratch* is a fine choice for now.
>> 
>> What does this have to do with the question at hand.  IIUC th question
>> at hand is: why should the server.el code show "*scratch*" when the user
>> has set initial-buffer-choice to some file name?

> NEWS says:

> ** New user option `initial-buffer-choice' specifies what to display
> after starting Emacs: startup screen, *scratch* buffer, visiting a
> file or directory.

> if the code is changed so that emacsclient called with no arguments
> displays the startup screen __by default__, then we might have yet
> another long discussion if this is the right thing to do.

I do not understand what you mean.


        Stefan






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
  2009-04-14  2:07           ` Stefan Monnier
@ 2009-04-14  2:35             ` Dan Nicolaescu
       [not found]             ` <200904140235.n3E2Zp0J008505@godzilla.ics.uci.edu>
  1 sibling, 0 replies; 11+ messages in thread
From: Dan Nicolaescu @ 2009-04-14  2:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Chong Yidong, 2825, emacs-devel

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

  > >> >> I'm not sure what you mean by "the startup screen", but if a user
  > >> >> prefers to start with a (dired "~/") than with *scratch*, I can't think
  > >> >> of a good reason why we should disregard this preference when connecting
  > >> >> via the emacsclient.
  > >> 
  > >> > The startup screen is what `display-startup-screen' displays. 
  > >> > And that's my point too, *scratch* is a fine choice for now.
  > >> 
  > >> What does this have to do with the question at hand.  IIUC th question
  > >> at hand is: why should the server.el code show "*scratch*" when the user
  > >> has set initial-buffer-choice to some file name?
  > 
  > > NEWS says:
  > 
  > > ** New user option `initial-buffer-choice' specifies what to display
  > > after starting Emacs: startup screen, *scratch* buffer, visiting a
  > > file or directory.
  > 
  > > if the code is changed so that emacsclient called with no arguments
  > > displays the startup screen __by default__, then we might have yet
  > > another long discussion if this is the right thing to do.
  > 
  > I do not understand what you mean.

Currently:
emacs -q -f server-start

emacsclient -t
shows the *scratch* buffer.

Will the proposed change will make
emacsclient -t
show the startup screen?

If yes, then IMO it's not a good idea to implement such a change of
behavior at this time.






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
       [not found]             ` <200904140235.n3E2Zp0J008505@godzilla.ics.uci.edu>
@ 2009-04-14  3:49               ` Stefan Monnier
  0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2009-04-14  3:49 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Chong Yidong, 2825, emacs-devel

> Will the proposed change will make
> emacsclient -t
> show the startup screen?

Of course not.  We're only talking about the case where "the user
has set initial-buffer-choice to some file name".


        Stefan






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon
  2009-03-30 13:57 bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon Damien Cassou
@ 2012-04-20 10:05 ` Chong Yidong
  0 siblings, 0 replies; 11+ messages in thread
From: Chong Yidong @ 2012-04-20 10:05 UTC (permalink / raw)
  To: Damien Cassou; +Cc: 2825

Damien Cassou <damien.cassou@gmail.com> writes:

> the new variable initial-buffer-choice seems useless when using emacs
> as a daemon and emacsclient. This variable probably sets the initial
> frame of the daemon, but does not affect the emacs clients. The buffer
> is opened but not visible, the *scratch* buffer is opened instead.

I've changed the trunk to reflect this behavior.  Thanks.





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-04-20 10:05 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-30 13:57 bug#2825: 23.0.91; initial-buffer-choice useless with emacs daemon Damien Cassou
2012-04-20 10:05 ` Chong Yidong
  -- strict thread matches above, loose matches on Subject: below --
2009-04-10  2:25 Chong Yidong
     [not found] <87ocv5mei7.fsf@cyd.mit.edu>
2009-04-11 15:13 ` Dan Nicolaescu
     [not found] ` <200904111513.n3BFD6fp012593@godzilla.ics.uci.edu>
2009-04-11 18:34   ` Stefan Monnier
2009-04-11 23:34     ` Dan Nicolaescu
     [not found]     ` <200904112334.n3BNYwuE019572@godzilla.ics.uci.edu>
2009-04-13 17:51       ` Stefan Monnier
2009-04-13 18:13         ` Dan Nicolaescu
     [not found]         ` <200904131813.n3DIDinI026826@godzilla.ics.uci.edu>
2009-04-14  2:07           ` Stefan Monnier
2009-04-14  2:35             ` Dan Nicolaescu
     [not found]             ` <200904140235.n3E2Zp0J008505@godzilla.ics.uci.edu>
2009-04-14  3:49               ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).