unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Gallagher - NOAA Affiliate via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 50506@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
Subject: bug#50506: 28.0.50; display-line-numbers equivalent for linum-format?
Date: Wed, 15 Sep 2021 11:32:17 -0600	[thread overview]
Message-ID: <CA+e+kb1qnajUNfsyXWzY86a2zL=+crFWaw+akpJ_B3kzkpPg-A@mail.gmail.com> (raw)
In-Reply-To: <83a6kdbx11.fsf@gnu.org>

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

Ok. Correct me if I'm wrong, but this is extremely ugly in that it requires
a deep knowledge of how the glyphs are drawn and how move_it_by_lines
operates on the glyphs. Because, as it appears to me, once the line number
glyphs are sent to what I will call the "glyph queue" via PRODUCE_GLYPHS
you have very little (no?) information about what is responsible for those
glyphs? Actually. I don't fully understand where in the code the line
numbers get moved to the right side. Because it should be, conceptually,
easy to swap the last glyph to the first glyph if there is a separator
character at that point in the code. But when I "M-s o" for occurences of
R2L and then look for the place where the lnum glyphs are moved to the
right side, I can't find it.

On Wed, Sep 15, 2021 at 10:53 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Michael Gallagher - NOAA Affiliate <michael.r.gallagher@noaa.gov>
> > Date: Wed, 15 Sep 2021 10:45:01 -0600
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50506@debbugs.gnu.org
> >
> > So, in concept then, as the display-line-numbers code operates now
> adding a separator character that
> > respects direction isn't possible because when maybe_produce_line_number
> is called the code doesn't yet
> > know the direction of the text. The correct fix is to somehow have the
> function call for generating the line
> > number glyphs after the buffer glyphs are computed... or to generate
> both L2R and R2L line numbers and
> > then let the code decide what to display once reversed_p is decided.
>
> Yes.
>
> > This is verified by the fact that if I make a check on
> paragraph_direction instead of embedding, the first line
> > number displays incorrectly because this flag has yet to be set.
>
> Exactly.
>
> > Either way, I hate to admit it, but any solution to that problem is way
> beyond my skillset and you'd have to
> > spend a lot of time checking/fixing any my work if I did make the
> attempt.
>
> The idea I had, which is somewhat ugly, is to rearrange the glyphs in
> the line-number part if the value of the reversed_p flag changes
> between the time the line number was produced and the time the first
> following glyph is produced in display_line.
>


-- 
Michael Gallagher, PhD
CIRES Research Scientist
Polar Observations and Processes Team (ESRL/NOAA/PSD)
325 Broadway, Boulder, Colorado 80305

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

  reply	other threads:[~2021-09-15 17:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  7:40 bug#50506: 28.0.50; display-line-numbers equivalent for linum-format? Michael Gallagher (CIRES/NOAA) via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-10 12:30 ` Eli Zaretskii
2021-09-10 16:00   ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-11 11:53     ` Eli Zaretskii
2021-09-11 12:03     ` Lars Ingebrigtsen
2021-09-13 17:54       ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-13 18:05         ` Eli Zaretskii
2021-09-13 18:17           ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-13 18:27             ` Eli Zaretskii
2021-09-14 16:17               ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-14 17:24                 ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-14 17:35                 ` Eli Zaretskii
2021-09-15 15:22                   ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 15:49                     ` Eli Zaretskii
2021-09-15 16:08                       ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 16:26                         ` Eli Zaretskii
2021-09-15 16:45                           ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 16:53                             ` Eli Zaretskii
2021-09-15 17:32                               ` Michael Gallagher - NOAA Affiliate via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-09-15 18:10                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+e+kb1qnajUNfsyXWzY86a2zL=+crFWaw+akpJ_B3kzkpPg-A@mail.gmail.com' \
    --to=bug-gnu-emacs@gnu.org \
    --cc=50506@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    --cc=michael.r.gallagher@noaa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).