GNU bug report logs -
#76084
31.0.50; Dragging tab line does not resize windows, unlike header line or mode line
Previous Next
Reported by: Jared Finder <jared <at> finder.org>
Date: Thu, 6 Feb 2025 06:09:01 UTC
Severity: normal
Fixed in version 31.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #23 received at 76084 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-02-10 02:15, martin rudalics wrote:
>> To handle this I would need to add checks against the down-mouse-1
>> keybinding before setting the mouse icon. I'm just worried about
>> performance here since looking up the keymap would get run on mouse
>> motion.
>
> I think there's no reason to bother about 'ruler-mode'. IIRC, apart
> from the scroll bar, the ruler has no "empty space" and dragging should
> mostly happen in a horizontal fashion.
Attached is a patch that adds the vertical scroll icon for header and
tab lines. I also altered ruler-mode so that dragging works with it as
well as it has no real reason to block dragging AFAICT. Similar changes
would be needed in other packages if the desire is to be aligned with
the newly shown drag icon. The only way to outright hide the drag icon
is to add a keymap via text properties, which is already the case for
the mode line. If this (small) breakage seems acceptable, then I think
this is strictly better.
The alternative here is to add a call to Fkey_binding in
note_line_or_margin_highlight to check what the down-mouse-1 binding is.
Let me know if that is more appropriate. I'm just nervous because
there are comments about Fkey_binding maybe causing GC and in general is
seems much more heavyweight an operation for each mouse move.
-- MJF
[0001-Show-drag-cursor-on-all-window-lines-mode-tab-header.patch (text/x-diff, attachment)]
This bug report was last modified 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.