From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel 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 13:21:13 -0400 Message-ID: <949b79b9-0009-6f36-7d6d-8be895d2cf19@gmail.com> References: <33007735-30b9-4c52-c440-929686e1cb0e@gmail.com> <83o8rg809k.fsf@gnu.org> <5da7af4f-0f8c-c79c-38d7-ed7465d9b34d@gmail.com> <83sggr7jbf.fsf@gnu.org> <84be9f87-15ac-f501-13ba-5ce0372332ac@gmail.com> <83imhn7at9.fsf@gnu.org> 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="88503"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: 40821@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 25 19:22:14 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 1jSOVJ-000MwR-TU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 19:22:14 +0200 Original-Received: from localhost ([::1]:41546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSOVI-0000Tb-RN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 13:22:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41846) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSOVA-0000RF-Ve for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 13:22:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSOV9-0001up-1t for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 13:22:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSOV8-0001rc-KG for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 13:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSOV8-0008En-Eh for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 13:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 17:22: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.158783528331617 (code B ref 40821); Sat, 25 Apr 2020 17:22:02 +0000 Original-Received: (at 40821) by debbugs.gnu.org; 25 Apr 2020 17:21:23 +0000 Original-Received: from localhost ([127.0.0.1]:60280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOUU-0008Dt-Nv for submit@debbugs.gnu.org; Sat, 25 Apr 2020 13:21:22 -0400 Original-Received: from mail-qt1-f182.google.com ([209.85.160.182]:36762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOUS-0008Dg-R0 for 40821@debbugs.gnu.org; Sat, 25 Apr 2020 13:21:21 -0400 Original-Received: by mail-qt1-f182.google.com with SMTP id w29so10736305qtv.3 for <40821@debbugs.gnu.org>; Sat, 25 Apr 2020 10:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=y1L/iK3ZBMhqmbKT04OTlVgC6+gNkEzAnsOD8jQU9QQ=; b=ULnraPFLAG9vgu8czArlqHgc+xy2c6sEO+ow8uamzv8xfMlfZ/0iuNGOUf6tu7/wqq fPyKzATDdQkOpkACiSdgJDwsHYrxecA/mCetwCZL4w3ZkXostPStU+Xl+y8jz47ZHPQ9 TD0L+qNddAPVovndRmv5TLLkm9/e61H8ZlwHEUG4ZHpFQzRRFbYYdVCDfMKL0L0aT70C YuVhuKAK6i7itIplvhR2ktqQv05GLHcCS3CV3pw3R67Zv19WwPJ4DkcMZi9IcaGvQkX2 ziNiOfP1IYaIbXB3u+AY8dHie+f9i7l8i02G1HiGEQgyxAxH3Zr9X3NHt3rfgcic1T6N tnHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=y1L/iK3ZBMhqmbKT04OTlVgC6+gNkEzAnsOD8jQU9QQ=; b=rwZ2InjzXAJhHEFYkn+uuLnNhRKDyWkT8hOvyzGQF2hBcuGlWNtaAz9iku7JUVP14M 76G8GBTinyGVXiN+1HIOBricRQzPmDNhP7QnShnCdiVClNzctyCf0xg49R07Hzwlsaz7 ELoNpmTCXanqKH/GRjOuGFc35j4CyxIg4Tvq+cbRq3glLoPxCn+1L113GTxf3YWUBJ6D BBJtvpuRj95eJnp3hc8op7PxIZtl7lHXhmXkOM0jl7UX03EyVMW83EJA5nTdsFH3yC0B G1UopwkPBWBrCQNrJnIVyWgw3KrLeLgw2zpJxYfP7R+Dcq3+FLhUiPKPmSCJvF/CexQe pZAg== X-Gm-Message-State: AGi0PuZR/YEqxaIEqX71fLLL8L9X6vcdlT8MLA79COeRVmTlVvRWUW5q JoLr5RdlckeSrXodkKRZz4ip+6QMA0k= X-Google-Smtp-Source: APiQypLPCQ7DpaglhHBFFpBaoO9yeaOzhWWd2SSbIbG9+gJhNpDMM5XP94nFDxeFaOpwLfWko+0tGg== X-Received: by 2002:ac8:6f66:: with SMTP id u6mr15195887qtv.201.1587835275022; Sat, 25 Apr 2020 10:21:15 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.googlemail.com with ESMTPSA id s14sm6487264qts.70.2020.04.25.10.21.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 10:21:14 -0700 (PDT) In-Reply-To: <83imhn7at9.fsf@gnu.org> Content-Language: en-GB 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:179017 Archived-At: On 25/04/2020 13.08, Eli Zaretskii wrote: >> Cc: 40821@debbugs.gnu.org >> From: Clément Pit-Claudel >> Date: Sat, 25 Apr 2020 12:51:52 -0400 >> >> On 25/04/2020 10.04, Eli Zaretskii wrote: >>>> I only want/need to display one margin indicator — the highest priority one :) >>> >>> Then why not have your code do that? >> >> It's quite complicated: every time I add a new overlay (they arrive asynchronously, not all at once), I need to check for others on the same line and adjust the symbols. Every time the text is changed, I need to rescan the current line and adjust the overlay properties. > > Yes, but is it reasonable to ask the display engine to figure that out > for you? You are talking about something that is clearly application > logic; other applications might want some other logic to have other > overlays "win". I think it is reasonable: we already have a notion of overlays "winning", namely their priority. >>>> 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 is: the buffer shows the face of one overlay and the icon of another one. > > As expected: faces are merged, but fringe bitmaps aren't. Yes, which is the outlandish part :) >>>> 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. >> >> The margin specs are displayed in order of decreasing priority, as far as I can tell: first the one coming from the overlay with the lowest priority, then the next one, etc. > > What you described is actually the order of _increasing_ priority. Or > am I confused? Of, yes, you're completely right; sorry for mixing up the terms. I meant to say that, if highest-priority overlays were displayed first in the margin, then on narrow margins specs from high-priority overlays would take precedence.