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: Mon, 08 Jul 2019 15:23:09 +0300 Message-ID: <83d0ik7m1e.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> <83pnmrayei.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="147037"; 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 Mon Jul 08 14:39:42 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 1hkSvl-000bv6-QG for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Jul 2019 14:39:41 +0200 Original-Received: from localhost ([::1]:41264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkSgv-0007gK-KX for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Jul 2019 08:24:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33977) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkSgh-0007dX-73 for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2019 08:24:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkSge-0001Qs-0Y for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2019 08:24:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49182) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkSgc-0001QG-Gk for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2019 08:24:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hkSgc-0004Lv-8g for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2019 08:24: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: Mon, 08 Jul 2019 12:24: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.156258861616699 (code B ref 36472); Mon, 08 Jul 2019 12:24:02 +0000 Original-Received: (at 36472) by debbugs.gnu.org; 8 Jul 2019 12:23:36 +0000 Original-Received: from localhost ([127.0.0.1]:58003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkSgB-0004LG-Pw for submit@debbugs.gnu.org; Mon, 08 Jul 2019 08:23:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkSgA-0004L4-Fm for 36472@debbugs.gnu.org; Mon, 08 Jul 2019 08:23:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hkSg2-00017C-OC; Mon, 08 Jul 2019 08:23:28 -0400 Original-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 ) id 1hkSg1-0001hp-Ns; Mon, 08 Jul 2019 08:23:26 -0400 In-reply-to: (message from Dmitry Gutov on Mon, 8 Jul 2019 02:46:50 +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:162324 Archived-At: > Cc: 36472@debbugs.gnu.org > From: Dmitry Gutov > 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.