GNU logs - #36472, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jul 2019 11:15:01 +0000
Resent-Message-ID: <handler.36472.B.156206607331044 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 36472 <at> debbugs.gnu.org
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
Date: Tue, 2 Jul 2019 14:14:15 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

There is a feature request for diff-hl: to indicate the VCS status of
different lines by using the colors of the line numbers, instead of
fringe or margin indicators.

(https://github.com/dgutov/diff-hl/issues/124)

I think this is not possible yet, but if there was a hook to choose how
a number is displayed, I'd be able to use it.

In GNU Emacs 27.0.50 (build 70, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.10)
  of 2019-06-19 built on zappa
Repository revision: 922121e7ddbc107da14ea9c1280d15c828e85063
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Ubuntu 18.04.2 L

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: bug#36472: Acknowledgement (27.0.50; Convey information by
 showing line numbers using different colors?)
Message-ID: <handler.36472.B.156206607331044.ack <at> debbugs.gnu.org>
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
X-Gnu-PR-Message: ack 36472
X-Gnu-PR-Package: emacs
Reply-To: 36472 <at> debbugs.gnu.org
Date: Tue, 02 Jul 2019 11:15:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 36472 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
36472: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36472
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jul 2019 14:32:02 +0000
Resent-Message-ID: <handler.36472.B36472.156207788026167 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Date: Tue, 02 Jul 2019 17:30:52 +0300
Message-Id: <83blycecf7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN> (message from
 Dmitry Gutov on Tue, 2 Jul 2019 14:14:15 +0300)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Tue, 2 Jul 2019 14:14:15 +0300
