From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Colorful line numbers Date: Fri, 22 Jul 2022 13:02:01 +0100 Message-ID: <87zgh1nyo6.fsf@gmail.com> References: <87leslpow2.fsf@gmail.com> <83ilnpl8e0.fsf@gnu.org> <874jz9peq0.fsf@gmail.com> <837d45l6ge.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6332"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 22 14:04:13 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oErO9-0001Sn-AD for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 14:04:13 +0200 Original-Received: from localhost ([::1]:42900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oErO8-0001j9-D8 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 08:04:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oErKt-0007Pk-Gi for emacs-devel@gnu.org; Fri, 22 Jul 2022 08:01:01 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:37393) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oErKr-0005YQ-AC; Fri, 22 Jul 2022 08:00:51 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id u5so6205351wrm.4; Fri, 22 Jul 2022 05:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=9nLA20YnWSXGHHWWuj0pzfQQ/HegKKNhbmxEh1tqS5s=; b=T2zHdIWcgOQax73zrYytEuhk27tpME/2TxloVXmJ+tHyO3khtTkeBGPAhlKFfM4FM8 9nXC9gLsJoJZYeziwBQCwl+7WUmhbIuJuaPfpFXMIkZaH8Elm4Kko4Cz2tSqGNoCy+RV f8bjWaORd/3eTJ/vm6jFj29OnI6h2TaDsYfytVU/hyRLD/BYicQZnLw6V/6oXYQ4n8+s SDOVrak5ch6qHf8yf/+jbEqGKPjMEdcWOSRI0JR5UcAaX3L/A9G3Y5OuJkEi2DEocqGt vJH19MdPc+pp0wp1Jj2afzd43q3jyayPO6qbJMhpyf8FBGuptZDK53iUwvkmIZksYTTB S0yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version:content-transfer-encoding; bh=9nLA20YnWSXGHHWWuj0pzfQQ/HegKKNhbmxEh1tqS5s=; b=DroV76bLmcuuuhQqs7ttfMdP0Uda7iPXyzF5K7kn6hLi7eL2taJo5KTvr+aj4BkQnQ 80W7kIZgL5SOV0FUBH8cW3lVftC7oB2lTM5J9rOrMreUqYucVoouqUNmAX4QOwmF1I4z QP74ViqmKURPUkATLmuG+uGhynff8R3/bXCyGaxV+sgaJePhDeBevOE7hV8CvmJb5cn6 1B7VtnK0wYYM+PxXzGbnKiY3xnHV78wIoeiricNo4Lk3/+10DNPTAf5M1ik4YFxv/cX3 Fq8zYp7Uf913jqYHQ2tt8Ac4H9gBU2lsSBiAwFdVjRHYzs/UiZV3DH+ygbLcD0UO6cC8 BEIQ== X-Gm-Message-State: AJIora+NbBEygoyt1TYCiCwjBdrFBA4FCBYGmwhoyN2ubzEB1EcDWZ9U /e9RhBWa5p6H/vM689y6WMFVILx9urs= X-Google-Smtp-Source: AGRyM1t3tM9hMVS73H7OUsetV7rfJJ2wKf1/WZs0NWJq7ck2Y1qChDonYF5HYwKTbHPsXQ44Dnm7HQ== X-Received: by 2002:adf:fbc6:0:b0:21d:3fc3:99e with SMTP id d6-20020adffbc6000000b0021d3fc3099emr106230wrs.550.1658491246437; Fri, 22 Jul 2022 05:00:46 -0700 (PDT) Original-Received: from krug (87-196-72-209.net.novis.pt. [87.196.72.209]) by smtp.gmail.com with ESMTPSA id bg42-20020a05600c3caa00b003a31b79dc0esm21625928wmb.1.2022.07.22.05.00.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jul 2022 05:00:46 -0700 (PDT) In-Reply-To: <837d45l6ge.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Jul 2022 14:42:09 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x429.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292422 Archived-At: Eli Zaretskii writes: >> Does checking for a given text property on some buffer text call into >> Lisp? If it isn't, and it's cheap, then this hypothetical feature could >> have very low overhead when not used. > You want the line number to have the same face as the character > displayed immediately after it? Not the "same face", rather some face which is the result of querying text properties on that text.=20 > That can be done from C without calling Lisp, but how would that work > reliably? Any change in the buffer text will risk breaking the > feature. It's up to the Lisp package that is interested in this functionality to set or unset the correct text property.=20 > And even this is already a complication I'd like to avoid: line number > of a line is rendered before we examine the buffer text of the line > (and even know whether there is any text there). Now we would need to > look forward in the buffer and get text properties of that text. > Which might not work correctly, btw, if jit-lock was not yet invoked > to produce the faces there. See above. This wouldn't be a problem because I'm not interesting in choosing the same face that jit-lock selected. The indirection would be some text property, say line-number-face > Likewise if the line is hscrolled, so > that the first character displayed to the right of the line number is > not the first character of the physical line. It would be up to the Lisp package to propertize the whole line with 'line-number-face'. >> Even if you're opposed the idea, could you perhaps some pointers on how >> to implement it, so that I try my hand at it and benchmark the >> before/after? > > The implementation is in maybe_produce_line_number in xdisp.c. Yes, I've seen it (this is would I discovered the closed set of faces). But I'm not familiar with xdisp.c code and how to get to the buffer text about to be displayed besides the line number (if it indeed exists) and the associated text properties of that text. The only argument passed to maybe_produce_line_number is a 'struct it'. How to go from there to any valid buffer position of the same line that the 'struct it' refers to? > You can change the colors of the text without affecting the line > numbers. Line numbers have a distinct face for a good reason. See above. I'm not interested in having line number have exactly the same face/color as any one of the characters in the buffer text. >> I've recently discovered Jay Kamat's most excellent rmsbolt.el. It is >> is even better than godbolt.org in many aspects but is missing this last >> feature, which I would like to add. But instead of highlighting the >> whole line, I thought it would be nicer and less distracting if I just >> highlighted the line number's background. > > Why not put some indication on the fringe instead? I'm experimenting with that, too. Not the fringe, since it only works on graphical displays, but the margin. >> > And if they aren't enough, why cannot you use line-number-mode? >> I do use line-number-mode, but I don't understand how it can help me >> here. AFAIK it shows me one line number at a time in the modeline, not >> besides the text. > Sorry, I meant linum-mode. Ah. I could indeed, but I would still like to experiment with the display-line-numbers-mode. Jo=C3=A3o