From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
Cc: 28814@debbugs.gnu.org
Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost )
Date: Wed, 25 Oct 2017 03:24:58 +0300 [thread overview]
Message-ID: <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> (raw)
In-Reply-To: <87fua91vis.fsf@gmail.com>
On 10/23/17 11:03 PM, João Távora wrote:
> I read the discussion you pointed me to me by Dmitry in
> http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01235.html.
>
> Eli, If I understand your concerns there, then the first and third
> patches I proposed shouldn't in any way interfere with your use of
> *xref*-related facilities. If anything, they should improve it.
Overall, I don't have strong objections, so if Eli is fine with the new
behavior all around, I don't mind getting them in (with maybe a few
modifications), and hopefully we'll reach some better solutions by the
next release.
For some more context though: previously, I've tried to make it seem
"like xref buffer was never there" after the user performed the
navigation, in other respects too:
- As we recall, the xref buffer was buried after the user performed the
navigation.
- The window configuration was fully restored to the one before the xref
buffer was shown (with some checks like making sure the user didn't
change the configuration manually thereafter), and then the navigation
was performed. After that, using the "originally intended" window or
frame was much easier.
- All buffers that were opened just to show the xref locations were
cleaned up (closed) after the navigation was performed.
...But in the end, all this stuff worked not reliably/fast/intuitively
enough, and I came to the conclusion that it's not a good choice when we
have an *xref* buffer that stays around for a long time. So it was removed.
Now to your patches.
> * 0003-Allow-split-window-sensibly-to-split-threshold-in-fu.patch
>
> This extends the exception granted by split-window-sensibly to
> single-window frames whose dimensions are below those of splitting
> thresholds to consider multi-window frames where all but one window is
> dedicated.
If there are other non-dedicated windows, will one of them be used (that
would seem fine)?
> In practice, it fixes the case where
>
> C-x 4 . xref-backend-definitions RET n
>
> would surprisingly pop-up a new frame if the original frame was already
> small to start with.
>
> This fix to window.el appears very sound to me, but if it is not desired
> for whatever reason, a more localized fix in xref.el is also possible.
A fix in xref.el sounds more prudent to me, but someone else would have
to comment on window.el.
> * 0004-Don-t-quit-xref-window-on-RET-only-on-C-u-RET.patch
>
> This fixes the "disappearing *xref* problem", by bringing back the
> default behaviour of not quitting the *xref* window on RET, although
> allowing for that if the user types C-u RET instead.
I have to wonder if we have other commands that quit the current window
when called with a prefix. Particularly commands bound to RET.
next prev parent reply other threads:[~2017-10-25 0:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 16:07 bug#28814: 26.0.90; When *xref* window is needed, original window-switching intent is lost João Távora
[not found] ` <handler.28814.B.150791088020837.ack@debbugs.gnu.org>
2017-10-16 17:58 ` bug#28814: Acknowledgement (26.0.90; When *xref* window is needed, original window-switching intent is lost ) João Távora
2017-10-20 9:13 ` bug#28814: [BUMP, PATCH] " João Távora
2017-10-20 10:39 ` Dmitry Gutov
2017-10-23 2:06 ` Dmitry Gutov
2017-10-23 8:23 ` João Távora
2017-10-23 20:03 ` João Távora
2017-10-25 0:24 ` Dmitry Gutov [this message]
2017-10-25 7:43 ` João Távora
2017-10-25 10:24 ` Dmitry Gutov
2017-10-25 13:29 ` João Távora
2017-10-25 14:49 ` Dmitry Gutov
2017-10-25 15:35 ` João Távora
2017-10-25 15:46 ` Dmitry Gutov
2017-10-25 15:11 ` Eli Zaretskii
2017-10-25 15:27 ` João Távora
2017-10-25 15:39 ` Eli Zaretskii
2017-10-25 20:56 ` João Távora
2017-10-26 7:56 ` martin rudalics
2017-10-26 16:42 ` Eli Zaretskii
2017-10-26 22:40 ` Dmitry Gutov
2017-10-27 0:05 ` João Távora
2017-11-02 17:06 ` Dmitry Gutov
2017-10-26 23:59 ` João Távora
2017-10-28 9:41 ` Eli Zaretskii
2017-10-28 19:19 ` João Távora
2017-11-02 17:03 ` João Távora
2017-11-02 17:07 ` Eli Zaretskii
2017-11-02 19:07 ` João Távora
2017-11-02 19:32 ` Eli Zaretskii
2017-11-03 13:47 ` Eli Zaretskii
2017-11-03 16:18 ` João Távora
2017-11-03 19:06 ` Eli Zaretskii
2017-10-26 12:39 ` Dmitry Gutov
2017-10-25 7:46 ` martin rudalics
2017-10-25 13:19 ` João Távora
2017-10-26 7:56 ` martin rudalics
2017-10-25 0:07 ` Dmitry Gutov
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=13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru \
--to=dgutov@yandex.ru \
--cc=28814@debbugs.gnu.org \
--cc=joaotavora@gmail.com \
/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.