> 
> There is a feature request for diff-hl: to indicate the VCS status of
> different lines by using the colors of the line numbers, instead of
> fringe or margin indicators.
> 
> (https://github.com/dgutov/diff-hl/issues/124)
> 
> I think this is not possible yet, but if there was a hook to choose how
> a number is displayed, I'd be able to use it.

I wouldn't hold my breath, because this will mean any display routine
that calculates layout will have to call some non-trivial Lisp,
possibly even running a subprocess.  Not a very good design, IMO.

Why don't you show these indicators on the fringes or in the display
margins?  That's what those features are there for, and native line
numbers keep their claws off the margins for that very reason.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jul 2019 15:10:02 +0000
Resent-Message-ID: <handler.36472.B36472.156208015229567 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
Date: Tue, 2 Jul 2019 18:09:01 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <83blycecf7.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On 02.07.2019 17:30, Eli Zaretskii wrote:

 > I wouldn't hold my breath, because this will mean any display routine
that calculates layout will have to call some non-trivial Lisp,
possibly even running a subprocess.

Not really. In my use case it would only look up overlays on the lines 
corresponding to the numbers.

> Why don't you show these indicators on the fringes or in the display
> margins?

Already do. That's what diff-hl does by default.

I'm relaying a feature request here.

But speaking of fringes and margins, we still don't have a good solution 
for multiple packages to shows indicators on the same line.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jul 2019 15:39:01 +0000
Resent-Message-ID: <handler.36472.B36472.156208192332470 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.156208192332470
          (code B ref 36472); Tue, 02 Jul 2019 15:39:01 +0000
Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 15:38:43 +0000
Received: from localhost ([127.0.0.1]:47698 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hiKrh-0008Rc-M9
	for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 11:38:43 -0400
Received: from eggs.gnu.org ([209.51.188.92]:54380)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hiKrg-0008RQ-1K
 for 36472 <at> debbugs.gnu.org; Tue, 02 Jul 2019 11:38:40 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51310)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hiKra-00084e-KM; Tue, 02 Jul 2019 11:38:34 -0400
Received: from [176.228.60.248] (port=4808 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hiKrZ-0001NV-Gv; Tue, 02 Jul 2019 11:38:33 -0400
Date: Tue, 02 Jul 2019 18:38:18 +0300
Message-Id: <835zoke9at.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN> (message from
 Dmitry Gutov on Tue, 2 Jul 2019 18:09:01 +0300)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 36472 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Tue, 2 Jul 2019 18:09:01 +0300
> 
> On 02.07.2019 17:30, Eli Zaretskii wrote:
> 
>  > I wouldn't hold my breath, because this will mean any display routine
> that calculates layout will have to call some non-trivial Lisp,
> possibly even running a subprocess.
> 
> Not really. In my use case it would only look up overlays on the lines 
> corresponding to the numbers.

I don't understand: who would need to look up overlays?  And how will
"it" know that it needs to look up overlays?

IOW, I don't think I understand the API you had in mind.  You
originally said "a hook", which implies the display engine would call
a hook variable, but now it sounds like you had something else in
mind.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jul 2019 15:50:02 +0000
Resent-Message-ID: <handler.36472.B36472.1562082591989 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.1562082591989
          (code B ref 36472); Tue, 02 Jul 2019 15:50:02 +0000
Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 15:49:51 +0000
Received: from localhost ([127.0.0.1]:47703 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hiL2V-0000Fs-9z
	for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 11:49:51 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:44437)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1hiL2T-0000Fe-9q
 for 36472 <at> debbugs.gnu.org; Tue, 02 Jul 2019 11:49:49 -0400
Received: by mail-wr1-f53.google.com with SMTP id e3so8876645wrs.11
 for <36472 <at> debbugs.gnu.org>; Tue, 02 Jul 2019 08:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=m+TsQ7LuMfG4WtIpFI48v/2A0wZWPAneLIMC//pPRKY=;
 b=pVI+Skks6p5TKVnY5elfeToeatiz4nKZ4xGR3EeR5Ahr0+uPvI2mVPHTa7EPeLXbsQ
 6r23dWgjjSadz0R8jISJ75e32dE1oGYPXq91ocfa8YSsfoKxlEBfk+ye4FnUvnIaU61s
 bFQui1ryVEaYFA9XPa8/Td/0/fqcjtVhJacDK3ploDWdtkHKcg4h//iN+q4S/y1RYtZ2
 nzYkilthbr4GCLM1WfxoqwDF+P2DdDfdLSiTXwTPqN4fQ0pSmXr5xoPLOQKEVxDLw2ke
 E7oLUsAiS59y5bJgB5EfzVtYNGWhvvX1aznaQCHvIH89Dw7n1cSf2mLmOpHm7fEbdptU
 ErhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=m+TsQ7LuMfG4WtIpFI48v/2A0wZWPAneLIMC//pPRKY=;
 b=dBz8tXnEgA5KKtYW3aCUTP9JG2TWgzMWFuwny2SIeNK3dPDm1Wi2KlKBASGtIXujS7
 qZEnXZO6vyk8SIOXcpseCaUc5w/0s5RJASfNdjQat1AQY9R1SW4XLEalGI2Wlgik77fM
 +/+twfEk83+i1PM2+OXaElWKA2wwGByWVtyy7xSRqyiK+rUE8F1lVN966dXL2wr9TlGb
 r6KWqkhR9cbxaOABjygLu2EYDw580YDU4HpRrydSvXvRaRDuStHhzdBIVyMzts8poyFN
 AkJy/nLQgX92vjpnKpA2HTFJIr6d1WWKLgJKL5yFziqcVWJd2k+pMaDtyvJRSE6A3gkn
 5DDw==
X-Gm-Message-State: APjAAAVtFk+eyMVkS3F09wGvMoAxPiE0KlkjWIWbuIQMfyZWbfd8rVYj
 SD0p2IcX+OvylvNi/Ov6d2anUANn86c=
X-Google-Smtp-Source: APXvYqw6vdXqGMFrLmsFZKIsncH5vNKmG+PnpjKSzdSzFt9cT/758B3Uafg5Tbt04fqcHq3+5mLbLg==
X-Received: by 2002:a05:6000:112:: with SMTP id
 o18mr25781877wrx.153.1562082583076; 
 Tue, 02 Jul 2019 08:49:43 -0700 (PDT)
Received: from [192.168.0.195] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id t14sm12986128wrr.33.2019.07.02.08.49.41
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 02 Jul 2019 08:49:42 -0700 (PDT)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
Date: Tue, 2 Jul 2019 18:49:38 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <835zoke9at.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

On 02.07.2019 18:38, Eli Zaretskii wrote:

> I don't understand: who would need to look up overlays?  And how will
> "it" know that it needs to look up overlays?

The function that diff-hl would add to the said hook. So it will know.

> IOW, I don't think I understand the API you had in mind.  You
> originally said "a hook", which implies the display engine would call
> a hook variable, but now it sounds like you had something else in
> mind.

Something like:

(defvar display-line-number-renderers-functions nil
  "The line number (a string) is mapped through all of the functions in 
this list, in turn. Each receives it as an argument, and then the return 
value is used. The functions are called in the buffer for which the line 
numbers are displayed, at the beginning of a line which corresponds to 
the given number.")

(add-hook 'display-line-number-renderers 'diff-hl-line-number-renderer)

(defun diff-hl-line-number-renderer (line-number-string)
   (cl-case (get-text-property (point) 'diff-hl-indicator-type)
     ...)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jul 2019 16:29:01 +0000
Resent-Message-ID: <handler.36472.B36472.156208488712985 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.156208488712985
          (code B ref 36472); Tue, 02 Jul 2019 16:29:01 +0000
Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 16:28:07 +0000
Received: from localhost ([127.0.0.1]:47770 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hiLdX-0003NN-6s
	for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 12:28:07 -0400
Received: from eggs.gnu.org ([209.51.188.92]:36092)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hiLdV-0003Mt-FP
 for 36472 <at> debbugs.gnu.org; Tue, 02 Jul 2019 12:28:06 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52052)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hiLdN-0006sQ-IH; Tue, 02 Jul 2019 12:27:58 -0400
Received: from [176.228.60.248] (port=3884 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hiLdM-0000Oy-54; Tue, 02 Jul 2019 12:27:57 -0400
Date: Tue, 02 Jul 2019 19:27:41 +0300
Message-Id: <834l44e70i.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN> (message from
 Dmitry Gutov on Tue, 2 Jul 2019 18:49:38 +0300)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN> <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 36472 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Tue, 2 Jul 2019 18:49:38 +0300
> 
> (defvar display-line-number-renderers-functions nil
>   "The line number (a string) is mapped through all of the functions in 
> this list, in turn. Each receives it as an argument, and then the return 
> value is used. The functions are called in the buffer for which the line 
> numbers are displayed, at the beginning of a line which corresponds to 
> the given number.")
> 
> (add-hook 'display-line-number-renderers 'diff-hl-line-number-renderer)
> 
> (defun diff-hl-line-number-renderer (line-number-string)
>    (cl-case (get-text-property (point) 'diff-hl-indicator-type)
>      ...)

I still have some questions:

  . The argument is a line-number string.  You expect the absolute
    line number there?  When the line-number display style is
    'relative' or 'visual', the absolute line number might not be
    available.
  . What kind of object is the return value, and how should the
    display engine use it?
  . You seem to assume the hook will be called at point, but that is
    not true: it will be called where the display engine is scanning
    the buffer.  So you need that position (the beginning of line or
    something) in the interface, or else you will need to calculate
    the position from the line number, not a nice prospect.
  . The display engine is sometimes called to scan buffer positions
    outside of the window, so you should either detect that or be sure
    to place your properties/overlays not only in the window.  Is that
    a problem?
  . What are the triggers for changing these properties/overlays?  Are
    they determined once and for all, or can they change after the
    buffer has been created and populated with the text?  If some
    changes in the buffer affect visual appearance of screen lines
    that are otherwise unaffected by the changes, it would mean
    disabling redisplay optimizations when this feature is used.  For
    example, with 'relative' style, moving point to another line
    requires to redraw all the lines in the window.

In general, calling Lisp from the display engine means complications
and all kinds of silly precautions, to protect ourselves from crazy
Lisp, so I'm still not very fond if the idea, sorry.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 03 Jul 2019 14:20:02 +0000
Resent-Message-ID: <handler.36472.B36472.15621635622378 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.15621635622378
          (code B ref 36472); Wed, 03 Jul 2019 14:20:02 +0000
Received: (at 36472) by debbugs.gnu.org; 3 Jul 2019 14:19:22 +0000
Received: from localhost ([127.0.0.1]:49903 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hig6T-0000cH-La
	for submit <at> debbugs.gnu.org; Wed, 03 Jul 2019 10:19:22 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:37441)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1hig6R-0000c0-GE
 for 36472 <at> debbugs.gnu.org; Wed, 03 Jul 2019 10:19:20 -0400
Received: by mail-wm1-f43.google.com with SMTP id f17so2602073wme.2
 for <36472 <at> debbugs.gnu.org>; Wed, 03 Jul 2019 07:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=Gg5ozi/5VJ9ZvwPCVlajaTPGIYKgU9pl2OmF1mxoRdw=;
 b=DQmshbiMWTF64dctH1pOQ624TEsCfJF2J3iRWKQBBzoHUrL9LAPI7rRTdm4knf7eUS
 URyftcbVGkXM4uei3Pk6U+BF+2yJk/oAfovGH0o7Oo49nbl1k066jHy0BLsagh51nBoY
 f/xNsMPpt4mgQGMbbUz2cR8/TiI28gVZ0bxOzsjC/aHZzoXiF7f8y377sDhH6pgGgD/o
 tkxXNh+Nrcjj6tOSupwb9f6JCmPhh/lFDfsgfw42k07Np61CWgS4TnY3ifTwE7k6HF4g
 CS55/kCV5wRwI7uBqGB9OPRmd5/UtkS12yM/9J5OGFnirLOoV5kdK2OHjbrkbHA7euc0
 B6Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=Gg5ozi/5VJ9ZvwPCVlajaTPGIYKgU9pl2OmF1mxoRdw=;
 b=K3vUHabPRHkjjhNO6yz2fHSOmo4ni2pAjQewetjQFsDdsjzrPW2Po06ykcpXoLz8I3
 vg0TyTqrrCoobD/Bl8GoyyhVYp5EEGsa70rZaF9iVT7XhTEZUaPJlqyZuRoAKwZRRh1N
 YcBoWFMe0JL7BMWU+74WJ/FqofFQfFtMCIyMMDGUu86l1PYd7bWNQCaMtkn2az+24eGY
 iAg87J74uzhrmHML1fH/M2bto1mfK7yW+QCW28KioMjnFs2LgTMZoY6ya0FhlNH+lIYn
 4U1c4iabLhaPxojdbS5hiudtccWOBwt6lqMWdKEd7mTjekiy5tRadUVRFnHbVTtnVrsy
 akaQ==
X-Gm-Message-State: APjAAAXpKWnUXD7QJqM183ErcMzblQuqp1I/d9HgGxE3PQmvJ8L2Br1r
 yKzUps/qSwZNtae/ytD66Keru55aLBs=
X-Google-Smtp-Source: APXvYqzBSJyjNwzUNJLWX5fiwuMhNKvK2W4SHtHJErGPmZRBhwEqpvH/3gCoj2FwEZGXZ/XoBvUrsQ==
X-Received: by 2002:a1c:c2d5:: with SMTP id s204mr8576513wmf.174.1562163553216; 
 Wed, 03 Jul 2019 07:19:13 -0700 (PDT)
Received: from [192.168.0.195] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id x20sm4285684wrg.52.2019.07.03.07.19.10
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 03 Jul 2019 07:19:11 -0700 (PDT)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN> <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
 <834l44e70i.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN>
Date: Wed, 3 Jul 2019 17:19:09 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <834l44e70i.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

On 02.07.2019 19:27, Eli Zaretskii wrote:

> I still have some questions:
> 
>    . The argument is a line-number string.  You expect the absolute
>      line number there?  When the line-number display style is
>      'relative' or 'visual', the absolute line number might not be
>      available.

I'm not sure about the best design overall, but for the use case in 
question the line number should already be styled as necessary according 
to the display style. Maybe the styling function should be the first in 
this hook.

>    . What kind of object is the return value, and how should the
>      display engine use it?

A propertized string. With a 'face' or 'font-lock-face' property?

Although if we just make a hook that would return a face to use, that 
would work just as well for me.

>    . You seem to assume the hook will be called at point, but that is
>      not true: it will be called where the display engine is scanning
>      the buffer.  So you need that position (the beginning of line or
>      something) in the interface, or else you will need to calculate
>      the position from the line number, not a nice prospect.

Either the calling code would temporarily change point or, yes, the 
position would be passed to the hook functions. Either is fine by me.

>    . The display engine is sometimes called to scan buffer positions
>      outside of the window, so you should either detect that or be sure
>      to place your properties/overlays not only in the window.  Is that
>      a problem?

No, the overlays should be present everywhere by that point.

>    . What are the triggers for changing these properties/overlays?  Are
>      they determined once and for all, or can they change after the
>      buffer has been created and populated with the text?

Normally they are changed in after-save-hook. But there is an option 
that makes that happen on a timer.

> If some
>      changes in the buffer affect visual appearance of screen lines
>      that are otherwise unaffected by the changes, it would mean
>      disabling redisplay optimizations when this feature is used.  For
>      example, with 'relative' style, moving point to another line
>      requires to redraw all the lines in the window.

Well, I'm not a pro on the display engine, but shouldn't redisplay 
happen anyway when those overlays are added/modified?

Because right now they set fringe bitmaps using the before-string 
overlay property. And that should cause redisplay anyway.

> In general, calling Lisp from the display engine means complications
> and all kinds of silly precautions, to protect ourselves from crazy
> Lisp, so I'm still not very fond if the idea, sorry.

It's okay, I'm not too invested to the idea personally. But if the 
option were available, I'd whip up integration pretty quickly.

But on that subject, maybe it'd be fine to just document what the 
functions on the new hook are allowed and not allowed to do. And then 
see if we really have to add actual restrictions to force third-party 
code to behave.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 03 Jul 2019 16:15:02 +0000
Resent-Message-ID: <handler.36472.B36472.156217047412573 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.156217047412573
          (code B ref 36472); Wed, 03 Jul 2019 16:15:02 +0000
Received: (at 36472) by debbugs.gnu.org; 3 Jul 2019 16:14:34 +0000
Received: from localhost ([127.0.0.1]:49937 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hihtx-0003Gj-Ge
	for submit <at> debbugs.gnu.org; Wed, 03 Jul 2019 12:14:33 -0400
Received: from eggs.gnu.org ([209.51.188.92]:46525)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hihtv-0003GW-QJ
 for 36472 <at> debbugs.gnu.org; Wed, 03 Jul 2019 12:14:32 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:44041)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hihtq-00041z-6m; Wed, 03 Jul 2019 12:14:26 -0400
Received: from [176.228.60.248] (port=1270 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hihtp-00064d-37; Wed, 03 Jul 2019 12:14:25 -0400
Date: Wed, 03 Jul 2019 19:14:13 +0300
Message-Id: <83pnmrayei.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN> (message from
 Dmitry Gutov on Wed, 3 Jul 2019 17:19:09 +0300)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN> <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
 <834l44e70i.fsf@HIDDEN> <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 36472 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Wed, 3 Jul 2019 17:19:09 +0300
> 
> On 02.07.2019 19:27, Eli Zaretskii wrote:
> 
> > I still have some questions:
> > 
> >    . The argument is a line-number string.  You expect the absolute
> >      line number there?  When the line-number display style is
> >      'relative' or 'visual', the absolute line number might not be
> >      available.
> 
> I'm not sure about the best design overall, but for the use case in 
> question the line number should already be styled as necessary according 
> to the display style. Maybe the styling function should be the first in 
> this hook.

There's some misunderstanding here, perhaps mine.  What I wanted to
say is that you may get a relative line-number string such as "-2",
which will probably tell you nothing about the position of that line.
IOW, a line number is not a good API design in this case, because the
display engine doesn't always know the absolute line number of each
line, whereas your function must have an unambiguous descriptor of the
line's location.

> >    . What kind of object is the return value, and how should the
> >      display engine use it?
> 
> A propertized string. With a 'face' or 'font-lock-face' property?
> 
> Although if we just make a hook that would return a face to use, that 
> would work just as well for me.

A face would be much easier to use from the display engine, I think.
I assume the face attributes can only specify colors?

> >    . You seem to assume the hook will be called at point, but that is
> >      not true: it will be called where the display engine is scanning
> >      the buffer.  So you need that position (the beginning of line or
> >      something) in the interface, or else you will need to calculate
> >      the position from the line number, not a nice prospect.
> 
> Either the calling code would temporarily change point

That's an absolute no-no for the display engine, because such changes
sooner or later leak to userland and cause adverse effects.

> >    . What are the triggers for changing these properties/overlays?  Are
> >      they determined once and for all, or can they change after the
> >      buffer has been created and populated with the text?
> 
> Normally they are changed in after-save-hook. But there is an option 
> that makes that happen on a timer.

Ouch!  Another performance killer.

> > If some
> >      changes in the buffer affect visual appearance of screen lines
> >      that are otherwise unaffected by the changes, it would mean
> >      disabling redisplay optimizations when this feature is used.  For
> >      example, with 'relative' style, moving point to another line
> >      requires to redraw all the lines in the window.
> 
> Well, I'm not a pro on the display engine, but shouldn't redisplay 
> happen anyway when those overlays are added/modified?
> 
> Because right now they set fringe bitmaps using the before-string 
> overlay property. And that should cause redisplay anyway.

Redisplay should and does happen, but it tries very hard to determine
which portions of the window actually need to be redrawn.  For some
features, the answer is "the entire window", and that makes redisplay
slower.  My question was how local are the changes caused by this
feature, i.e. could it happen that changes in some place in a buffer
cause changes on display in remote places?

> But on that subject, maybe it'd be fine to just document what the 
> functions on the new hook are allowed and not allowed to do. And then 
> see if we really have to add actual restrictions to force third-party 
> code to behave.

I don't know about "allowed".  Would it be reasonable to say don't
switch buffers and/or don't select another window?  There are also
things you cannot really disallow, because the caller doesn't know
enough about what happens under the hood and doesn't control that.
For example, if the Lisp function calls vertical-motion or
posn-at-point, that invokes display routines, so the code in question
could be re-entered; but how can we tell Lisp programmers "don't call
anything that could call vertical-motion"?  And where to put such
limitations for them to be visible and discoverable enough in the
first place?

So I think imposing such limitations is impractical, and the only
reasonable thing to do whenever we call Lisp is take all the
precautions that assume the worst.  We had quite a few bugs recently
that were caused by not taking all the precautions.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 07 Jul 2019 23:48:01 +0000
Resent-Message-ID: <handler.36472.B36472.156254322121652 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.156254322121652
          (code B ref 36472); Sun, 07 Jul 2019 23:48:01 +0000
Received: (at 36472) by debbugs.gnu.org; 7 Jul 2019 23:47:01 +0000
Received: from localhost ([127.0.0.1]:57566 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hkGs1-0005d5-C0
	for submit <at> debbugs.gnu.org; Sun, 07 Jul 2019 19:47:01 -0400
Received: from mail-wm1-f46.google.com ([209.85.128.46]:33341)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1hkGrz-0005cm-A6
 for 36472 <at> debbugs.gnu.org; Sun, 07 Jul 2019 19:47:00 -0400
Received: by mail-wm1-f46.google.com with SMTP id h19so11491388wme.0
 for <36472 <at> debbugs.gnu.org>; Sun, 07 Jul 2019 16:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=bGW4AIE3U+SONdE6O4Y3bdIxM/PVqT7wuTNk06PasQ4=;
 b=IX2GKtKVG8GNo6QlcquUzgLWOJ/qMh/HKxA530ucZBwdcQ6z/zWwBu8gP5fFPT+Vi/
 dJ+u1dhSLDMUkZ9AmZjNMoYChzkey6YgN3evIhVzYCgy8KJ+K9oZf/YsH9+b2vqljo9m
 1nBgAhfR4hhfJEiwTGuRqa1eMPWVr+UabDKwQNhkCBBRs84q4M575aQaJZwVJjN42m+L
 xLsJf3EgJEqbtI3yQUSmdYSA9putK4oBuuD163Jgg/vkSWlrAuRbeUOXWXO2+lCroEl9
 E3gzHN3813xtcoDqGY2YZs12YlCUEp9gwWA16JrCzS/GUwE46bod74w9kylNPbrUCSs+
 in2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=bGW4AIE3U+SONdE6O4Y3bdIxM/PVqT7wuTNk06PasQ4=;
 b=NELVSEpQiYuA90p94Zt2se/pjmZDnR1+uAf+1zPefibM1ASoQFC7sBeGF0ilpX558q
 YnROQvcRd05XA4LVD73R0gDwzruw3AZ58lsE70weqtq7F25pMKXrwq5zlTGtWo2R5//9
 oGS+1sLD3foslZXUJNvqkkid4ZACqwQ749kNYFSu9KiMVnsIJscoH7uZLLdonX/PYp/Q
 IHOyHOtQ96hFb5qOsuixR94QQ9eexf77Xs2pb+JFD0WYAGUETOCyQr4V1/a2XUQvIbsM
 GyVhy7u8crHWiw3d2YPQpTbsQdf2U0jIWEJGeltGG5CQ8T4Cu/L41qySNnEJKuNUJW4y
 QiMA==
X-Gm-Message-State: APjAAAXk3FcvHebXmHyljWVDJNm7FyzAXaSI/4mlGrY184c5PDG7Pmy4
 apSL8UnJ8oxJPVrjbZGE4BtID6rl
X-Google-Smtp-Source: APXvYqxKKKL5Ri9xsHtBkMp+Zbn4fCtGm7iaXWsdAhEsrMsIbfFnUWEMmQpa28+tMi8KPPcpHEwbtg==
X-Received: by 2002:a1c:acc8:: with SMTP id
 v191mr13684291wme.177.1562543212877; 
 Sun, 07 Jul 2019 16:46:52 -0700 (PDT)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id w20sm42874891wra.96.2019.07.07.16.46.51
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sun, 07 Jul 2019 16:46:52 -0700 (PDT)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN> <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
 <834l44e70i.fsf@HIDDEN> <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN>
 <83pnmrayei.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <b2985e09-62ce-6bca-5830-78eb4457cba6@HIDDEN>
Date: Mon, 8 Jul 2019 02:46:50 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <83pnmrayei.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On 03.07.2019 19:14,
 Eli Zaretskii wrote: > There's some misunderstanding
 here, perhaps mine. What I wanted to > say is that you may get a relative
 line-number string such as "-2", > which will probably tell you nothing about
 the position of [...] 
 Content analysis details:   (1.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.128.46 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
 mail domains are different
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (raaahh[at]gmail.com)
 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
 EnvelopeFrom freemail headers are different
 1.3 PDS_NO_HELO_DNS        High profile HELO but no A record
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.8 (/)

On 03.07.2019 19:14, Eli Zaretskii wrote:

> There's some misunderstanding here, perhaps mine.  What I wanted to
> say is that you may get a relative line-number string such as "-2",
> which will probably tell you nothing about the position of that line.

Like I wrote in the example docstring, the hook functions would be 
called with point temporary changed to the corresponding line's 
beginning. You didn't like that, so I suggested the position would be 
passed as a second parameter to the functions. Or it can be a dynamic 
variable. Whichever option looks best to you.

> IOW, a line number is not a good API design in this case, because the
> display engine doesn't always know the absolute line number of each
> line, whereas your function must have an unambiguous descriptor of the
> line's location.

The display engine doesn't, but the display-line-numbers feature clearly 
does. Knowing line numbers is in its job description.

Or are you hinting at some optimization where, when the style is 
`relative', it doesn't bother to compute the absolute numbers?

Anyway, it doesn't matter for this particular use case: I only need 
line-beginning-position, not its absolute number.

>> Although if we just make a hook that would return a face to use, that
>> would work just as well for me.
> 
> A face would be much easier to use from the display engine, I think.
> I assume the face attributes can only specify colors?

Sure. Although some other users of this hook could also want to specify 
other properties. Maybe we'll want to combine the return values?

>> Either the calling code would temporarily change point
> 
> That's an absolute no-no for the display engine, because such changes
> sooner or later leak to userland and cause adverse effects.

OK.

>> Normally they are changed in after-save-hook. But there is an option
>> that makes that happen on a timer.
> 
> Ouch!  Another performance killer.

That feature already exists, you know. And it updates fringe or margin 
indicators. People seem to like it. In my limited testing, I haven't 
observed any major slowdowns.

> Redisplay should and does happen, but it tries very hard to determine
> which portions of the window actually need to be redrawn.  For some
> features, the answer is "the entire window", and that makes redisplay
> slower.

So is there an optimization that looks at new overlays, checks that it 
only has a before-string with a fringe spec, and then only updates the 
fringe?

> My question was how local are the changes caused by this
> feature, i.e. could it happen that changes in some place in a buffer
> cause changes on display in remote places?

In my case, the hook function would just look up a property on overlays 
at bol. Thus no far-reaching changes. But it's hard to guarantee, API-wise.

>> But on that subject, maybe it'd be fine to just document what the
>> functions on the new hook are allowed and not allowed to do. And then
>> see if we really have to add actual restrictions to force third-party
>> code to behave.
> 
> I don't know about "allowed".  Would it be reasonable to say don't
> switch buffers and/or don't select another window?

Sure, I guess. Though I would like to know why a temporary changes in 
the current buffer or the selected window would be so bad.

> There are also
> things you cannot really disallow, because the caller doesn't know
> enough about what happens under the hood and doesn't control that.
> For example, if the Lisp function calls vertical-motion or
> posn-at-point, that invokes display routines, so the code in question
> could be re-entered; but how can we tell Lisp programmers "don't call
> anything that could call vertical-motion"?  And where to put such
> limitations for them to be visible and discoverable enough in the
> first place?

I suppose the display code could check for re-entrance (e.g. by setting 
a variable at the beginning of the redisplay routine) and abort any such 
attempts with a Lisp-level error. Thus the limitation would be enforced 
at runtime, which is not perfect, but if the error is intelligible, it 
shouldn't be hard for a programmer to understand the reasons and change 
their code.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Jul 2019 12:24:02 +0000
Resent-Message-ID: <handler.36472.B36472.156258861616699 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.156258861616699
          (code B ref 36472); Mon, 08 Jul 2019 12:24:02 +0000
Received: (at 36472) by debbugs.gnu.org; 8 Jul 2019 12:23:36 +0000
Received: from localhost ([127.0.0.1]:58003 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hkSgB-0004LG-Pw
	for submit <at> debbugs.gnu.org; Mon, 08 Jul 2019 08:23:36 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49744)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hkSgA-0004L4-Fm
 for 36472 <at> debbugs.gnu.org; Mon, 08 Jul 2019 08:23:34 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:56197)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hkSg2-00017C-OC; Mon, 08 Jul 2019 08:23:28 -0400
Received: from [176.228.60.248] (port=4672 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hkSg1-0001hp-Ns; Mon, 08 Jul 2019 08:23:26 -0400
Date: Mon, 08 Jul 2019 15:23:09 +0300
Message-Id: <83d0ik7m1e.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <b2985e09-62ce-6bca-5830-78eb4457cba6@HIDDEN> (message from
 Dmitry Gutov on Mon, 8 Jul 2019 02:46:50 +0300)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN> <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
 <834l44e70i.fsf@HIDDEN> <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN>
 <83pnmrayei.fsf@HIDDEN> <b2985e09-62ce-6bca-5830-78eb4457cba6@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 36472 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 8 Jul 2019 02:46:50 +0300
> 
> > IOW, a line number is not a good API design in this case, because the
> > display engine doesn't always know the absolute line number of each
> > line, whereas your function must have an unambiguous descriptor of the
> > line's location.
> 
> The display engine doesn't, but the display-line-numbers feature clearly 
> does. Knowing line numbers is in its job description.
> 
> Or are you hinting at some optimization where, when the style is 
> `relative', it doesn't bother to compute the absolute numbers?

Yes.  In particular, in the 'visual' style.

> Anyway, it doesn't matter for this particular use case: I only need 
> line-beginning-position, not its absolute number.

Right.

> > I assume the face attributes can only specify colors?
> 
> Sure. Although some other users of this hook could also want to specify 
> other properties. Maybe we'll want to combine the return values?

If the face attributes make characters wider or narrower than the
faces of other numbers, you will have unpleasant horizontal movement
of the line's text.  Colors can never cause this.

> >> Normally they are changed in after-save-hook. But there is an option
> >> that makes that happen on a timer.
> > 
> > Ouch!  Another performance killer.
> 
> That feature already exists, you know. And it updates fringe or margin 
> indicators. People seem to like it. In my limited testing, I haven't 
> observed any major slowdowns.

I meant it will be a slow-down for redisplay.

> > Redisplay should and does happen, but it tries very hard to determine
> > which portions of the window actually need to be redrawn.  For some
> > features, the answer is "the entire window", and that makes redisplay
> > slower.
> 
> So is there an optimization that looks at new overlays, checks that it 
> only has a before-string with a fringe spec, and then only updates the 
> fringe?

Some of that.  We know whether the overlays changed, and we have tests
for whether the fringe needs to be updated on a per-line basis.

> > My question was how local are the changes caused by this
> > feature, i.e. could it happen that changes in some place in a buffer
> > cause changes on display in remote places?
> 
> In my case, the hook function would just look up a property on overlays 
> at bol. Thus no far-reaching changes.

What events trigger changes in that property?

> But it's hard to guarantee, API-wise.

Yes, this is always a concern with such hooks.

> > I don't know about "allowed".  Would it be reasonable to say don't
> > switch buffers and/or don't select another window?
> 
> Sure, I guess. Though I would like to know why a temporary changes in 
> the current buffer or the selected window would be so bad.

Because when the display engine works on a window, it always makes
that window's buffer the current buffer.  If some Lisp we call changes
that, redisplay will be confused.  So we need to save and restore the
current buffer (and sometimes also the selected frame), to avoid such
problems.

> > There are also
> > things you cannot really disallow, because the caller doesn't know
> > enough about what happens under the hood and doesn't control that.
> > For example, if the Lisp function calls vertical-motion or
> > posn-at-point, that invokes display routines, so the code in question
> > could be re-entered; but how can we tell Lisp programmers "don't call
> > anything that could call vertical-motion"?  And where to put such
> > limitations for them to be visible and discoverable enough in the
> > first place?
> 
> I suppose the display code could check for re-entrance (e.g. by setting 
> a variable at the beginning of the redisplay routine) and abort any such 
> attempts with a Lisp-level error. Thus the limitation would be enforced 
> at runtime, which is not perfect, but if the error is intelligible, it 
> shouldn't be hard for a programmer to understand the reasons and change 
> their code.

Errors signaled during redisplay are caught and only logged in
*Messages*, because displaying them would re-enter redisplay and cause
the same error again.  So such errors are not very visible, and could
go undetected for a long time.  IOW, it is better to (tediously)
protect ourselves than signal errors in such situations.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors?
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 15 Jul 2019 15:17:01 +0000
Resent-Message-ID: <handler.36472.B36472.156320379320863 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36472
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 36472 <at> debbugs.gnu.org
Received: via spool by 36472-submit <at> debbugs.gnu.org id=B36472.156320379320863
          (code B ref 36472); Mon, 15 Jul 2019 15:17:01 +0000
Received: (at 36472) by debbugs.gnu.org; 15 Jul 2019 15:16:33 +0000
Received: from localhost ([127.0.0.1]:48756 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hn2iP-0005Q6-8z
	for submit <at> debbugs.gnu.org; Mon, 15 Jul 2019 11:16:33 -0400
Received: from mail-wr1-f51.google.com ([209.85.221.51]:35564)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1hn2iN-0005Jl-JU
 for 36472 <at> debbugs.gnu.org; Mon, 15 Jul 2019 11:16:32 -0400
Received: by mail-wr1-f51.google.com with SMTP id y4so17558691wrm.2
 for <36472 <at> debbugs.gnu.org>; Mon, 15 Jul 2019 08:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=zqXoWTtAb00ASjQuJvfKa75a2/sW/XmmexAjbzUexRc=;
 b=hy5W4EHjtTDOUY/yZvohCdsxN6OVCWn+vryxwArNgpkYBTD8Z3fgSpOiYQnBko++B2
 HUVIG4RJ7Y409LKOpTsaWVwXdzU4SG4zG24EvOyP4xgEKOkV0tKwb65czqsLv7PRG6sa
 1BWjoWAzmcslYTRk3Ctg/SbrJ1vgcDgXvPXBy50X6KDixd+9IrWzf1n3vAFx/VyyZSak
 54fWv+E13IiITanRHOdI76DITlxi2AGJHyUqEw6EL2pMjKbSm+W76K/yguwA5rgCwf3/
 R7pFwZlzDtM104bzirfqe2uEbsVwUk0hZpZHGeaLI1yCO41+PqCuMhFBfIKs3MMFGl46
 bz8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=zqXoWTtAb00ASjQuJvfKa75a2/sW/XmmexAjbzUexRc=;
 b=IWqjcUslmDjPGMybwcDWBb5+sNK3Iqh+nJuaFBy+bISGDpiNtDxg0SNvib6IqCFXeO
 TzGO5ZA5k4eWzw090GuRIO0ybw3ITrl24XfIY4GNHlzroW/c7sqHKThGb/nq1dgr6+y9
 V4yz4u8ZdMyj6wkhw5CYc1EoSDl91HRGpcWoYrU9BhuLBvmsgHdUoD3Jupo4LUIPOFAG
 rxdOjZ2o6GmAAueaxP+k0cgmhdWNocfGA3A/Z+zvjxePOlqO1Ke3BsjQMxRsGU5Nvm+b
 rmjLzwUTlcMrEF4zXEYwkF/3hoROlhXXuNIrNRZuB9AK7kKB8fv12aCmB/8SzeoKe0sm
 A8zw==
X-Gm-Message-State: APjAAAVTNs1lOGmMm/cAK+pEnArMpD/KIU/s2W2J2Ri/8maL+6iXjKBs
 2X8daL3uK9N470Jr2C4ZRVoca7ba
X-Google-Smtp-Source: APXvYqwLOagR+YFkg24u2+SGpnYK9vbtnVVQIHebZCEyYzvV2qnBgsZUMvCkxu9vS+1OqH/VYJ70qQ==
X-Received: by 2002:adf:e8cb:: with SMTP id k11mr28902485wrn.244.1563203785386; 
 Mon, 15 Jul 2019 08:16:25 -0700 (PDT)
Received: from [192.168.0.195] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id l8sm31682267wrg.40.2019.07.15.08.16.24
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 15 Jul 2019 08:16:24 -0700 (PDT)
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
 <83blycecf7.fsf@HIDDEN> <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN>
 <835zoke9at.fsf@HIDDEN> <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN>
 <834l44e70i.fsf@HIDDEN> <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN>
 <83pnmrayei.fsf@HIDDEN> <b2985e09-62ce-6bca-5830-78eb4457cba6@HIDDEN>
 <83d0ik7m1e.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <811ed2d5-c812-a813-1292-d922df1e7fa3@HIDDEN>
Date: Mon, 15 Jul 2019 18:16:23 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <83d0ik7m1e.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

On 08.07.2019 15:23, Eli Zaretskii wrote:

> If the face attributes make characters wider or narrower than the
> faces of other numbers, you will have unpleasant horizontal movement
> of the line's text.  Colors can never cause this.

Makes sense.

>>>> Normally they are changed in after-save-hook. But there is an option
>>>> that makes that happen on a timer.
>>>
>>> Ouch!  Another performance killer.
>>
>> That feature already exists, you know. And it updates fringe or margin
>> indicators. People seem to like it. In my limited testing, I haven't
>> observed any major slowdowns.
> 
> I meant it will be a slow-down for redisplay.

Not sure I understand you here. Redisplay would be slowed down by 
waiting for timers?

>> So is there an optimization that looks at new overlays, checks that it
>> only has a before-string with a fringe spec, and then only updates the
>> fringe?
> 
> Some of that.  We know whether the overlays changed, and we have tests
> for whether the fringe needs to be updated on a per-line basis.

If it's really making a noticeable change, maybe we could standardize on 
a text property which would indicate which colors to use for the 
display-line-numbers area. That would circumvent the whole issue of 
running Lisp in redisplay.

>>> My question was how local are the changes caused by this
>>> feature, i.e. could it happen that changes in some place in a buffer
>>> cause changes on display in remote places?
>>
>> In my case, the hook function would just look up a property on overlays
>> at bol. Thus no far-reaching changes.
> 
> What events trigger changes in that property?

Like I said, saving a buffer, or a timer firing (depending on whether a 
certain modification in enabled). Also the user can make an overlay 
outdated by typing, so the highlighting is removed right away in such 
cases (only for the closest hunk).

> Because when the display engine works on a window, it always makes
> that window's buffer the current buffer.  If some Lisp we call changes
> that, redisplay will be confused.  So we need to save and restore the
> current buffer (and sometimes also the selected frame), to avoid such
> problems.

But if any such change is temporary (e.g. using with-current-buffer), 
it's all well, right? In that case, such limitation sounds very 
reasonable to me.

> Errors signaled during redisplay are caught and only logged in
> *Messages*, because displaying them would re-enter redisplay and cause
> the same error again.  So such errors are not very visible, and could
> go undetected for a long time.  IOW, it is better to (tediously)
> protect ourselves than signal errors in such situations.

I don't know, I still think it's better for the programmer to see the 
error to be able to fix their code. Even if it's only in *Messages*. The 
accompanying simplification of error handling sounds beneficial to me as 
well.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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