bug#18175: files.el: use mapc in (mapcar 'switch-to-buffer ...)

[Ivan Shmakov <ivan@siamics.net>]

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

[…]

 > Your new patch does that, and it looks OK to me.  I did not spend
 > much time looking things over, so I might be missing something, but
 > it looks like you are not changing the external behavior (good).

 > It is fine to optimize things, but function interfaces (signatures
 > and behavior as viewed by calling functions or by users) should not
 > be altered.

	I expect neither of these patches to change the external
	behavior.

 > You might want to make sure that the list of buffers returned is the
 > same in all cases as what is returned today.  The doc string of
 > `switch-to-buffer', for instance, seems to make a point of saying
 > that it returns the buffer switched to.  It does not say that it
 > returns the buffer indicated by argument BUFFER-OR-NAME.  Dunno why,
 > but it does.

	I guess it’s because switch-to-buffer passes its argument
	through window-normalize-buffer-to-switch-to, which passes it
	through get-buffer in turn.  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.

 > 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.

 > 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.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A