bug#34022: 26.1; Region highlight has lower priority than flymake overlays

[João Távora]

Johann Klähn <johann@jklaehn.de> writes:

> thanks for your quick response! I did not see
> `flymake-overlay-control' because I was still using the version of
> flymake shipped with Emacs 26.1. (I really like the options introduced
> with the new version allows, so I will probably switch to using it.)

Flymake is now also distributed through ELPA, so you can use the most
recent version even on Emacs 26.1

> ‖ ‘priority’
> ‖      This property’s value determines the priority of the overlay.  If
> ‖      you want to specify a priority value, use either ‘nil’ (or zero),
> ‖      or a positive integer.  Any other value has undefined behavior.
> ‖      [...]
> ‖      Note that Emacs sometimes uses non-numeric priority values for some
> ‖      of its internal overlays, so do not try to do arithmetic on the
> ‖      priority of an overlay (unless it is one that you created).  In
> ‖      particular, the overlay used for showing the region uses a priority
> ‖      value of the form ‘(PRIMARY . SECONDARY)’, where the PRIMARY value
> ‖      is used as described above, and SECONDARY is the fallback value
> ‖      used when PRIMARY and the nesting considerations fail to resolve
> ‖      the precedence between overlays.  However, you are advised not to
> ‖      design Lisp programs based on this implementation detail; if you
> ‖      need to put overlays in priority order, use the SORTED argument of
> ‖      ‘overlays-at’.  *Note Finding Overlays::.
>
> Even though it's shipped with Emacs, flymake is probably not
> "internal" enough to use those?

Good point.  Don't know how to fix it then.

> ...looking around further I just found Bug#16192, where a similar
> problem was fixed for hl-line-mode by using a negative priority.  And
> then there is also Bug#15899, which discusses the use of overlays to
> highlight region in the first place.
>
I remember reading somewhere negative priorites were a nono, maybe that
has changed.

João