GNU bug report logs - #76934
31.0.50; rectangle-mark-mode resets fringe-mode settings

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76934 in the body.
You can then email your comments to 76934 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 31.0.50; rectangle-mark-mode resets fringe-mode settings
Date: Tue, 11 Mar 2025 08:06:40 +0000

[Message part 1 (text/plain, inline)]

If i set the fringe-mode with the 'minimal' option, then using the
rectangle-mark-mode resets it.

Steps to reproduce:

1. emacs -Q
2. In the scratch buffer evaluate this code:

(global-display-line-numbers-mode 1)
(setq display-line-numbers 'visual
display-line-numbers-type 'relative)

3. M-x fringe-mode (choose the minimal option)
4. M-x rectangle-mark-mode

You will see that the fringe area reappeared again.

In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.0) of 2025-03-10 built on ub-void
Repository revision: b568ff418ce7147c27d7f82fe4a8eef325b9de2c
Repository branch: HEAD
System Description: Void Linux

Configured using:
'configure --with-native-compilation=aot --with-tree-sitter --with-gif
--with-png --with-jpeg --with-rsvg --with-tiff --with-imagemagick
--with-pgtk --with-mailutils'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK JPEG
LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
XIM GTK3 ZLIB

Important settings:
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Org

Minor modes in effect:
org-appear-mode: t
windmove-mode: t
savehist-mode: t
meow-global-mode: t
meow-mode: t
meow-normal-mode: t
meow-esc-mode: t
envrc-global-mode: t
envrc-mode: t
buffer-terminator-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
marginalia-mode: t
vertico-mode: t
corfu-popupinfo-mode: t
corfu-history-mode: t
corfu-echo-mode: t
global-corfu-mode: t
corfu-mode: t
which-key-mode: t
undo-fu-session-global-mode: t
undo-fu-session-mode: t
global-treesit-auto-mode: t
global-auto-revert-mode: t
save-place-mode: t
electric-pair-mode: t
recentf-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
override-global-mode: t
tooltip-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
auto-fill-function: org-auto-fill-function
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
/home/wurfkreuz/.emacs.d/elpa/transient-20250306.1916/transient hides /usr/local/share/emacs/31.0.50/lisp/transient

