unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 47300@debbugs.gnu.org
Subject: bug#47300: delete-window to select window with same position
Date: Mon, 31 May 2021 23:46:49 +0300	[thread overview]
Message-ID: <87k0nefwq6.fsf@mail.linkov.net> (raw)
In-Reply-To: <63612145-5eaa-0766-30cc-f30f7e7e1700@gmx.at> (martin rudalics's message of "Thu, 27 May 2021 17:20:51 +0200")

> +	 (when (and (>= x (nth 0 edges)) (< x (nth 2 edges))
> +		    (>= y (nth 1 edges)) (< y (nth 3 edges)))
>
> We have to mention the "<" somewhere.  For two side-by-side windows with
> the right window's point at 1, we obviously must avoid the left window's
> right edge because the X, Y coordinates set by pos_visible_p are the top
> left edge of the character box at that position, i.e., 0, 0.
>
> But OTOH the "<" leaves the right edge of a frame's rightmost window
> unhandled and someone might use that function for other purposes.

I changed <= to < to fix only Y coordinates for top/bottom windows,
but maybe X coordinates should still use <= ?

> It would be a tad more elegant to just save `posn-at-point' here ...
>
> +              (setq posn-at-point-x (+ (nth 0 edges) (car posn-at-point))
> +                    posn-at-point-y (+ (nth 1 edges) (cdr posn-at-point))))))
>  	;; Actually delete WINDOW.
>  	(delete-window-internal window)
>  	(window--pixel-to-total frame horizontal)
> -	(when (and frame-selected
>
> ... and delay extracting its car and cdr until here.
>
> +        (when (and posn-at-point-x posn-at-point-y
> +		   (setq window-at-posn-at-point
> +			 (window-at-pos posn-at-point-x posn-at-point-y frame)))

Please note that the crucial difference is that now it uses
frame relative positions rather than window relative ones
with '(window-edges window nil nil t)' of the window to be deleted,
and window coordinates added to X and Y of posn-at-point.

> I'd still urge you to transfer the `get-mru-window' call here too, that
> is, the entire
>
> 	  /* Now look whether `get-mru-window' gets us something.  */
> 	  mru_window = call1 (Qget_mru_window, frame);
> 	  if (WINDOW_LIVE_P (mru_window)
> 	      && EQ (XWINDOW (mru_window)->frame, frame))
> 	    new_selected_window = mru_window;
>
> 	  /* If all ended up well, we now promote the mru window.  */
> 	  if (EQ (FRAME_SELECTED_WINDOW (f), selected_window))
> 	    Fselect_window (new_selected_window, Qnil);
> 	  else
> 	    fset_selected_window (f, new_selected_window);
>
> block, and to include the
>
>         (when (and frame-selected
> 		   (window-parameter
> 		    (frame-selected-window frame) 'no-other-window))
> 	  ;; `delete-window-internal' has selected a window that should
> 	  ;; not be selected, fix this here.
> 	  (other-window -1 frame))
>
> so we can avoid selecting a new window up to four times when deleting a
> window (the one remaining call in `delete-window-internal' does not
> record the window and has to stay there).  It's simply not nice to do
> that.

1. `get-mru-window' could be one possible choice of the new option.
2. `use-posn-at-point' could be another choice.
3. Selecting the first window could remain in `delete-window-internal'.
4. But what to do with this code block with '(other-window -1 frame)'?
   Should this be simply deleted?





  reply	other threads:[~2021-05-31 20:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21 20:31 bug#47300: delete-window to select window with same position Juri Linkov
2021-05-18 14:49 ` Lars Ingebrigtsen
2021-05-18 16:00   ` martin rudalics
2021-05-18 20:17     ` Juri Linkov
2021-05-19  7:42       ` martin rudalics
2021-05-19 16:07         ` Juri Linkov
2021-05-19 17:41           ` martin rudalics
2021-05-22  8:05             ` martin rudalics
2021-05-22 21:25               ` Juri Linkov
2021-05-23  8:43                 ` martin rudalics
2021-05-25  6:50                 ` martin rudalics
2021-05-26 21:29                   ` Juri Linkov
2021-05-27 15:20                     ` martin rudalics
2021-05-31 20:46                       ` Juri Linkov [this message]
2021-06-02  9:08                         ` martin rudalics
2021-06-03 21:20                           ` Juri Linkov
2021-06-04  9:19                             ` martin rudalics
2021-06-04 16:29                               ` Juri Linkov
2021-06-06  7:43                                 ` martin rudalics
2021-06-06 20:47                                   ` Juri Linkov
2021-06-07  7:35                                     ` martin rudalics
2021-06-07 21:00                                       ` Juri Linkov
2021-06-10  7:44                                         ` martin rudalics
2021-06-11 17:06                                           ` Juri Linkov

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87k0nefwq6.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=47300@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=rudalics@gmx.at \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).