From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Gallagher - NOAA Affiliate via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#50506: 28.0.50; display-line-numbers equivalent for linum-format? Date: Wed, 15 Sep 2021 11:32:17 -0600 Message-ID: References: <87czpgc1yb.fsf@noaa.gov> <83fsucipdz.fsf@gnu.org> <87tuirnwu0.fsf@gnus.org> <83sfy8cpvz.fsf@gnu.org> <83pmtccovd.fsf@gnu.org> <834kancb73.fsf@gnu.org> <83ilz1bzyx.fsf@gnu.org> <83ee9pby9t.fsf@gnu.org> <83a6kdbx11.fsf@gnu.org> Reply-To: Michael Gallagher - NOAA Affiliate Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000085194805cc0c16e9" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27052"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50506@debbugs.gnu.org, Lars Ingebrigtsen To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 15 19:34:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQYnU-0006nM-2D for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 19:34:12 +0200 Original-Received: from localhost ([::1]:57438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQYnR-0003bW-5o for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 13:34:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQYnK-0003b1-2a for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 13:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQYnJ-00071x-R4 for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 13:34:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQYnJ-0004vl-O8 for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 13:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Gallagher - NOAA Affiliate Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Sep 2021 17:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50506 X-GNU-PR-Package: emacs Original-Received: via spool by 50506-submit@debbugs.gnu.org id=B50506.163172718218870 (code B ref 50506); Wed, 15 Sep 2021 17:34:01 +0000 Original-Received: (at 50506) by debbugs.gnu.org; 15 Sep 2021 17:33:02 +0000 Original-Received: from localhost ([127.0.0.1]:53173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQYmL-0004uH-Ro for submit@debbugs.gnu.org; Wed, 15 Sep 2021 13:33:02 -0400 Original-Received: from mail-pg1-f173.google.com ([209.85.215.173]:36381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQYmJ-0004tk-29 for 50506@debbugs.gnu.org; Wed, 15 Sep 2021 13:33:01 -0400 Original-Received: by mail-pg1-f173.google.com with SMTP id t1so3447539pgv.3 for <50506@debbugs.gnu.org>; Wed, 15 Sep 2021 10:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noaa.gov; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QeXp8qeW2MvHilFwmlwD49tpKDgV+kDRM+x2riwMp2s=; b=lYXUg9J7bt+uDffNOpCenP9lgKbWwMdllDVBX93uOIQPxL5nCtyLBUEBHQqdoBgURF pgNun/hSxX1CtUDsnM3d9/jLNdQNjmn2sbqVvgXm5afLGCtiQFrra1wWnVMfZtvYSh1d A1Iq3BuwlerZvH4k2PJlPps4fjpZxyZx9FiGVCy16Ypwgv7h+jmIMp2hfz7mX2T3go3X WtAGykbknxwdgXg6lrwJuP1dl5K/fHzRYV+pdUGDzaKu8dh4lmLvgdu3llyphYRcOBLX MSUwikhoohOpjIayMXUPsp/+m3hkzzx6RyGJnZB9qzqw3k3U37aEFMMyCBjhxZ5SZYo4 EWfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QeXp8qeW2MvHilFwmlwD49tpKDgV+kDRM+x2riwMp2s=; b=E30INGKvVCrLogS3zM+Pcj5WFGoKjlU2kN2+CuKhSUWYetmTrbnakqOtGf3BsqJeXn Rs2IlaTUOW/WVEeKHEvT6qAkV6OPa6Nj4jWRcL3NETSZ1uVfCUPzNLzLz17eX6G7d5vJ mjRik5AbCXA4f64JB/AyAdEm6zo1eEp8YuJ/VAkE58jag9D0DTaEKBq60xUkgyQdHNQI 8PXETVYbnkf+/IRBzFMRfcSyezRq4ThLvqBVVaNpcUQIGsCCFznpJUJWoiuYzqBvuNcM gfNmJylCr5k7QhKO+lw8liJ0LraBSW4/6fmw6i4M+RLczCGX0C8AwkNfEFTVEDvZTHMQ YKLg== X-Gm-Message-State: AOAM530uKVxXyC18k/R/0tFATnVzFQ/ElKFWbv97x9Jr7AEYX75YZuvX Bo3G0/w8n7Uerruw0JNv5QafBf4D1MA0PjImVXCqSA== X-Google-Smtp-Source: ABdhPJwWUhEvTk856SqPl/hJZDiHJ4xVfxmGbA4QgF4XAH195tiMWwtBoCziy69BVPKSxfRT7RpPRo8jicqxkKp1wYE= X-Received: by 2002:a05:6a00:c8a:b0:3fb:dbcc:e1d7 with SMTP id a10-20020a056a000c8a00b003fbdbcce1d7mr643296pfv.51.1631727173015; Wed, 15 Sep 2021 10:32:53 -0700 (PDT) In-Reply-To: <83a6kdbx11.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214419 Archived-At: --00000000000085194805cc0c16e9 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > From: Michael Gallagher - NOAA Affiliate > > Date: Wed, 15 Sep 2021 10:45:01 -0600 > > Cc: Lars Ingebrigtsen , 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 --00000000000085194805cc0c16e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok. Correct me if I'm wrong, but this is extremely ugl= y 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&= quot; via PRODUCE_GLYPHS you have very little (no?) information about what = is responsible for those glyphs? Actually. I don't fully understand whe= re in the code the line numbers get moved to the right side. Because it sho= uld be, conceptually, easy to swap the last glyph to the first glyph if the= re 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 g= lyphs are moved to the right side, I can't find it.=C2=A0
On Wed, S= ep 15, 2021 at 10:53 AM Eli Zaretskii <e= liz@gnu.org> wrote:
> From: Michael Gallagher - NOAA Affiliate <michael.r.gallagher@noa= a.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 add= ing 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 b= oth 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_direc= tion 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 wa= y beyond my skillset and you'd have to
> spend a lot of time checking/fixing any my work if I did make the atte= mpt.

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
<= /div>
Polar Obser= vations and Processes Team (ESRL/NOAA/PSD)
325 Broadway, Boulder, Colorado 80305
--00000000000085194805cc0c16e9--