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: Wed, 3 Jul 2019 17:19:09 +0300 Message-ID: <94198c02-f646-1493-58d4-422349c0d1a5@yandex.ru> References: <83blycecf7.fsf@gnu.org> <835zoke9at.fsf@gnu.org> <761edfce-9f36-8570-3700-a8bb5ced99b0@yandex.ru> <834l44e70i.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="100398"; 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 Wed Jul 03 16:20:27 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 1hig7W-000Q00-GC for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 16:20:26 +0200 Original-Received: from localhost ([::1]:36316 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hig7U-0008JZ-SN for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Jul 2019 10:20:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53287) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hig7A-0008JF-BG for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 10:20:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hig79-0000I5-28 for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 10:20:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41082) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hig78-0000Hy-UJ for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 10:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hig78-0000dV-OK for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2019 10:20: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: Wed, 03 Jul 2019 14:20: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.15621635622378 (code B ref 36472); Wed, 03 Jul 2019 14:20:02 +0000 Original-Received: (at 36472) by debbugs.gnu.org; 3 Jul 2019 14:19:22 +0000 Original-Received: from localhost ([127.0.0.1]:49903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hig6T-0000cH-La for submit@debbugs.gnu.org; Wed, 03 Jul 2019 10:19:22 -0400 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:37441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hig6R-0000c0-GE for 36472@debbugs.gnu.org; Wed, 03 Jul 2019 10:19:20 -0400 Original-Received: by mail-wm1-f43.google.com with SMTP id f17so2602073wme.2 for <36472@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) Original-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) In-Reply-To: <834l44e70i.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:162023 Archived-At: 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.