From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones) Date: Sat, 25 Apr 2020 17:04:36 +0300 Message-ID: <83sggr7jbf.fsf@gnu.org> References: <33007735-30b9-4c52-c440-929686e1cb0e@gmail.com> <83o8rg809k.fsf@gnu.org> <5da7af4f-0f8c-c79c-38d7-ed7465d9b34d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="49457"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40821@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 25 16:05:19 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jSLQk-000Cj9-5u for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 16:05:18 +0200 Original-Received: from localhost ([::1]:37788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSLQj-00019j-6z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 10:05:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37264) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSLQV-00019M-7d for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 10:05:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSLQU-0002L4-Ok for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 10:05:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48559) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSLQU-0002K3-BU for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 10:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSLQU-0001O9-62 for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 10:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 14:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40821 X-GNU-PR-Package: emacs Original-Received: via spool by 40821-submit@debbugs.gnu.org id=B40821.15878234955320 (code B ref 40821); Sat, 25 Apr 2020 14:05:02 +0000 Original-Received: (at 40821) by debbugs.gnu.org; 25 Apr 2020 14:04:55 +0000 Original-Received: from localhost ([127.0.0.1]:60105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSLQM-0001Nj-Hz for submit@debbugs.gnu.org; Sat, 25 Apr 2020 10:04:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSLQL-0001NX-DO for 40821@debbugs.gnu.org; Sat, 25 Apr 2020 10:04:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55163) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSLQF-0001po-Vs; Sat, 25 Apr 2020 10:04:48 -0400 Original-Received: from [176.228.60.248] (port=3548 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSLQF-0005hB-9e; Sat, 25 Apr 2020 10:04:47 -0400 In-Reply-To: <5da7af4f-0f8c-c79c-38d7-ed7465d9b34d@gmail.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel on Sat, 25 Apr 2020 09:01:07 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178995 Archived-At: > Cc: 40821@debbugs.gnu.org > From: Clément Pit-Claudel > Date: Sat, 25 Apr 2020 09:01:07 -0400 > > On 25/04/2020 03.58, Eli Zaretskii wrote: > >> One unfortunate side effect of this is that, when margins are too narrow, low-priority margin specs are displayed before high-priority ones, and hence high-priority ones are not visible. > > > > Yes, the display margins use this very simple strategy of truncating > > the stuff that has no margin space to be displayed. Why can't you > > compute the width of the margins taking into consideration the size of > > what you need to display there? > > I only want/need to display one margin indicator — the highest priority one :) Then why not have your code do that? > Consider a line with the following contents: > > eee www ewew > > And let's assume that the compiler says this: > > 0-3: error: … > 4-7: warning: … > 8-12: error: … > 8-12: warning: … > > In that case, I don't need 4 indicators in the margin, I want just one (indicating an error). But in the the buffer I'd like 4 overlays to apply error and warning faces (though, since two of them cover the same area, one will not be visible; overlay priorities are used to ensure that the error one will take precedence over the warning one). It is your Lisp program that puts these overlays, isn't it? Why cannot it put only one overlay, the one you want to be displayed in this case? > (with-current-buffer (get-buffer-create "*fringes*") > (erase-buffer) > (delete-all-overlays) > (let ((beg (point)) > (end (progn (insert "test") (point)))) > (let ((ov-low (make-overlay beg end))) > (overlay-put ov-low 'before-string (propertize "low" 'display '(left-fringe right-arrow compilation-info))) > (overlay-put ov-low 'priority 10)) > (let ((ov-mid (make-overlay beg end))) > (overlay-put ov-mid 'before-string (propertize "mid" 'display '(left-fringe compilation-warning))) > (overlay-put ov-mid 'priority 50)) > (let ((ov-high (make-overlay beg end))) > (overlay-put ov-high 'before-string (propertize "high" 'display '(left-fringe compilation-error))) > (overlay-put ov-high 'priority 100))) > (pop-to-buffer (current-buffer))) > > I thought this would show a fringe icon in compilation-error face, because of the higher priority of the corresponding overlay. It doesn't. > Should I report this as a separate issue? Why is that an issue? You in effect invoke undefined behavior, and the result is not outlandish, IMO. > > It should be possible to support this idea of "replacing" margin specs > > (which seems strange to me, FWIW), given some special display spec, > > but it would need a separate pass through the overlays, to find those > > which draw in the margins, and mark the replaced ones as "not to be > > processed". But I question the need for such a complexity, when a > > simpler solution that doesn't require any changes seems to be at hand. > > Widening the margin isn't a working solution for this case, but displaying the margin specs in order of increasing priority would work. However, wouldn't that require a second pass as well? That is, if margin specs were sorted by priority before being inserted, it would work (it wouldn't matter that there are multiple instead of one, since the most important one would be first). Now I'm confused: the overlays are already being sorted by the display engine, and displayed in the order of increasing priority, as I explained in my original message.