Features:
(shadow sort mail-extr emacsbug rect cus-start python vc-git
vc-dispatcher org-appear image-file image-converter oc-basic ol-eww eww
vtable url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range gnus-win gnus nnheader range ol-docview
doc-view jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m
ol-doi org-link-doi misearch multi-isearch windmove dired-aux help-fns
radix-tree mule-util tramp-cmds savehist f eshell em-tramp esh-cmd
esh-ext esh-proc esh-opt esh-io esh-arg esh-module esh-module-loaddefs
esh-util meow meow-tutor meow-cheatsheet meow-cheatsheet-layout
meow-core meow-shims meow-esc meow-command array meow-thing meow-visual
meow-keypad meow-beacon meow-helpers meow-util meow-keymap meow-face
meow-var delsel org-tempo tempo org-drill persist org-agenda embark-org
org-element org-persist org-id org-refile org-element-ast inline
avl-tree org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-src ob-comint org-pcomplete org-list org-footnote org-faces
org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol
org-fold org-fold-core org-keys oc org-version org-loaddefs cal-menu
calendar cal-loaddefs org-compat org-macs eglot external-completion
jsonrpc xref ert ewoc debug backtrace kdl-mode generic markdown-mode
color nix-mode nix-repl nix-shell nix-store nix-log nix-instantiate
nix-shebang nix-format nix yaml-mode dockerfile-mode terraform-mode
noutline outline hcl-mode lua-mode perl-mode flymake envrc inheritenv
buffer-terminator magit-bookmark magit-submodule magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff git-commit log-edit message sendmail
yank-media puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils
mailheader pcvs-util add-log magit-core magit-autorevert magit-margin
magit-transient magit-process magit-mode benchmark magit-git magit-base
magit-section cursor-sensor crm llama nerd-icons nerd-icons-faces
nerd-icons-data nerd-icons-data-mdicon nerd-icons-data-flicon
nerd-icons-data-codicon nerd-icons-data-devicon nerd-icons-data-sucicon
nerd-icons-data-wicon nerd-icons-data-faicon nerd-icons-data-powerline
nerd-icons-data-octicon nerd-icons-data-pomicon nerd-icons-data-ipsicon
smerge-mode diff-mode track-changes diff hydra lv with-editor server
embark-consult embark ffap thingatpt consult bookmark marginalia vertico
project cape corfu-popupinfo corfu-history corfu-echo corfu orderless
wgrep grep compile text-property-search which-key docker docker-context
docker-volume docker-network docker-image docker-container docker-faces
docker-core docker-compose docker-process docker-utils tablist advice
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local find-func cedet dired
dired-loaddefs tramp trampver tramp-integration files-x tramp-message
tramp-compat shell pcomplete comint ansi-osc ring parse-time iso8601
time-date ansi-color tramp-loaddefs docker-group transient format-spec
edmacro kmacro compat dash aio generator s goto-chg undo-fu-session
undo-fu zig-ts-mode clojure-ts-mode treesit-auto crontab-mode sh-script
smie treesit executable rose-pine-theme cus-edit pp cus-load midnight
autorevert filenotify saveplace desktop frameset elec-pair recentf
tree-widget wid-edit comp comp-cstr warnings comp-run comp-common rx
display-line-numbers cl-extra help-mode use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core finder-inf buffer-terminator-autoloads
cape-autoloads clojure-ts-mode-autoloads corfu-autoloads
crontab-mode-autoloads docker-autoloads aio-autoloads
dockerfile-mode-autoloads embark-consult-autoloads consult-autoloads
embark-autoloads envrc-autoloads evil-collection-autoloads
annalist-autoloads evil-numbers-autoloads evil-surround-autoloads
evil-autoloads evil-textobj-tree-sitter-autoloads f-autoloads
goto-chg-autoloads hydra-autoloads inheritenv-autoloads
lua-mode-autoloads lv-autoloads magit-autoloads pcase
marginalia-autoloads markdown-mode-autoloads meow-autoloads
nerd-icons-autoloads nix-mode-autoloads magit-section-autoloads
llama-autoloads orderless-autoloads org-appear-autoloads
org-drill-autoloads persist-autoloads s-autoloads tablist-autoloads
tempel-collection-autoloads tempel-autoloads terraform-mode-autoloads
dash-autoloads hcl-mode-autoloads transient-autoloads
treesit-auto-autoloads undo-fu-autoloads undo-fu-session-autoloads
vertico-autoloads wgrep-autoloads info with-editor-autoloads
yaml-mode-autoloads zig-ts-mode-autoloads package browse-url xdg url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win touch-screen pgtk-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

Memory information:
((conses 16 869177 147070) (symbols 48 51473 0) (strings 32 260806 10351)
(string-bytes 1 7871353) (vectors 16 86909) (vector-slots 8 1037340 57298)
(floats 8 745 306) (intervals 56 6731 2128) (buffers 992 18))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: the_wurfkreuz <the_wurfkreuz <at> proton.me>
Cc: 76934 <at> debbugs.gnu.org
Subject: Re: bug#76934: 31.0.50;
 rectangle-mark-mode resets fringe-mode settings
Date: Tue, 11 Mar 2025 15:25:15 +0200

> Date: Tue, 11 Mar 2025 08:06:40 +0000
> From:  the_wurfkreuz via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> If i set the fringe-mode with the 'minimal' option, then using the
> rectangle-mark-mode resets it.
> 
> Steps to reproduce:
> 
> 1. emacs -Q
> 2. In the scratch buffer evaluate this code:
> 
> (global-display-line-numbers-mode 1)
> (setq display-line-numbers 'visual
>       display-line-numbers-type 'relative)
> 
> 3. M-x fringe-mode (choose the minimal option)
> 4. M-x rectangle-mark-mode
> 
> You will see that the fringe area reappeared again.

I cannot reproduce this.  Maybe this is GTK-specific?  Or maybe I
don't understand what you mean by "fringe area reappeared"?

I made the fringe background be red, to make it easier spotted, and
performed your recipe: I see the same 1-pixel fringe before and after
I invoke rectangle-mark-mode.

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

From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76934 <at> debbugs.gnu.org
Subject: Re: bug#76934: 31.0.50;
 rectangle-mark-mode resets fringe-mode settings
Date: Tue, 11 Mar 2025 14:34:09 +0000

[Message part 1 (text/plain, inline)]

Sorry for the bad report.
Initially, there is the fringe area (shown in the attached file called "first-screenshot"). I can interactively execute the fringe-mode command it choose the 'minimal' option. It makes the fringe area to visually disappear and emacs adjusts the space between the fringe of the window and line numbers accordingly (shown in the second-screenshot). Then i use the rectangle-mark-mode command and doing so returns the space that was previously taken by the fringe area back (shown in the third-screenshot). Yes, the added space doesn't use any highlighting, so you can't verify it by looking at the highlighting for the fringe-area, my description was confusing on that part.



On Tuesday, March 11th, 2025 at 1:25 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Tue, 11 Mar 2025 08:06:40 +0000
> > From: the_wurfkreuz via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" bug-gnu-emacs <at> gnu.org
> > 
> > If i set the fringe-mode with the 'minimal' option, then using the
> > rectangle-mark-mode resets it.
> > 
> > Steps to reproduce:
> > 
> > 1. emacs -Q
> > 2. In the scratch buffer evaluate this code:
> > 
> > (global-display-line-numbers-mode 1)
> > (setq display-line-numbers 'visual
> > display-line-numbers-type 'relative)
> > 
> > 3. M-x fringe-mode (choose the minimal option)
> > 4. M-x rectangle-mark-mode
> > 
> > You will see that the fringe area reappeared again.
> 
> 
> I cannot reproduce this. Maybe this is GTK-specific? Or maybe I
> don't understand what you mean by "fringe area reappeared"?
> 
> I made the fringe background be red, to make it easier spotted, and
> performed your recipe: I see the same 1-pixel fringe before and after
> I invoke rectangle-mark-mode.

[first-screenshot.png (image/png, attachment)]

[second-screenshot.png (image/png, attachment)]

[third-screenshot.png (image/png, attachment)]

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: the_wurfkreuz <the_wurfkreuz <at> proton.me>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76934 <at> debbugs.gnu.org
Subject: Re: bug#76934: 31.0.50; rectangle-mark-mode resets fringe-mode
 settings
Date: Tue, 11 Mar 2025 17:50:50 +0100

On Tue, 11 Mar 2025 14:34:09 +0000 the_wurfkreuz <the_wurfkreuz <at> proton.me> wrote:

> Sorry for the bad report.
> Initially, there is the fringe area (shown in the attached file called
> "first-screenshot"). I can interactively execute the fringe-mode command it
> choose the 'minimal' option. It makes the fringe area to visually disappear
> and emacs adjusts the space between the fringe of the window and line numbers
> accordingly (shown in the second-screenshot). Then i use the
> rectangle-mark-mode command and doing so returns the space that was previously
> taken by the fringe area back (shown in the third-screenshot). Yes, the added
> space doesn't use any highlighting, so you can't verify it by looking at the
> highlighting for the fringe-area, my description was confusing on that part.

I can reproduce the problem in the emacs-29, -30 and master branches on
GNU/Linux (I cannot currently test earlier builds).  It appears to be an
interaction between display-line-numbers-mode and rectangle-mark-mode:

0. emacs -Q
1. M-: (car (window-absolute-pixel-position))
   => 88
2. M-x display-line-numbers-mode
3. M-: (car (window-absolute-pixel-position))
   => 120
4. C-x SPC
5. M-: (car (window-absolute-pixel-position))
   => 130
6. C-g
7. M-: (car (window-absolute-pixel-position))
   => 128

After disabling and then re-enabling display-line-numbers-mode the extra
space appears without enabling rectangle-mark-mode:

8. M-x display-line-numbers-mode
9. M-: (car (window-absolute-pixel-position))
   => 88
10. M-x display-line-numbers-mode
11. M-: (car (window-absolute-pixel-position))
   => 128

Splitting the window vertically removes the extra space (but splitting
it horizontally (C-x 3) does not):

12. C-x 2
13. M-: (car (window-absolute-pixel-position))
   => 120

On restoring the single window the extra space reappears:

14. C-x 1
15. M-: (car (window-absolute-pixel-position))
   => 128

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: the_wurfkreuz <the_wurfkreuz <at> proton.me>
Cc: 76934 <at> debbugs.gnu.org
Subject: Re: bug#76934: 31.0.50;
 rectangle-mark-mode resets fringe-mode settings
Date: Tue, 11 Mar 2025 19:16:44 +0200

> Date: Tue, 11 Mar 2025 14:34:09 +0000
> From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
> Cc: 76934 <at> debbugs.gnu.org
> 
> Initially, there is the fringe area (shown in the attached file called "first-screenshot"). I can interactively execute the fringe-mode command it choose the 'minimal' option. It makes the fringe area to visually disappear and emacs adjusts the space between the fringe of the window and line numbers accordingly (shown in the second-screenshot). Then i use the rectangle-mark-mode command and doing so returns the space that was previously taken by the fringe area back (shown in the third-screenshot). Yes, the added space doesn't use any highlighting, so you can't verify it by looking at the highlighting for the fringe-area, my description was confusing on that part.

Looks like Emacs decided it needed one more columns for the line
numbers, probably because the current line moved to line 9, and maybe
also because the window's glyph matrix was enlarged for some reason.
IOW, this has nothing to do with the fringes.

Message #22 received at 76934-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: the_wurfkreuz <at> proton.me
Cc: 76934-done <at> debbugs.gnu.org
Subject: Re: bug#76934: 31.0.50;
 rectangle-mark-mode resets fringe-mode settings
Date: Sat, 29 Mar 2025 14:13:09 +0300

> Cc: 76934 <at> debbugs.gnu.org
> Date: Tue, 11 Mar 2025 19:16:44 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Tue, 11 Mar 2025 14:34:09 +0000
> > From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
> > Cc: 76934 <at> debbugs.gnu.org
> > 
> > Initially, there is the fringe area (shown in the attached file called "first-screenshot"). I can interactively execute the fringe-mode command it choose the 'minimal' option. It makes the fringe area to visually disappear and emacs adjusts the space between the fringe of the window and line numbers accordingly (shown in the second-screenshot). Then i use the rectangle-mark-mode command and doing so returns the space that was previously taken by the fringe area back (shown in the third-screenshot). Yes, the added space doesn't use any highlighting, so you can't verify it by looking at the highlighting for the fringe-area, my description was confusing on that part.
> 
> Looks like Emacs decided it needed one more columns for the line
> numbers, probably because the current line moved to line 9, and maybe
> also because the window's glyph matrix was enlarged for some reason.
> IOW, this has nothing to do with the fringes.

No further comments, so I'm now closing this bug.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 76934 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, the_wurfkreuz <at> proton.me
Subject: Re: bug#76934: 31.0.50; rectangle-mark-mode resets fringe-mode
 settings
Date: Sat, 29 Mar 2025 12:41:47 +0100

On Sat, 29 Mar 2025 14:13:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Cc: 76934 <at> debbugs.gnu.org
>> Date: Tue, 11 Mar 2025 19:16:44 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> > Date: Tue, 11 Mar 2025 14:34:09 +0000
>> > From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
>> > Cc: 76934 <at> debbugs.gnu.org
>> >
>> > Initially, there is the fringe area (shown in the attached file called
>> > "first-screenshot"). I can interactively execute the fringe-mode command
>> > it choose the 'minimal' option. It makes the fringe area to visually
>> > disappear and emacs adjusts the space between the fringe of the window and
>> > line numbers accordingly (shown in the second-screenshot). Then i use the
>> > rectangle-mark-mode command and doing so returns the space that was
>> > previously taken by the fringe area back (shown in the
>> > third-screenshot). Yes, the added space doesn't use any highlighting, so
>> > you can't verify it by looking at the highlighting for the fringe-area, my
>> > description was confusing on that part.
>>
>> Looks like Emacs decided it needed one more columns for the line
>> numbers, probably because the current line moved to line 9, and maybe
>> also because the window's glyph matrix was enlarged for some reason.
>> IOW, this has nothing to do with the fringes.
>
> No further comments, so I'm now closing this bug.

The observations I made in this thread (that the extra space is
triggered by rectangle-mark-mode but remains after cancelling
rectangle-mark-mode, and that splitting the window vertically removes
the extra space) involve a buffer with only three lines, and regardless
of the number of lines I think they indicate buggy or at least
surprising behavior.  Does closing the bug mean you think the observed
behavior is fine, and if so, why is it fine?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76934 <at> debbugs.gnu.org, the_wurfkreuz <at> proton.me
Subject: Re: bug#76934: 31.0.50; rectangle-mark-mode resets fringe-mode
 settings
Date: Sat, 29 Mar 2025 15:34:20 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: eliz <at> gnu.org,  the_wurfkreuz <at> proton.me
> Date: Sat, 29 Mar 2025 12:41:47 +0100
> 
> On Sat, 29 Mar 2025 14:13:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> Cc: 76934 <at> debbugs.gnu.org
> >> Date: Tue, 11 Mar 2025 19:16:44 +0200
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> > Date: Tue, 11 Mar 2025 14:34:09 +0000
> >> > From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
> >> > Cc: 76934 <at> debbugs.gnu.org
> >> >
> >> > Initially, there is the fringe area (shown in the attached file called
> >> > "first-screenshot"). I can interactively execute the fringe-mode command
> >> > it choose the 'minimal' option. It makes the fringe area to visually
> >> > disappear and emacs adjusts the space between the fringe of the window and
> >> > line numbers accordingly (shown in the second-screenshot). Then i use the
> >> > rectangle-mark-mode command and doing so returns the space that was
> >> > previously taken by the fringe area back (shown in the
> >> > third-screenshot). Yes, the added space doesn't use any highlighting, so
> >> > you can't verify it by looking at the highlighting for the fringe-area, my
> >> > description was confusing on that part.
> >>
> >> Looks like Emacs decided it needed one more columns for the line
> >> numbers, probably because the current line moved to line 9, and maybe
> >> also because the window's glyph matrix was enlarged for some reason.
> >> IOW, this has nothing to do with the fringes.
> >
> > No further comments, so I'm now closing this bug.
> 
> The observations I made in this thread (that the extra space is
> triggered by rectangle-mark-mode but remains after cancelling
> rectangle-mark-mode, and that splitting the window vertically removes
> the extra space) involve a buffer with only three lines, and regardless
> of the number of lines I think they indicate buggy or at least
> surprising behavior.  Does closing the bug mean you think the observed
> behavior is fine, and if so, why is it fine?

Yes, I think this behavior is fine, given the evidence presented.

It is fine because the code which decides how much space to allocate
for line numbers doesn't (and cannot) know how many lines are actually
in the buffer; the only thing it knows is the number of the current
line.

If you want to convince me that there is a problem here that should be
solved, please step with a debugger through the relevant code and
point out where you think the code does the wrong thing, and why.

Please also note that the original bug report was about a completely
different issue, as seen from the Subject.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76934 <at> debbugs.gnu.org, the_wurfkreuz <at> proton.me
Subject: Re: bug#76934: 31.0.50; rectangle-mark-mode resets fringe-mode
 settings
Date: Sat, 29 Mar 2025 13:55:22 +0100

On Sat, 29 Mar 2025 15:34:20 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: eliz <at> gnu.org,  the_wurfkreuz <at> proton.me
>> Date: Sat, 29 Mar 2025 12:41:47 +0100
>>
>> On Sat, 29 Mar 2025 14:13:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> >> Cc: 76934 <at> debbugs.gnu.org
>> >> Date: Tue, 11 Mar 2025 19:16:44 +0200
>> >> From: Eli Zaretskii <eliz <at> gnu.org>
>> >>
>> >> > Date: Tue, 11 Mar 2025 14:34:09 +0000
>> >> > From: the_wurfkreuz <the_wurfkreuz <at> proton.me>
>> >> > Cc: 76934 <at> debbugs.gnu.org
>> >> >
>> >> > Initially, there is the fringe area (shown in the attached file called
>> >> > "first-screenshot"). I can interactively execute the fringe-mode command
>> >> > it choose the 'minimal' option. It makes the fringe area to visually
>> >> > disappear and emacs adjusts the space between the fringe of the window and
>> >> > line numbers accordingly (shown in the second-screenshot). Then i use the
>> >> > rectangle-mark-mode command and doing so returns the space that was
>> >> > previously taken by the fringe area back (shown in the
>> >> > third-screenshot). Yes, the added space doesn't use any highlighting, so
>> >> > you can't verify it by looking at the highlighting for the fringe-area, my
>> >> > description was confusing on that part.
>> >>
>> >> Looks like Emacs decided it needed one more columns for the line
>> >> numbers, probably because the current line moved to line 9, and maybe
>> >> also because the window's glyph matrix was enlarged for some reason.
>> >> IOW, this has nothing to do with the fringes.
>> >
>> > No further comments, so I'm now closing this bug.
>>
>> The observations I made in this thread (that the extra space is
>> triggered by rectangle-mark-mode but remains after cancelling
>> rectangle-mark-mode, and that splitting the window vertically removes
>> the extra space) involve a buffer with only three lines, and regardless
>> of the number of lines I think they indicate buggy or at least
>> surprising behavior.  Does closing the bug mean you think the observed
>> behavior is fine, and if so, why is it fine?
>
> Yes, I think this behavior is fine, given the evidence presented.
>
> It is fine because the code which decides how much space to allocate
> for line numbers doesn't (and cannot) know how many lines are actually
> in the buffer; the only thing it knows is the number of the current
> line.

I don't see how that's relevant to the observed behavior, namely, that
the extra space is triggered by rectangle-mark-mode apparently
regardless of the number of lines or what the current line number is
(and remains after rectangle-mark-mode is cancelled), and that the extra
space is not displayed when the window is vertically split.

> If you want to convince me that there is a problem here that should be
> solved, please step with a debugger through the relevant code and
> point out where you think the code does the wrong thing, and why.

> Please also note that the original bug report was about a completely
> different issue, as seen from the Subject.

Well, rectangle-mark-mode is certainly part of the issue according to my
observations, while the reference to fringe-mode was evidently a
mischaracterization of the observed behavior.  Anyway, I'll try to do
some debugging at some point, and if I find anything worth reporting,
I'll open a new bug.

Steve Berman

Previous Next

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