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 10:58:31 +0300 Message-ID: <83o8rg809k.fsf@gnu.org> References: <33007735-30b9-4c52-c440-929686e1cb0e@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="120348"; 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 09:59:11 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 1jSFiR-000VCL-96 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 09:59:11 +0200 Original-Received: from localhost ([::1]:60298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSFiP-0005TF-RL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 03:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44462) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSFiI-0005Sw-E3 for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 03:59:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSFiI-00059Y-0u for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 03:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46925) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSFiH-00055V-KX for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 03:59:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSFiH-0002Z6-Jp for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 03:59:01 -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 07:59:01 +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.15878015309843 (code B ref 40821); Sat, 25 Apr 2020 07:59:01 +0000 Original-Received: (at 40821) by debbugs.gnu.org; 25 Apr 2020 07:58:50 +0000 Original-Received: from localhost ([127.0.0.1]:58471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSFi5-0002Yb-Se for submit@debbugs.gnu.org; Sat, 25 Apr 2020 03:58:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSFi3-0002YI-IQ; Sat, 25 Apr 2020 03:58:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50052) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSFhy-00018p-7G; Sat, 25 Apr 2020 03:58:42 -0400 Original-Received: from [176.228.60.248] (port=4783 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSFhw-0003CE-Py; Sat, 25 Apr 2020 03:58:41 -0400 In-Reply-To: <33007735-30b9-4c52-c440-929686e1cb0e@gmail.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel on Fri, 24 Apr 2020 11:56:45 -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:178970 Archived-At: severity 40821 wishlist thanks > From: Clément Pit-Claudel > Date: Fri, 24 Apr 2020 11:56:45 -0400 > > All three overlays begin at the same point. Currently, it seems that margin specs are concatenated in order of increasing priority. This is likely due to before-strings being concatenated in that order? The strings are not concatenated, they are displayed one after another, in the order they are processed by the display engine. The overlays at a given buffer position are indeed sorted. First, before-strings should come before after-strings, and within each class the overlays are sorted in the order of increasing priority. Then the sorted overlays are processed one by one in the sorted order. > 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? > Additionally, unlike fringe bitmaps, for which the highest-priority bitmap replaces all others on the same line, there doesn't seem to be a way for higher-priority margin specs to replace lower-priority ones. First, I don't understand what you say about fringe bitmaps: I don't think there's any priority associated with those bitmaps, or what am I missing? 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. > This issue came up when trying to develop a mode to indicate errors and warnings in the margins (instead of drawing symbols in the fringes). Currently, if a line contains errors and warnings, Flycheck will place multiple overlays on the same line, and the fringe bitmap corresponding to the highest-priority one will be displayed. But if we put a symbol in the margins instead of the fringes, the symbols won't override each others: instead, they will be concatenated, often in the wrong order (as shown in the attached screenshot). A simple way of overcoming this problem is to define the overlay priorities in the reverse order of the Flycheck's error/warning priorities. A better solution would be to make the margin wider as needed, something that should be easy enough (line-number-mode did that, for example).