GNU bug report logs - #37880
27.0.50; Changing font size in Info-mode messes up formatting

Previous Next

To reply to this bug, email your comments to 37880 AT debbugs.gnu.org.

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

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

From: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Changing font size in Info-mode messes up formatting
Date: Wed, 23 Oct 2019 03:43:55 +0200

When I browse Info in "emacs -Q", the default formatting is fine when
I say C-h i and I see entries nicely lined up like so:

* IDLWAVE           Major mode and shell for IDL files.
* Newsticker        A feed reader for Emacs.

However, when I increase the font size using C-x C-+, I end up with
text that looks visually more like this:

* IDLWAVEMajor mode and shell for IDL files.
* NewstickerA feed reader for Emacs.

I see the same in menu entries in individual nodes.

I didn't look into it, but it would be nice if the formatting of menu
items could adjust as the font size increases.

Best regards,
Stefan Kangas

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 37880 <at> debbugs.gnu.org
Subject: Re: bug#37880: 27.0.50;
 Changing font size in Info-mode messes up formatting
Date: Wed, 23 Oct 2019 19:27:10 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 23 Oct 2019 03:43:55 +0200
> 
> When I browse Info in "emacs -Q", the default formatting is fine when
> I say C-h i and I see entries nicely lined up like so:
> 
> * IDLWAVE           Major mode and shell for IDL files.
> * Newsticker        A feed reader for Emacs.
> 
> However, when I increase the font size using C-x C-+, I end up with
> text that looks visually more like this:
> 
> * IDLWAVEMajor mode and shell for IDL files.
> * NewstickerA feed reader for Emacs.

That's :align-to display property in action.  See bug#37858 for one
attempt to enhance it.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
Subject: Re: bug#37880: 27.0.50; Changing font size in Info-mode messes up
 formatting
Date: Sat, 07 May 2022 14:07:24 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> So, I'd like to extend our `space` specifications so as to be able to
> specify a minimum width.  I came up with the patch below which lets you
> write:
>
>     (space :align-to FOO :min-width BAR)
>
> which seems to work fine, but while trying to update the Elisp doc for
> it I realized that maybe a better option is to extend the acceptable
> forms for FOO so it can be of the form:
>
>     (space :align-to (max FOO (+ BAR current-x)))

I think I'd actually prefer the first form -- it's easy to reason about,
and does what most usage cases want (i.e., align if possible, but if
not, then at least leave some space so that things don't run into each
other).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
Subject: Re: bug#37880: 27.0.50; Changing font size in Info-mode messes up
 formatting
Date: Sat, 07 May 2022 10:29:54 -0400

Lars Ingebrigtsen [2022-05-07 14:07:24] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> So, I'd like to extend our `space` specifications so as to be able to
>> specify a minimum width.  I came up with the patch below which lets you
>> write:
>>
>>     (space :align-to FOO :min-width BAR)
>>
>> which seems to work fine, but while trying to update the Elisp doc for
>> it I realized that maybe a better option is to extend the acceptable
>> forms for FOO so it can be of the form:
>>
>>     (space :align-to (max FOO (+ BAR current-x)))
>
> I think I'd actually prefer the first form -- it's easy to reason about,
> and does what most usage cases want (i.e., align if possible, but if
> not, then at least leave some space so that things don't run into each
> other).

The patch I came up with back then doesn't work right.  IIRC it's
because we need to change both the redisplay code and the
`current-column` code and it only changed one of the two.

IIRC, I decided then that the right fix is to rewrite the
`current-column` code to use the redisplay code (instead of trying to
mimic it), but I didn't get around to that (and IIRC it's not
completely straightforward because `current-column` currently behaves
differently *on purpose* in some cases (most importantly w.r.t treating
ellipsis-erased text) so fixing it right will imply changes in behavior
and figuring out how to do it without breaking existing uses).


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: larsi <at> gnus.org, 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
Subject: Re: bug#37858: bug#37880: 27.0.50;
 Changing font size in Info-mode messes up formatting
Date: Sat, 07 May 2022 17:38:10 +0300

> Cc: 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
> Date: Sat, 07 May 2022 10:29:54 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> The patch I came up with back then doesn't work right.  IIRC it's
> because we need to change both the redisplay code and the
> `current-column` code and it only changed one of the two.
> 
> IIRC, I decided then that the right fix is to rewrite the
> `current-column` code to use the redisplay code (instead of trying to
> mimic it), but I didn't get around to that (and IIRC it's not
> completely straightforward because `current-column` currently behaves
> differently *on purpose* in some cases (most importantly w.r.t treating
> ellipsis-erased text) so fixing it right will imply changes in behavior
> and figuring out how to do it without breaking existing uses).

When did you last look at what current-column does in the context of
the issue being discussed here?

I'm not sure it does what you had in mind, but some changes were done
there recently, and the behavior in similar contexts did change.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
Subject: Re: bug#37858: bug#37880: 27.0.50; Changing font size in Info-mode
 messes up formatting
Date: Sat, 07 May 2022 11:58:41 -0400

Eli Zaretskii [2022-05-07 17:38:10] wrote:
> When did you last look at what current-column does in the context of
> the issue being discussed here?

It was soon after I posted this bug report.

> I'm not sure it does what you had in mind, but some changes were done
> there recently, and the behavior in similar contexts did change.

I haven't looked at recent changes in this area, so maybe things would
be a bit easier now, tho looking at `scan_for_column` in `master`,
I still see that we re-implement in `check_display_width` (part of) the
code used in `xdisp.c` to handle the display property, so AFAICT the
duplication is still present.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: larsi <at> gnus.org, 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
Subject: Re: bug#37858: bug#37880: 27.0.50; Changing font size in Info-mode
 messes up formatting
Date: Sat, 07 May 2022 19:06:55 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org,  37880 <at> debbugs.gnu.org,  37858 <at> debbugs.gnu.org
> Date: Sat, 07 May 2022 11:58:41 -0400
> 
> I haven't looked at recent changes in this area, so maybe things would
> be a bit easier now, tho looking at `scan_for_column` in `master`,
> I still see that we re-implement in `check_display_width` (part of) the
> code used in `xdisp.c` to handle the display property, so AFAICT the
> duplication is still present.

There's no duplication.  We simply use the same infrastructure as the
display code does.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: monnier <at> iro.umontreal.ca
Cc: larsi <at> gnus.org, 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
Subject: Re: bug#37858: bug#37880: 27.0.50;
 Changing font size in Info-mode messes up formatting
Date: Sat, 07 May 2022 19:20:33 +0300

> Cc: larsi <at> gnus.org, 37880 <at> debbugs.gnu.org, 37858 <at> debbugs.gnu.org
> Date: Sat, 07 May 2022 19:06:55 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: larsi <at> gnus.org,  37880 <at> debbugs.gnu.org,  37858 <at> debbugs.gnu.org
> > Date: Sat, 07 May 2022 11:58:41 -0400
> > 
> > I haven't looked at recent changes in this area, so maybe things would
> > be a bit easier now, tho looking at `scan_for_column` in `master`,
> > I still see that we re-implement in `check_display_width` (part of) the
> > code used in `xdisp.c` to handle the display property, so AFAICT the
> > duplication is still present.
> 
> There's no duplication.  We simply use the same infrastructure as the
> display code does.

And, btw, I don't think I agree with your assertion that we should use
the display routines for current-column and friends.  The
column-oriented functions count actual (not canonical) columns,
whereas display code counts pixels.  It makes little sense to me to
call the display code, which will load fonts, call jit-lock, and
whatnot, just to count columns like current-column expects.

Previous Next

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