all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Ivan Shmakov <ivan@siamics.net>, 18175@debbugs.gnu.org
Subject: bug#18175: files.el: use mapc in (mapcar 'switch-to-buffer ...)
Date: Sun, 3 Aug 2014 11:43:48 -0700 (PDT)	[thread overview]
Message-ID: <7ac7622e-acbc-43ee-a58d-d1d97d3e8f16@default> (raw)
In-Reply-To: <87ha1tfn25.fsf@violet.siamics.net>

> The docstring for the latter reads:
> … If BUFFER-OR-NAME is a buffer, return it as given.
> And I see no reason for a buffer /name/ to ever appear in the
> lists returned from find-file-noselect.

Yes, of course not.  It needs to return a list of buffers. That's why I
wrote that we need to "make sure that the list of buffers returned is
the same in all cases as what is returned today." ^^^^^^^

>  > I'm guessing that that can make a difference only if the intended
>  > buffer cannot be switched to (an error is raised).  And in that case
>  > I'm guessing that the error raised would be handled correctly by
>  > `find-file*'.  (I have not checked.)
> 
> 	As there’re no condition-case forms around switch-to-buffer
> 	calls in find-file et al. – no such error will be handled in any
> 	special way, and will just be signalled to the user as usual.

That all I meant by handled (treated) by `find-file*', not that
there is a `condition-case' with a handler.  The point is that the
behavior should remain the same; that's all.  If it does, fine.

>  > You might also want to check to be sure that the effect on what
>  > `buffer-list' returns (after the calls to `switch-buffer*') remains
>  > the same.
> 
> 	AIUI, the buffer-list result depends solely on the order of
> 	calls to switch-to-buffer, which is /not/ changed in any way.
> 
>  > The calls to `switch-to-buffer*' here do not use non-nil NORECORD, so
>  > that at least can be ignored.  But maybe take a look, to make sure.
>  > Some commands and other functions depend on the buffer order in
>  > `buffer-list', so this too should not be altered by your proposed
>  > change.

Thanks for looking at and testing these things.





  reply	other threads:[~2014-08-03 18:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-02 21:55 bug#18175: files.el: use mapc in (mapcar 'switch-to-buffer ...) Ivan Shmakov
2014-08-03  0:55 ` Drew Adams
2014-08-03  8:55   ` Ivan Shmakov
2014-08-03 16:32     ` Drew Adams
2014-08-03 18:25       ` Ivan Shmakov
2014-08-03 18:43         ` Drew Adams [this message]
2014-08-06 17:26 ` Stefan Monnier
2014-08-07 19:15   ` Ivan Shmakov
2014-08-07 19:29     ` Stefan Monnier
2015-01-23 15:27       ` Ivan Shmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ac7622e-acbc-43ee-a58d-d1d97d3e8f16@default \
    --to=drew.adams@oracle.com \
    --cc=18175@debbugs.gnu.org \
    --cc=ivan@siamics.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.