bug#21505: 24.4; Buffer order

[hoppe <travis.hoppe@gmail.com>]

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

In response to the first question, I'd like this to be the "easy" request,
that this behavior is only for when emacs opens and not continuously during
the session. I agree, it does not need to be maintained during the session.

Re: Tassilo Horn: I purposely showed my example with a wildcard since emacs
could be given any expansion from the shell. To me it, and for my usual use
case, it doesn't matter. I have a bunch of files I'd like to edit and I
often miss those that are past the messages and scratch buffer. Opening the
files in the order given from the command line seems very natural to me.

So to be clear, given the command run on the shell:

> emacs a c b

The buffer order should be [a,c,b,*messages*,*scratch*]. Currently the
default behavior looks something like [b,c,*messages*,*scratch*, a].

On Thu, Sep 17, 2015 at 10:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  21505@debbugs.gnu.org,
> travis.hoppe@gmail.com
> > Date: Thu, 17 Sep 2015 08:50:33 -0400
> >
> > > No, it should always be as given to emacs/emacsclient, i.e., when I
> > > invoke
> > >
> > >   $ emacsclient x a b
> > >
> > > I want to have the buffer x selected and using `next-buffer' I'd switch
> > > to a and then b, and then to the other buffers which have existed
> > > before.  Right now, x will be selected, but a and b are far away.
> >
> > That's right.  And same for "emacs x a b".
> >
> > The precise behavior is a bit more complex since those commands, rather
> > than just showing the first file may/will also show the buffer-list,
> > but if exactly one of the files is shown it should be the first in the
> > list and next-buffer should go in the order in which the file names
> > were given (until reaching the end of this list at which point it'll
> > hit things like *Messages* and friends and that's fine).
>
> The questions I asked the OP still stand.  The required feature is not
> defined in sufficient detail.  If only the initial order is required,
> it's probably relatively easy, but then that order is very fragile and
> could easily break as soon as the user issues the first command.
>

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