From: Eli Zaretskii <eliz@gnu.org>
To: Jordan Ellis Coppard <jc+o.emacs@wz.ht>,
Richard Hansen <rhansen@rhansen.org>,
Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 73332@debbugs.gnu.org
Subject: bug#73332: 31.0.50; Whitespace-mode breaking font-locking
Date: Thu, 19 Sep 2024 12:46:33 +0300 [thread overview]
Message-ID: <86y13o7z7q.fsf@gnu.org> (raw)
In-Reply-To: <9e04c81c-d95f-434f-aae7-6b65664bc479@wz.ht> (bug-gnu-emacs@gnu.org)
> Date: Wed, 18 Sep 2024 21:44:53 +0900
> From: Jordan Ellis Coppard via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Starting from `emacs -Q`:
>
> With whitespace-mode enabled (no other configuration at all) in an Elisp
> buffer (or any other I've tested such as Org) the last character at the
> end of the buffer has all fontification removed (confirmed with
> describe-char) while typing and said character stays un-fontified until
> the buffer is re-formatted (say by killing it and re-opening, or by
> having whitespace cleanup occur).
>
> Whitespace-mode should not be stripping all fontification of the last
> character in a buffer while typing.
>
> Open Emacs, create an Elisp buffer, enable whitespace-mode, and type a
> comment (easiest to visualise): `;; Foo bar baz`. Notice as you type
> this comment the last character has no fontification until a subsequent
> one is typed or the aforementioned buffer re-formatting occurs.
Thank you for your report.
Richard, could you please look into this?
There are at least two problems here, AFAICT. First, whitespace-mode
does not refontify the character at EOB when there's no newline at EOB
and you move point to or from EOB. This can be fixed by the patch
below; any comments to it?
The other problem is with fontification of the last character in the
buffer when point is at EOB: the foreground color is removed from the
last character, but the font-lock face for it is not restored. If I
go to that character and invoke describe-text-properties, I see that
it has the 'face' property of nil, and I think that's the reason. The
nil value comes from this part of whitespace-font-lock-keywords:
,@(when (memq 'missing-newline-at-eof whitespace-active-style)
;; Show missing newline.
`(("[^\n]\\'" 0
;; Don't mark the end of the buffer is point is there --
;; it probably means that the user is typing something
;; at the end of the buffer.
(and (/= whitespace-point (point-max))
'whitespace-missing-newline-at-eof)
t)))
That 'and' expression yields nil when point is at EOB.
Stefan, is there a way of avoiding this effect, perhaps by using a
function in whitespace-font-lock-keywords?
This missing-newline-at-eof feature is new in Emacs 30, so I'd like to
fix it on the emacs-30 release branch.
Here's the patch that fixes the refontification of the last character
when there's no newline at EOB:
diff --git a/lisp/whitespace.el b/lisp/whitespace.el
index 28d131b..d1b1f84 100644
--- a/lisp/whitespace.el
+++ b/lisp/whitespace.el
@@ -2333,10 +2333,22 @@ whitespace-post-command-hook
(font-lock-flush whitespace-eob-marker (1+ (buffer-size)))))
(setq-local whitespace-buffer-changed nil)
(setq whitespace-point (point)) ; current point position
- (let ((refontify (and (eolp) ; It is at end of line ...
- ;; ... with trailing SPACE or TAB
- (or (memq (preceding-char) '(?\s ?\t)))
- (line-beginning-position)))
+ (let ((refontify (or (and (eolp) ; It is at end of line ...
+ ;; ... with trailing SPACE or TAB
+ (or (memq (preceding-char) '(?\s ?\t)))
+ (line-beginning-position))
+ (and (memq 'missing-newline-at-eof
+ ;; If user requested to highlight
+ ;; EOB without a newline...
+ whitespace-active-style)
+ ;; ...and the buffer is not empty...
+ (not (= (point-min) (point-max)))
+ (= (point-max) (without-restriction (point-max)))
+ ;; ...and no newline at EOB...
+ (not (eq (char-before (point-max)) ?\n))
+ ;; ...then refontify the last character in
+ ;; the buffer
+ (max (1- (point-max)) (point-min)))))
(ostart (overlay-start whitespace-point--used)))
(cond
((not refontify)
next prev parent reply other threads:[~2024-09-19 9:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-18 12:44 bug#73332: 31.0.50; Whitespace-mode breaking font-locking Jordan Ellis Coppard via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-19 9:46 ` Eli Zaretskii [this message]
2024-09-19 15:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-21 10:49 ` Eli Zaretskii
2024-09-21 14:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y13o7z7q.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=73332@debbugs.gnu.org \
--cc=jc+o.emacs@wz.ht \
--cc=monnier@iro.umontreal.ca \
--cc=rhansen@rhansen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.