GNU bug report logs -
#52447
29.0.50; New mode-line breaks calculations for last element in my mode-line
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 52447 in the body.
You can then email your comments to 52447 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52447
; Package
emacs
.
(Sun, 12 Dec 2021 07:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 12 Dec 2021 07:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
--text follows this line--
I'm using the attached code for my mode-line. It's inspired by the doom
mode-line. My last element is right-aligned and shows GIT information when
relevant. On emacs < 29, the calculation for the free space avoids
overlapping with the fringe:[image: emacs28-modeline.png]
On emacs29, with fixed font using the fix from etc/NEWS, the fringe
overlaps with the vc information.
[image: emacs29-broken-modeline.png]
Not to speak variable pitch, where I only see the first 1.5 letters or so
(depending on the branch I'm in)
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0)
of 2021-12-11 built on emacs29
Repository revision: d90be279958c093c4d3023ef553ea20508cf4c28
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Ubuntu 20.04.3 LTS
Configured using:
'configure --prefix=/usr --program-suffix=29 --with-json --with-x
--with-x-toolkit=gtk3 --with-cairo --with-compress-install
--with-modules=yes --with-threads --with-included-regex --with-zlib
--with-native-compilation 'CFLAGS=-g -O2
-fdebug-prefix-map=/home/paag/emacs=. -fstack-protector-strong -Wformat
-Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3
ZLIB
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_GB.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search seq gv byte-opt 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 cus-edit pp cus-start cus-load wid-edit time-date subr-x
cl-loaddefs cl-lib pcase iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 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 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 emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button 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
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)
Memory information:
((conses 16 90617 9584)
(symbols 48 8335 0)
(strings 32 23959 1771)
(string-bytes 1 758881)
(vectors 16 15565)
(vector-slots 8 321755 14485)
(floats 8 30 51)
(intervals 56 239 0)
(buffers 992 10))
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
[Message part 2 (text/html, inline)]
[emacs28-modeline.png (image/png, inline)]
[emacs29-broken-modeline.png (image/png, inline)]
[mode-line.el.gz (application/gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52447
; Package
emacs
.
(Sun, 12 Dec 2021 09:04:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52447 <at> debbugs.gnu.org (full text, mbox):
> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> Date: Sun, 12 Dec 2021 08:17:28 +0100
>
> I'm using the attached code for my mode-line. It's inspired by the doom mode-line. My last element is
> right-aligned and shows GIT information when relevant. On emacs < 29, the calculation for the free space
> avoids overlapping with the fringe:
> emacs28-modeline.png
>
> On emacs29, with fixed font using the fix from etc/NEWS, the fringe overlaps with the vc information.
> emacs29-broken-modeline.png
Your code says:
(defun fill-spaces (len)
`((space :align-to (- (+ right right-fringe right-margin) ,len))))
This tells Emacs to right-align the string to the place _after_ the
margin and the fringe. If I remove the addition of right-fringe and
right-margin from the :align-to expression, the effect is like you
want.
So it sounds like Emacs 28 and before had some bug in this area which
was fixed in Emacs 29, and your code needs to adapt by removing the
"fix" you had in previous Emacs versions.
> Not to speak variable pitch, where I only see the first 1.5 letters or so (depending on the branch I'm in)
For variable-pitch font, you need to calculate this in pixels, not in
columns.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52447
; Package
emacs
.
(Sun, 12 Dec 2021 18:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 52447 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Eli,
Doesn't this mean that there will be a 'bug' in emacs28 ;-) Just kidding...
thanks a lot for the analysis.
It was code I found time ago and I had really forgotten how it worked (or
didn't work).
Now that I(you) have fixed it for fixed-pitch I don't think I'm prepared
for a variable pitch font in the mode line yet. I still find it ugly.
Best, /PA
On Sun, 12 Dec 2021 at 10:03, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> > Date: Sun, 12 Dec 2021 08:17:28 +0100
> >
> > I'm using the attached code for my mode-line. It's inspired by the doom
> mode-line. My last element is
> > right-aligned and shows GIT information when relevant. On emacs < 29,
> the calculation for the free space
> > avoids overlapping with the fringe:
> > emacs28-modeline.png
> >
> > On emacs29, with fixed font using the fix from etc/NEWS, the fringe
> overlaps with the vc information.
> > emacs29-broken-modeline.png
>
> Your code says:
>
> (defun fill-spaces (len)
> `((space :align-to (- (+ right right-fringe right-margin) ,len))))
>
> This tells Emacs to right-align the string to the place _after_ the
> margin and the fringe. If I remove the addition of right-fringe and
> right-margin from the :align-to expression, the effect is like you
> want.
>
> So it sounds like Emacs 28 and before had some bug in this area which
> was fixed in Emacs 29, and your code needs to adapt by removing the
> "fix" you had in previous Emacs versions.
>
> > Not to speak variable pitch, where I only see the first 1.5 letters or
> so (depending on the branch I'm in)
>
> For variable-pitch font, you need to calculate this in pixels, not in
> columns.
>
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52447
; Package
emacs
.
(Sun, 12 Dec 2021 18:25:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52447 <at> debbugs.gnu.org (full text, mbox):
> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> Date: Sun, 12 Dec 2021 18:58:48 +0100
> Cc: 52447 <at> debbugs.gnu.org
>
> Doesn't this mean that there will be a 'bug' in emacs28 ;-)
Probably, but it's too late to fix this in Emacs 28.
> Just kidding... thanks a lot for the analysis.
> It was code I found time ago and I had really forgotten how it worked (or didn't work).
> Now that I(you) have fixed it for fixed-pitch I don't think I'm prepared for a variable pitch font in the mode line
> yet. I still find it ugly.
So can this bug be closed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52447
; Package
emacs
.
(Mon, 13 Dec 2021 06:07:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 52447 <at> debbugs.gnu.org (full text, mbox):
Yes, sure
Enviado desde mi iPad
El 12 dic 2021, a las 19:24, Eli Zaretskii <eliz <at> gnu.org> escribió:
>> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
>> Date: Sun, 12 Dec 2021 18:58:48 +0100
>> Cc: 52447 <at> debbugs.gnu.org
>>
>> Doesn't this mean that there will be a 'bug' in emacs28 ;-)
>
> Probably, but it's too late to fix this in Emacs 28.
>
>> Just kidding... thanks a lot for the analysis.
>> It was code I found time ago and I had really forgotten how it worked (or didn't work).
>> Now that I(you) have fixed it for fixed-pitch I don't think I'm prepared for a variable pitch font in the mode line
>> yet. I still find it ugly.
>
> So can this bug be closed?
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Mon, 13 Dec 2021 12:55:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 13 Dec 2021 12:55:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 52447-done <at> debbugs.gnu.org (full text, mbox):
> From: Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com>
> Date: Mon, 13 Dec 2021 07:06:27 +0100
> Cc: 52447 <at> debbugs.gnu.org
>
> Yes, sure
Thanks, done.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 11 Jan 2022 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 157 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.