GNU bug report logs - #36472
27.0.50; Convey information by showing line numbers using different colors?

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: wishlist; Reported by: Dmitry Gutov <dgutov@HIDDEN>; dated Tue, 2 Jul 2019 11:15:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 15 Jul 2019 15:16:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 15 11:16:33 2019
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)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
To: Eli Zaretskii <eliz@HIDDEN>
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 8 Jul 2019 12:23:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 08 08:23:36 2019
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>
To: Dmitry Gutov <dgutov@HIDDEN>
In-reply-to: <b2985e09-62ce-6bca-5830-78eb4457cba6@HIDDEN> (message from
 Dmitry Gutov on Mon, 8 Jul 2019 02:46:50 +0300)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 7 Jul 2019 23:47:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 07 19:47:01 2019
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)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
To: Eli Zaretskii <eliz@HIDDEN>
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 3 Jul 2019 16:14:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 03 12:14:33 2019
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>
To: Dmitry Gutov <dgutov@HIDDEN>
In-reply-to: <94198c02-f646-1493-58d4-422349c0d1a5@HIDDEN> (message from
 Dmitry Gutov on Wed, 3 Jul 2019 17:19:09 +0300)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 3 Jul 2019 14:19:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 03 10:19:22 2019
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)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
To: Eli Zaretskii <eliz@HIDDEN>
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 16:28:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 02 12:28:07 2019
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>
To: Dmitry Gutov <dgutov@HIDDEN>
In-reply-to: <761edfce-9f36-8570-3700-a8bb5ced99b0@HIDDEN> (message from
 Dmitry Gutov on Tue, 2 Jul 2019 18:49:38 +0300)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 15:49:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 02 11:49:51 2019
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)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
To: Eli Zaretskii <eliz@HIDDEN>
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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)
     ...)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 15:38:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 02 11:38:43 2019
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>
To: Dmitry Gutov <dgutov@HIDDEN>
In-reply-to: <cdb30f25-6d28-1c45-d0ea-37d06ba91538@HIDDEN> (message from
 Dmitry Gutov on Tue, 2 Jul 2019 18:09:01 +0300)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
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-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 15:09:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 02 11:09:12 2019
Received: from localhost ([127.0.0.1]:47651 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hiKP9-0007go-Mn
	for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 11:09:11 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:34279)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1hiKP7-0007gY-Lf
 for 36472 <at> debbugs.gnu.org; Tue, 02 Jul 2019 11:09:10 -0400
Received: by mail-wm1-f43.google.com with SMTP id w9so787172wmd.1
 for <36472 <at> debbugs.gnu.org>; Tue, 02 Jul 2019 08:09:09 -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=OdtFtpnFFCThpvqShs5BtJ4CP2RbvW30XGAXBB6xWTQ=;
 b=t6qf2lZ7r8sJs3vAXP1Vy/n7ay6Oeb5W85iHdHMsHu9sJ2PQC+6LhIFSY5ss8/TFqA
 mNdsjDjYCQ8Q229hEpgFaj18JrZy2KpZiUHT2gFuCpydxFZgb6nqMIz1j5j/IGgBjit+
 AMNndsT4AVGKgl6TRqiSywhd+V1GzdOajEvNY0vkglS8AgmOTZtNwysKWhQcWmnErzdg
 Q/C9XBb7RfljPW97qjCgumnsXoS0YjIDsG0ufReEJtaOLnEbWqqMfL2/Q+gO6quxI/Ti
 /aO+7JyhdVmEKMDSV++gpSe3oL5uE+viqC+WESkhMzUxiq07mNNXOgrhDOPi3cVTSR4h
 PGWw==
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=OdtFtpnFFCThpvqShs5BtJ4CP2RbvW30XGAXBB6xWTQ=;
 b=cMiwtnomfQQx3mdXGcg+SaC59VGH4PU8EXiZYPhcbj7bJPLGUUJfD2JUC2ejBZjVZF
 1vZ4xznsI08EDxRFj0JAyjRp23LtuRuWPayQ/C2tOlCJJ+dYr6Vw1guH1kY1HqZvCZa2
 6fJAEn4AXJtwZIeNmbfwIE65/cVNfvW9hbn7gTBBEXd8OJiHG6+CArtEb5vRL25eublu
 KEFC9Bh2HmHUGxNb7SRetNqjHkSWh0zU8dJMUS0tt6ZPNWECp07SeFKCfy7SShcl3k0C
 63QQ5ZBgBWXLeKkWmpXYk67A5mF8hMUFlx5FtV3qVKcGDdCSw9CI1KSxkMpXXICRgpPh
 5osw==
X-Gm-Message-State: APjAAAWiO2yIgRwrtrw2ksP3d2UPs4MqydcXK/oJ7Se7OeOcxhWDLL0F
 ysNKOVDujhS951CO2dGclL/zJwOqMVA=
X-Google-Smtp-Source: APXvYqxy5BRBTxPT1GZKTvZyozIBO+Krv1qzcEp5uENtiRmg2+OWsH5eJGQLIJ1KfP0EfTAo0H2IKA==
X-Received: by 2002:a05:600c:20d:: with SMTP id
 13mr3735701wmi.141.1562080143477; 
 Tue, 02 Jul 2019 08:09:03 -0700 (PDT)
Received: from [192.168.0.195] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id w20sm29783218wra.96.2019.07.02.08.09.01
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 02 Jul 2019 08:09:02 -0700 (PDT)
Subject: Re: bug#36472: 27.0.50; Convey information by showing line numbers
 using different colors?
To: Eli Zaretskii <eliz@HIDDEN>
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
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at 36472 <at> debbugs.gnu.org:


Received: (at 36472) by debbugs.gnu.org; 2 Jul 2019 14:31:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 02 10:31:20 2019
Received: from localhost ([127.0.0.1]:47624 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hiJoU-0006nx-GJ
	for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 10:31:20 -0400
Received: from eggs.gnu.org ([209.51.188.92]:37075)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hiJoS-0006nk-Hf
 for 36472 <at> debbugs.gnu.org; Tue, 02 Jul 2019 10:31:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:49898)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hiJoK-0003R6-Ib; Tue, 02 Jul 2019 10:31:10 -0400
Received: from [176.228.60.248] (port=4491 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 1hiJoI-0005MP-Ml; Tue, 02 Jul 2019 10:31:08 -0400
Date: Tue, 02 Jul 2019 17:30:52 +0300
Message-Id: <83blycecf7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
In-reply-to: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN> (message from
 Dmitry Gutov on Tue, 2 Jul 2019 14:14:15 +0300)
Subject: Re: bug#36472: 27.0.50;
 Convey information by showing line numbers using different colors?
References: <b6c7c7c6-2f1c-3aba-b4c2-33db21ce44f1@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36472
Cc: 36472 <at> debbugs.gnu.org
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 (---)

> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 2 Jul 2019 11:14:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 02 07:14:33 2019
Received: from localhost ([127.0.0.1]:46611 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hiGk4-00084e-Vp
	for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 07:14:33 -0400
Received: from lists.gnu.org ([209.51.188.17]:46057)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1hiGk3-00084X-TR
 for submit <at> debbugs.gnu.org; Tue, 02 Jul 2019 07:14:32 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:55647)
 by lists.gnu.org with esmtp (Exim 4.86_2)
 (envelope-from <raaahh@HIDDEN>) id 1hiGk1-0006y5-VZ
 for bug-gnu-emacs@HIDDEN; Tue, 02 Jul 2019 07:14:31 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <raaahh@HIDDEN>) id 1hiGjy-0001y0-OU
 for bug-gnu-emacs@HIDDEN; Tue, 02 Jul 2019 07:14:29 -0400
Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:33723)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1hiGju-0001gL-Cv
 for bug-gnu-emacs@HIDDEN; Tue, 02 Jul 2019 07:14:24 -0400
Received: by mail-wm1-x330.google.com with SMTP id h19so326505wme.0
 for <bug-gnu-emacs@HIDDEN>; Tue, 02 Jul 2019 04:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:to:from:subject:message-id:date:user-agent:mime-version
 :content-language:content-transfer-encoding;
 bh=Hd085wbEhN2wRcJEqcSBL43Zc0Kfd857WlPKD89zYW8=;
 b=WhLcC7Otam9rJrXo1B8pbbsvcrcBmsEr5vgJZf27b4HyxK26scg7v0XQThgaeigMH/
 RLHUmpgdxvmfrg2Fu8ybOeLpSHTpX8PIqw9rWSInrI7WVCWrpAHvdmI1P+fJySg4c+jn
 ISftz0VFR9CzzWI/vO/wBKnPnuflyUugztG6r5UzPFA3DFEjOG7XSdvjz0q8VEwDBn+5
 /z/4LPoA2jccodYoN5aazUrvF04+TyAMfXEZsi6znp42NcWFg6QTQpGpUgJeigvJz1pK
 T1H6nhPt3991b6D4od5s2Tx3N14gR9E3Dj1g7XgUGmDnFPU9EzCT9/Fjp71VwZ9QVCO7
 mnSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:to:from:subject:message-id:date
 :user-agent:mime-version:content-language:content-transfer-encoding;
 bh=Hd085wbEhN2wRcJEqcSBL43Zc0Kfd857WlPKD89zYW8=;
 b=ASxLrFsXkDClYRQ+vUD7nygT09tjLk4EUY3YLA2TXoxTziBPk5x8E6J0AHsR5xH/G6
 Osbp1SJEKeNu50XygYPSlbHAYHVYvlDm+r4Et2s+HqjfbDAN2X8Zm9e73VMFGI8E4p6I
 ol9R4cEzGyDdlxzYlDs/dcolb4nIOtAlzvJvWHENdbmvJLEfHfg89l8Hd5Bmf2NduOX5
 rYPWiNkcydy+GBLm22ZglRZcK8VdqCpDT0IHoxojLSIqhZAYITsjHvpStP2gdmNmBiaC
 ff4kdq/0wh4Opely0RB6xNBn0sCZWoa6wjjQjbsJA7W940tOHk4kDRJShZrt4VMbqMyp
 JqTQ==
X-Gm-Message-State: APjAAAV37HqePnGq0MQ2JmfzLP4PppvAKgtBv+UGE6GWlXpUVZPRjQFn
 WJPgGj2DIYfvFHupAU0HEAku7hNyTXQ=
X-Google-Smtp-Source: APXvYqwqL5y9HC1kC+b2ffY0H2MmRR7Jy7aW3LZBIgZO9hBwBW4Hz28sQ10fdyFIt+GVWvQ4HY8JUQ==
X-Received: by 2002:a1c:f61a:: with SMTP id w26mr3367883wmc.75.1562066058161; 
 Tue, 02 Jul 2019 04:14:18 -0700 (PDT)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id h133sm2620944wme.28.2019.07.02.04.14.16
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 02 Jul 2019 04:14:17 -0700 (PDT)
To: bug-gnu-emacs@HIDDEN
From: Dmitry Gutov <dgutov@HIDDEN>
Subject: 27.0.50; Convey information by showing line numbers using different
 colors?
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
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-Received-From: 2a00:1450:4864:20::330
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
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: -2.3 (--)

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




Acknowledgement sent to Dmitry Gutov <dgutov@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#36472; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
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.