bug#43949: Strange behaviour for linum-mode

bug#43949: Strange behaviour for linum-mode

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 4266 bytes --]

--text follows this line--

emacs -Q <long file>

select any theme with colours
M-x linum-mode
customize-variable linum-format to %05d
config to truncate long lines
Go to the end of a truncated line. The limun buffer disappears and is
replaced by blanks. IMHO, the linum buffer should no change


In GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
 of 2020-09-26 built on paag-EliteBook
Repository revision: cc7f9714858ab9f1fc30ffcfc5acc018da2b5d4d
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 20.04.1 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
rules has auto save data; consider M-x recover-this-file

Configured using:
 'configure --build=x86_64-linux-gnu --prefix=/usr
 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
 --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'
 '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
 --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
 --program-suffix=27 --with-modules=yes --with-x --with-x-toolkit=gtk3
 --without-xaw3d 'CFLAGS=-g -O2
 -fdebug-prefix-map=/home/paag/Devel/emacs27/emacs=.
-fstack-protector-strong
 -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_MONETARY: es_ES.UTF-8
  value of $LC_NUMERIC: es_ES.UTF-8
  value of $LC_TIME: es_ES.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search seq byte-opt gv
bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x mule-util
jka-compr info cl-seq vc-hg vc-git diff-mode easymenu easy-mmode
cl-loaddefs cl-lib make-mode tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 64406 8535)
 (symbols 48 7190 1)
 (strings 32 23109 2280)
 (string-bytes 1 673367)
 (vectors 16 11343)
 (vector-slots 8 148329 11666)
 (floats 8 25 50)
 (intervals 56 489 4)
 (buffers 1000 13))
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 4917 bytes --]

bug#43949: Strange behaviour for linum-mode

[Stefan Kangas]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> emacs -Q <long file>
>
> select any theme with colours
> M-x linum-mode
> customize-variable linum-format to %05d
> config to truncate long lines
> Go to the end of a truncated line. The limun buffer disappears and is
> replaced by blanks. IMHO, the linum buffer should no change

Does this work better if you use display-line-numbers-mode instead?

bug#43949: Strange behaviour for linum-mode

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1.1: Type: text/plain, Size: 857 bytes --]

Hi Stefan, thanks for the suggestion.
It sort of works. However, only sort of. I miss the  linum-format variable
and the linum face.
Maybe too many years in linum-mode

My linum settings look cool, don't they? ;-)
[image: image.png]

Best, /PA


On Mon, 12 Oct 2020 at 15:00, Stefan Kangas <stefan@marxist.se> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > emacs -Q <long file>
> >
> > select any theme with colours
> > M-x linum-mode
> > customize-variable linum-format to %05d
> > config to truncate long lines
> > Go to the end of a truncated line. The limun buffer disappears and is
> > replaced by blanks. IMHO, the linum buffer should no change
>
> Does this work better if you use display-line-numbers-mode instead?
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #1.2: Type: text/html, Size: 1593 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 5552 bytes --]

bug#43949: Strange behaviour for linum-mode

[Robert Pluim]

>>>>> On Mon, 12 Oct 2020 19:11:22 +0200, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:

    Pedro> Hi Stefan, thanks for the suggestion.
    Pedro> It sort of works. However, only sort of. I miss the  linum-format variable
    Pedro> and the linum face.
    Pedro> Maybe too many years in linum-mode

Thereʼs a line-number-face. What did you use linum-format for?

    Pedro> My linum settings look cool, don't they? ;-)
    Pedro> [image: image.png]

ENOIMAGE, but I believe you.

Robert
-- 

bug#43949: Strange behaviour for linum-mode

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

Cool!
Thanks for the tip!

linum-format is +/-  display-line-numbers-width
You can control things like having a space after the line number or not a
little bit better

Best, /PA

On Mon, 12 Oct 2020 at 19:24, Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Mon, 12 Oct 2020 19:11:22 +0200, Pedro Andres Aranda Gutierrez <
> paaguti@gmail.com> said:
>
>     Pedro> Hi Stefan, thanks for the suggestion.
>     Pedro> It sort of works. However, only sort of. I miss the
> linum-format variable
>     Pedro> and the linum face.
>     Pedro> Maybe too many years in linum-mode
>
> Thereʼs a line-number-face. What did you use linum-format for?
>
>     Pedro> My linum settings look cool, don't they? ;-)
>     Pedro> [image: image.png]
>
> ENOIMAGE, but I believe you.
>
> Robert
> --
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1565 bytes --]

