GNU bug report logs - #42138
26.3; Incompatibility between font-lock-add-keywords and enriched.el

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42138 in the body.
You can then email your comments to 42138 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vasilij Schneidermann <mail <at> vasilij.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
Date: Tue, 30 Jun 2020 15:08:22 +0200

[Message part 1 (text/plain, inline)]

After opening enriched.txt and running any kind of code using the
`font-lock-add-keywords` function (for example whitespace-mode or
hl-todo-mode), the enriched highlighting is gone.  Is this a bug or
intentional?  If it's intentional, is there some way for the code using
`font-lock-add-keywords` to detect this condition, other than checking
for the presence of enriched-mode?  Alternatively, is there a
recommended way to add highlighting of keywords that's compatible with
enriched-mode?


In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
 of 2020-05-19 built on felixonmars2
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description:	Arch Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Enriched: decoding document...
Indenting...
Note: file is write protected
Whitespace mode enabled in current buffer
You can run the command ‘whitespace-mode’ with M-x whit-m RET
Whitespace mode enabled in current buffer

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-wide-int
 --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_MESSAGES: 
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  whitespace-mode: t
  enriched-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  use-hard-newlines: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils whitespace disp-table
enriched elec-pair time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 101223 9021)
 (symbols 48 20550 1)
 (miscs 40 62 154)
 (strings 32 29069 1125)
 (string-bytes 1 778480)
 (vectors 16 14213)
 (vector-slots 8 506032 11338)
 (floats 8 49 68)
 (intervals 56 902 0)
 (buffers 992 12))

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 42138 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vasilij Schneidermann <mail <at> vasilij.de>
Cc: 42138 <at> debbugs.gnu.org
Subject: Re: bug#42138: 26.3;
 Incompatibility between font-lock-add-keywords and enriched.el
Date: Tue, 30 Jun 2020 19:32:48 +0300

> Date: Tue, 30 Jun 2020 15:08:22 +0200
> From: Vasilij Schneidermann <mail <at> vasilij.de>
> 
> After opening enriched.txt and running any kind of code using the
> `font-lock-add-keywords` function (for example whitespace-mode or
> hl-todo-mode), the enriched highlighting is gone.  Is this a bug or
> intentional?  If it's intentional, is there some way for the code using
> `font-lock-add-keywords` to detect this condition, other than checking
> for the presence of enriched-mode?

I think enriched-mode, like any other mode that puts its own faces on
chunks of text by means other than font-lock, is fundamentally
incompatible with font-lock.  It's basically the same problem as if
you tried to use put-text-property in *scratch* to put some face
property on some text in the buffer: the face won't show until you
turn off font-lock.  That's because the first thing font-lock does is
wipe out all the faces in the buffer.

> Alternatively, is there a recommended way to add highlighting of
> keywords that's compatible with enriched-mode?

Any way that uses put-text-property, add-text-properties, etc. without
using font-lock will do.  You can even try that manually via the
facemenu-set-* commands (or via the Edit->Text Properties menu from
the menu bar).

Message #11 received at 42138 <at> debbugs.gnu.org (full text, mbox):

From: Vasilij Schneidermann <mail <at> vasilij.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 42138 <at> debbugs.gnu.org
Subject: Re: bug#42138: 26.3; Incompatibility between font-lock-add-keywords
 and enriched.el
Date: Mon, 20 Jul 2020 08:59:31 +0200

[Message part 1 (text/plain, inline)]

> I think enriched-mode, like any other mode that puts its own faces on
> chunks of text by means other than font-lock, is fundamentally
> incompatible with font-lock.  It's basically the same problem as if
> you tried to use put-text-property in *scratch* to put some face
> property on some text in the buffer: the face won't show until you
> turn off font-lock.  That's because the first thing font-lock does is
> wipe out all the faces in the buffer.

Thanks for the clarification.  This doesn't really help me though, I want to
adjust my existing font-lock using code so that it detects when it would wipe
out said text properties enriched-mode set up.  It doesn't appear to be
sufficient to just check whether `font-lock-mode` is non-nil, if I do that
inside the example enriched.txt file, it's set to `t` for some reason.  Again,
what would the correct check be here?

