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, 15 Jul 2019 18:16:23 +0300 Message-ID: <811ed2d5-c812-a813-1292-d922df1e7fa3@yandex.ru> 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> <83d0ik7m1e.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="76723"; 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 15 17:17:12 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 1hn2j2-000Jkz-Fn for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Jul 2019 17:17:12 +0200 Original-Received: from localhost ([::1]:40002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hn2iw-0006S8-0X for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Jul 2019 11:17:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45476) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hn2it-0006S0-BN for bug-gnu-emacs@gnu.org; Mon, 15 Jul 2019 11:17:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hn2is-0005af-4I for bug-gnu-emacs@gnu.org; Mon, 15 Jul 2019 11:17:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39938) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hn2is-0005aS-0H for bug-gnu-emacs@gnu.org; Mon, 15 Jul 2019 11:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hn2ir-0005my-QA for bug-gnu-emacs@gnu.org; Mon, 15 Jul 2019 11:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Jul 2019 15:17: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.156320379320863 (code B ref 36472); Mon, 15 Jul 2019 15:17:01 +0000 Original-Received: (at 36472) by debbugs.gnu.org; 15 Jul 2019 15:16:33 +0000 Original-Received: from localhost ([127.0.0.1]:48756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hn2iP-0005Q6-8z for submit@debbugs.gnu.org; Mon, 15 Jul 2019 11:16:33 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:35564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hn2iN-0005Jl-JU for 36472@debbugs.gnu.org; Mon, 15 Jul 2019 11:16:32 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id y4so17558691wrm.2 for <36472@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) Original-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) In-Reply-To: <83d0ik7m1e.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:163126 Archived-At: 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.