Re: Pretest?

[David Kastrup]

"Juanma Barranquero" <address@hidden> writes:

> On 3/14/07, Richard Stallman <address@hidden> wrote:
>
>> I thought they complained because the buffer was not visible.
>
> The reporter said: "emacsclient seems to interrupt find-file,
> swith-to-buffer and areas marked to be copied, so I think it is
> somewhat inconsistent not to quit isearch and put the new buffer on
> top."
>
> We haven't done a poll of user expectations with respect to
> emacsclient, but I certainly wouldn't just expect the buffer to be
> visible, but selected as well.
>
> Cancelling isearch is not something done in extreme circunstances;
> almost anything you type or do will cancel it (like switching to
> another frame). What's so special in cancelling it from emacsclient?

Agreed.  However, we should still come up with a suitable strategy
concerning what we should do when we are in a minibuffer for other
reasons (such as M-x).

My initial impulse would be to let an emacsclient call behave like C-x
C-f: this would with the default setting of
enable-recursive-minibuffers (nil) cancel the minibuffer command,
return to a non-minibuffer window and open the given file there.

With enable-recursive-minibuffers to t, however, would then cause the
message "Cannot switch buffers in minibuffer window".

Suboptimal.  But at least for the default settings, the behavior would
be very much like what is expected.

And I think even in the case where emacsclient -eval is used, the
assumption of "clear minibuffer usage" seems reasonable, since that is
somewhat equivalent to using M-:

-- 
David Kastrup