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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.
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)
...)
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.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
Dmitry Gutov <dgutov@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#36472; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.