> Any way that uses put-text-property, add-text-properties, etc. without
> using font-lock will do.  You can even try that manually via the
> facemenu-set-* commands (or via the Edit->Text Properties menu from
> the menu bar).

Hm, I've done that for non-font-lock scenarios before, but in this case I
really need font-lock's ability to search for strings and apply fontification
to them, so this isn't really an option.  Looking for other examples in the
Emacs sources I've found uses of `jit-lock-register`.

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 42138 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vasilij Schneidermann <mail <at> vasilij.de>
Cc: 42138 <at> debbugs.gnu.org
Subject: Re: bug#42138: 26.3; Incompatibility between font-lock-add-keywords
 and enriched.el
Date: Mon, 20 Jul 2020 17:40:16 +0300

> Date: Mon, 20 Jul 2020 08:59:31 +0200
> From: Vasilij Schneidermann <mail <at> vasilij.de>
> Cc: 42138 <at> debbugs.gnu.org
> 
> > I think enriched-mode, like any other mode that puts its own faces on
> > chunks of text by means other than font-lock, is fundamentally
> > incompatible with font-lock.  It's basically the same problem as if
> > you tried to use put-text-property in *scratch* to put some face
> > property on some text in the buffer: the face won't show until you
> > turn off font-lock.  That's because the first thing font-lock does is
> > wipe out all the faces in the buffer.
> 
> Thanks for the clarification.  This doesn't really help me though, I want to
> adjust my existing font-lock using code so that it detects when it would wipe
> out said text properties enriched-mode set up.  It doesn't appear to be
> sufficient to just check whether `font-lock-mode` is non-nil, if I do that
> inside the example enriched.txt file, it's set to `t` for some reason.  Again,
> what would the correct check be here?

I think you want to look at font-lock-defaults.

> > Any way that uses put-text-property, add-text-properties, etc. without
> > using font-lock will do.  You can even try that manually via the
> > facemenu-set-* commands (or via the Edit->Text Properties menu from
> > the menu bar).
> 
> Hm, I've done that for non-font-lock scenarios before, but in this case I
> really need font-lock's ability to search for strings and apply fontification
> to them, so this isn't really an option.  Looking for other examples in the
> Emacs sources I've found uses of `jit-lock-register`.

Ah, I guess I  misunderstood what kind of solutions you are looking
for, sorry.

If you want to keep font-lock in effect, then indeed jit-lock-register
is one feature to look at.  But there are two others:
font-lock-extra-managed-props and the font-lock-face property.  I hope
one of these will allow you to come up with a solution.

Message #17 received at 42138 <at> debbugs.gnu.org (full text, mbox):

From: Vasilij Schneidermann <mail <at> vasilij.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 42138 <at> debbugs.gnu.org
Subject: Re: bug#42138: 26.3; Incompatibility between font-lock-add-keywords
 and enriched.el
Date: Sat, 25 Jul 2020 23:37:03 +0200

[Message part 1 (text/plain, inline)]

> I think you want to look at font-lock-defaults.

Thanks, checking for that did the trick.  I've fixed my own mode and someone
else's that way.

> If you want to keep font-lock in effect, then indeed jit-lock-register is one
> feature to look at.  But there are two others: font-lock-extra-managed-props
> and the font-lock-face property.  I hope one of these will allow you to come
> up with a solution.

That would be better, but considerably harder.  For now I'm happy with checking
`font-lock-defaults`.  Feel free to close this bug report.

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 42138-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vasilij Schneidermann <mail <at> vasilij.de>
Cc: 42138-done <at> debbugs.gnu.org
Subject: Re: bug#42138: 26.3; Incompatibility between font-lock-add-keywords
 and enriched.el
Date: Sun, 26 Jul 2020 05:31:37 +0300

> Date: Sat, 25 Jul 2020 23:37:03 +0200
> From: Vasilij Schneidermann <mail <at> vasilij.de>
> Cc: 42138 <at> debbugs.gnu.org
> 
> That would be better, but considerably harder.  For now I'm happy with checking
> `font-lock-defaults`.  Feel free to close this bug report.

Done.

Previous Next

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