* bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
@ 2020-06-30 13:08 Vasilij Schneidermann
2020-06-30 16:32 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Vasilij Schneidermann @ 2020-06-30 13:08 UTC (permalink / raw)
To: 42138
[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]
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))
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
2020-06-30 13:08 bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el Vasilij Schneidermann
@ 2020-06-30 16:32 ` Eli Zaretskii
2020-07-20 6:59 ` Vasilij Schneidermann
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2020-06-30 16:32 UTC (permalink / raw)
To: Vasilij Schneidermann; +Cc: 42138
> Date: Tue, 30 Jun 2020 15:08:22 +0200
> From: Vasilij Schneidermann <mail@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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
2020-06-30 16:32 ` Eli Zaretskii
@ 2020-07-20 6:59 ` Vasilij Schneidermann
2020-07-20 14:40 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Vasilij Schneidermann @ 2020-07-20 6:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 42138
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
> 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`.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
2020-07-20 6:59 ` Vasilij Schneidermann
@ 2020-07-20 14:40 ` Eli Zaretskii
2020-07-25 21:37 ` Vasilij Schneidermann
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2020-07-20 14:40 UTC (permalink / raw)
To: Vasilij Schneidermann; +Cc: 42138
> Date: Mon, 20 Jul 2020 08:59:31 +0200
> From: Vasilij Schneidermann <mail@vasilij.de>
> Cc: 42138@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
2020-07-20 14:40 ` Eli Zaretskii
@ 2020-07-25 21:37 ` Vasilij Schneidermann
2020-07-26 2:31 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Vasilij Schneidermann @ 2020-07-25 21:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 42138
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
> 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el
2020-07-25 21:37 ` Vasilij Schneidermann
@ 2020-07-26 2:31 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2020-07-26 2:31 UTC (permalink / raw)
To: Vasilij Schneidermann; +Cc: 42138-done
> Date: Sat, 25 Jul 2020 23:37:03 +0200
> From: Vasilij Schneidermann <mail@vasilij.de>
> Cc: 42138@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-07-26 2:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-30 13:08 bug#42138: 26.3; Incompatibility between font-lock-add-keywords and enriched.el Vasilij Schneidermann
2020-06-30 16:32 ` Eli Zaretskii
2020-07-20 6:59 ` Vasilij Schneidermann
2020-07-20 14:40 ` Eli Zaretskii
2020-07-25 21:37 ` Vasilij Schneidermann
2020-07-26 2:31 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).