bug#43949: Strange behaviour for linum-mode

[Robert Pluim]

>>>>> On Tue, 13 Oct 2020 07:33:26 +0200, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:

    Pedro> Cool!
    Pedro> Thanks for the tip!

    Pedro> linum-format is +/-  display-line-numbers-width
    Pedro> You can control things like having a space after the line number or not a
    Pedro> little bit better

I can see how people might want that, but I think the current setup
looks good, and since the line number calculation and display runs
during redisplay, I donʼt think we want too much flexibility, as that
could slow it down.

Having said that, eliminating that space seems to work, but it does
make the display look very squashed. Eli, what do you think of
a configuration variable allowing that space to be narrower?

Robert
-- 

bug#43949: Strange behaviour for linum-mode

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 13 Oct 2020 09:30:49 +0200
> Cc: Stefan Kangas <stefan@marxist.se>, 43949@debbugs.gnu.org
> 
> Having said that, eliminating that space seems to work, but it does
> make the display look very squashed. Eli, what do you think of
> a configuration variable allowing that space to be narrower?

I'm not sure I understand what you have in mind, please elaborate.

bug#43949: Strange behaviour for linum-mode

[Robert Pluim]

>>>>> On Tue, 13 Oct 2020 18:46:28 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Tue, 13 Oct 2020 09:30:49 +0200
    >> Cc: Stefan Kangas <stefan@marxist.se>, 43949@debbugs.gnu.org
    >> 
    >> Having said that, eliminating that space seems to work, but it does
    >> make the display look very squashed. Eli, what do you think of
    >> a configuration variable allowing that space to be narrower?

    Eli> I'm not sure I understand what you have in mind, please elaborate.

Instead of this in xdisp.c:23046

  strcat (lnum_buf, " ");

use the equivalent of

(setq line-number-space-width 0.5)
(insert (propertize " " 'display '(space . line-number-space-width)))

and adjusting the x-coordinate of the glyphs after the space
appropriately.

Robert
-- 

bug#43949: Strange behaviour for linum-mode

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: paaguti@gmail.com,  stefan@marxist.se,  43949@debbugs.gnu.org
> Date: Tue, 13 Oct 2020 18:06:06 +0200
> 
> Instead of this in xdisp.c:23046
> 
>   strcat (lnum_buf, " ");
> 
> use the equivalent of
> 
> (setq line-number-space-width 0.5)
> (insert (propertize " " 'display '(space . line-number-space-width)))
> 
> and adjusting the x-coordinate of the glyphs after the space
> appropriately.

Did you read the comment before this code?

bug#43949: Strange behaviour for linum-mode

[Robert Pluim]

>>>>> On Tue, 13 Oct 2020 19:19:54 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> and adjusting the x-coordinate of the glyphs after the space
    >> appropriately.

    Eli> Did you read the comment before this code?

Ah no. I guess that makes it more complicated (and I need to check my
L2R privilege more often).

Robert
-- 

bug#43949: Strange behaviour for linum-mode

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: paaguti@gmail.com,  stefan@marxist.se,  43949@debbugs.gnu.org
> Date: Tue, 13 Oct 2020 18:39:23 +0200
> 
> >>>>> On Tue, 13 Oct 2020 19:19:54 +0300, Eli Zaretskii <eliz@gnu.org> said:
>     >> and adjusting the x-coordinate of the glyphs after the space
>     >> appropriately.
> 
>     Eli> Did you read the comment before this code?
> 
> Ah no. I guess that makes it more complicated (and I need to check my
> L2R privilege more often).

Let me put it this way: if someone can find a clever algorithm to
know, when we produce the line numbers, whether the "glyph row" will
be "reversed" or not, we will be able to implement any number of
niceties like the one discussed here, which produce asymmetric space
before and after the line number.  As things are, I simply couldn't
find a solution for that (which doesn't mean it doesn't exist, just
that I'm not smart enough to come up with one).

Ideas and patches are welcome.