From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#36472: 27.0.50; Convey information by showing line numbers using different colors? Date: Mon, 8 Jul 2019 02:46:50 +0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="60186"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Cc: 36472@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 08 01:48:13 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 1hkGtA-000FSV-CS for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Jul 2019 01:48:12 +0200 Original-Received: from localhost ([::1]:37632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkGt9-0002IW-Dz for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jul 2019 19:48:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42513) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkGt2-0002I2-P2 for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 19:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkGt0-0001JC-U2 for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 19:48:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48745) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkGt0-0001Is-4H for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 19:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hkGsz-0005eS-VM for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 19:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jul 2019 23:48:01 +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.156254322121652 (code B ref 36472); Sun, 07 Jul 2019 23:48:01 +0000 Original-Received: (at 36472) by debbugs.gnu.org; 7 Jul 2019 23:47:01 +0000 Original-Received: from localhost ([127.0.0.1]:57566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkGs1-0005d5-C0 for submit@debbugs.gnu.org; Sun, 07 Jul 2019 19:47:01 -0400 Original-Received: from mail-wm1-f46.google.com ([209.85.128.46]:33341) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkGrz-0005cm-A6 for 36472@debbugs.gnu.org; Sun, 07 Jul 2019 19:47:00 -0400 Original-Received: by mail-wm1-f46.google.com with SMTP id h19so11491388wme.0 for <36472@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) Original-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) In-Reply-To: <83pnmrayei.fsf@gnu.org> Content-Language: en-US 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:162310 Archived-At: 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.