From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors? Date: Wed, 03 Jul 2019 19:14:13 +0300 Message-ID: <83pnmrayei.fsf@gnu.org> References: <83blycecf7.fsf@gnu.org> <835zoke9at.fsf@gnu.org> <761edfce-9f36-8570-3700-a8bb5ced99b0@yandex.ru> <834l44e70i.fsf@gnu.org> <94198c02-f646-1493-58d4-422349c0d1a5@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="236117"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36472@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 03 18:50:49 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hiiT2-000z5v-Vk for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 18:50:49 +0200 Original-Received: from localhost ([::1]:37650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiQI-0005ur-4U for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 12:47:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58998) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hihuX-0001Jy-P0 for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:15:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hihuU-0004PK-0V for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:15:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41116) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hihuQ-0004Lf-OY for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hihuQ-0003Hh-FU for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 12:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jul 2019 16:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36472 X-GNU-PR-Package: emacs Original-Received: via spool by 36472-submit@debbugs.gnu.org id=B36472.156217047412573 (code B ref 36472); Wed, 03 Jul 2019 16:15:02 +0000 Original-Received: (at 36472) by debbugs.gnu.org; 3 Jul 2019 16:14:34 +0000 Original-Received: from localhost ([127.0.0.1]:49937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hihtx-0003Gj-Ge for submit@debbugs.gnu.org; Wed, 03 Jul 2019 12:14:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hihtv-0003GW-QJ for 36472@debbugs.gnu.org; Wed, 03 Jul 2019 12:14:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hihtq-00041z-6m; Wed, 03 Jul 2019 12:14:26 -0400 Original-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 ) id 1hihtp-00064d-37; Wed, 03 Jul 2019 12:14:25 -0400 In-reply-to: <94198c02-f646-1493-58d4-422349c0d1a5@yandex.ru> (message from Dmitry Gutov on Wed, 3 Jul 2019 17:19:09 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162027 Archived-At: > Cc: 36472@debbugs.gnu.org > From: Dmitry Gutov > 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.