GNU bug report logs - #66041
30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'?

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: jporterbugs <at> gmail.com, 66041 <at> debbugs.gnu.org
Subject: bug#66041: 30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'?
Date: Mon, 25 Sep 2023 17:19:00 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Mon, 25 Sep 2023 14:52:07 +0100
> Cc: jporterbugs <at> gmail.com, 66041 <at> debbugs.gnu.org
> 
> > Does this explain what happens?
> 
> Yes, it does.  Although I would expect that when two overlays
> that compete for the same resource (in this case, the
> same  portion of the left fringe) the overlay with the highest
> priority would win that competition -- not the "last one".

There's no built-in mechanism for the display engine to do that, and
the fact that overlays are processed one by one in the order they are
encountered doesn't help: when processing an overlay the display
engine has no idea there are other overlays in the same screen line
that will "compete" for the fringe display.

> Since I can't change the start and end positions of the overlays,
> (because they do quite a bit more than specify a 'before-string
> property), I can't choose which overlay is the "last one".  So I
> guess this bug is very hard to solve until the "last one wins"
> behaviour your describe is changed.

The 'display' property can have the form

  (when CONDITION . SPEC)

where SPEC is your (left-fringe exclamation-mark compilation-warning)
spec, and CONDITION is evaluated by the display engine and must be
non-nil for SPEC to have effect.  The ELisp manual says:

     You can make any display specification conditional.  To do that,
  package it in another list of the form ‘(when CONDITION . SPEC)’.  Then
  the specification SPEC applies only when CONDITION evaluates to a
  non-‘nil’ value.  During the evaluation, ‘object’ is bound to the string
  or buffer having the conditional ‘display’ property.  ‘position’ and
  ‘buffer-position’ are bound to the position within ‘object’ and the
  buffer position where the ‘display’ property was found, respectively.
  Both positions can be different when ‘object’ is a string.

     Note that CONDITION will only be evaluated when redisplay examines
  the text where this display spec is located, so this feature is best
  suited for conditions that are relatively stable, i.e. yield, for each
  particular buffer position, the same results on every evaluation.  If
  the results change for the same text location, e.g., if the result
  depends on the position of point, then the conditional specification
  might not do what you want, because redisplay examines only those parts
  of buffer text where it has reasons to assume that something changed
  since the last display cycle.

Did you try using that here?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.