GNU bug report logs - #37826
Very annoying autoraise client/server behavior with -t option

Previous Next

Full log

Message #8 received at 37826 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 37826 <at> debbugs.gnu.org
Subject: Re: Very annoying autoraise client/server behavior with -t option
Date: Sat, 19 Oct 2019 18:39:31 -0300

I think I need some feedback in order to advance. I would like to do
something like:

```
frame = create-frame-func()
with-selected-frame frame:
    buffers = server-visit-files(files)
```

so that visiting messages show in the right frame. But this introduces
circularity, since frame is currently obtained as:

```
buffers = server-visit-files(files)
with-current-buffer car(buffers):
     frame = create-frame-func()
```

with the following rationale:

   ;; Set current buffer so that newly created tty frames
   ;; show the correct buffer initially.

So, short of deeper modifications, I could just let the messages show
in the wrong minibuffer and restrict the scope of auto-rise-minibuffer
to buffer reverting/writing questions:

```
            (cond ((file-exists-p filen)
                   (when (not (verify-visited-file-modtime obuf))
                     (revert-buffer t nil)))
                  (t
                   (when (y-or-n-p
                          (concat "File no longer exists: " filen
                                  ", write buffer to file? "))
                     (write-file filen))))
```

Nevertheless, not only the messages will show in the wrong minibuffer
but the questions will also be asked in the wrong place, although
these questions should happen exceptionally.

I believe one way or another there is some price to pay here: do we
prefer for the frame to be created with the right buffer from the very
beginning, at the expense of ill-placed messages and questions? Or do
we prefer to show this stuff in the new frame minibuffer, while
postponing the setting of its initial buffer until all files are
visited, producing a frequent and unpleasant switching visual artifact
(which AFAICR has been always the case, has this code changed recently
in order to address that?) ?

Of course, the first option is easier to implement since it's closer
to what there already exists. Also, insofar we avoid the autoraise
issue, the problem should be less noticeable than the "initial switch"
effect.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.