* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
@ 2018-12-29 22:39 Drew Adams
[not found] ` <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org>
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Drew Adams @ 2018-12-29 22:39 UTC (permalink / raw)
To: 33913
See https://emacs.stackexchange.com/q/46808/105.
Please consider letting users easily (e.g. user option) not highlight a
newline character when it ends a comment, such as in Lisp.
The effect should be to highlight only the chars of the line, starting
with `comment-start', up to but not including the newline char.
(I never would have noticed how annoying the default behavior is if I hadn't tried putting a background color on comments, as the OP did. I don't even think it should be the default behavior to highlight the newline char.)
In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
of 2018-05-30
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor `Microsoft Corp.', version 10.0.16299
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
^ permalink raw reply [flat|nested] 8+ messages in thread[parent not found: <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org>]
* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
[not found] ` <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org>
@ 2018-12-30 11:51 ` Alan Mackenzie
0 siblings, 0 replies; 8+ messages in thread
From: Alan Mackenzie @ 2018-12-30 11:51 UTC (permalink / raw)
To: Drew Adams; +Cc: 33913
Hello, Drew.
In article <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org> you wrote:
> See https://emacs.stackexchange.com/q/46808/105.
> Please consider letting users easily (e.g. user option) not highlight a
> newline character when it ends a comment, such as in Lisp.
OK, let's consider it. The comment delimiters in Emacs are considered
part of the comment, and fontified with it. In fact, I believe they get
font-lock-comment-delimiter-face.
It is open to the user to customize f-l-comment-delimiter-face not to
inherit from f-l-comment-face, but instead to have a neutral effect.
> The effect should be to highlight only the chars of the line, starting
> with `comment-start', up to but not including the newline char.
So the starting and stopping delimiters of a comment should get different
faces. Hmmm. Why?
One way to get this would be to introduce
font-lock-comment-terminator-face, inheriting by default from one of the
two existing comment faces.
> (I never would have noticed how annoying the default behavior is if I
> hadn't tried putting a background color on comments, as the OP did. I
> don't even think it should be the default behavior to highlight the
> newline char.)
If the OP doesn't want the terminators fontified, why does he want the
comment openers fontified? This seems a bit inconsistent. I mean, if a
string's being fontified, you'd want either both of the "s (as Emacs
does) or neither of them (XEmacs) to get string face. Why are comments
different?
> In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
> of 2018-05-30
> Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
> Windowing system distributor `Microsoft Corp.', version 10.0.16299
> Configured using:
> `configure --without-dbus --host=x86_64-w64-mingw32
> --without-compress-install 'CFLAGS=-O2 -static -g3''
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <mailman.6551.1546170751.1284.bug-gnu-emacs@gnu.org>]
* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
[not found] ` <mailman.6551.1546170751.1284.bug-gnu-emacs@gnu.org>
@ 2018-12-30 12:33 ` Alan Mackenzie
2018-12-30 17:21 ` Drew Adams
0 siblings, 1 reply; 8+ messages in thread
From: Alan Mackenzie @ 2018-12-30 12:33 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 33913
Hello, Drew.
In article <mailman.6551.1546170751.1284.bug-gnu-emacs@gnu.org> you wrote:
> In article <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org> you wrote:
>> See https://emacs.stackexchange.com/q/46808/105.
>> Please consider letting users easily (e.g. user option) not highlight a
>> newline character when it ends a comment, such as in Lisp.
> OK, let's consider it. The comment delimiters in Emacs are considered
> part of the comment, and fontified with it. In fact, I believe they get
> font-lock-comment-delimiter-face.
Apologies, I was wrong, here. When the terminator is \n, comment-end is
"", not "\n", and things get confused. comment-end is NOT and NEVER WAS
the comment terminator. It's merely what gets inserted when you type
M-;. I don't think there is a variable which holds the comment
terminator; there is merely an entry in the mode's syntax table.
The rest of my post was largely speculation, and was also wrong. Please
ignore it.
[ .... ]
>> In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
>> of 2018-05-30
>> Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
>> Windowing system distributor `Microsoft Corp.', version 10.0.16299
>> Configured using:
>> `configure --without-dbus --host=x86_64-w64-mingw32
>> --without-compress-install 'CFLAGS=-O2 -static -g3''
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
2018-12-30 12:33 ` Alan Mackenzie
@ 2018-12-30 17:21 ` Drew Adams
0 siblings, 0 replies; 8+ messages in thread
From: Drew Adams @ 2018-12-30 17:21 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 33913
> Apologies, I was wrong, here. When the terminator is \n, comment-end is
> "", not "\n", and things get confused. comment-end is NOT and NEVER WAS
> the comment terminator. It's merely what gets inserted when you type
> M-;. I don't think there is a variable which holds the comment
> terminator; there is merely an entry in the mode's syntax table.
>
> The rest of my post was largely speculation, and was also wrong. Please
> ignore it.
Hi Alan. No problem, and thanks for having looked into this.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
2018-12-29 22:39 bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = "" Drew Adams
[not found] ` <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org>
[not found] ` <mailman.6551.1546170751.1284.bug-gnu-emacs@gnu.org>
@ 2018-12-30 17:46 ` martin rudalics
2018-12-30 18:23 ` Drew Adams
2019-10-30 19:20 ` Lars Ingebrigtsen
3 siblings, 1 reply; 8+ messages in thread
From: martin rudalics @ 2018-12-30 17:46 UTC (permalink / raw)
To: Drew Adams, 33913
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
> Please consider letting users easily (e.g. user option) not highlight a
> newline character when it ends a comment, such as in Lisp.
>
> The effect should be to highlight only the chars of the line, starting
> with `comment-start', up to but not including the newline char.
For my private solution to this problem look at the attached file.
> (I never would have noticed how annoying the default behavior is if
> I hadn't tried putting a background color on comments, as the OP
> did. I don't even think it should be the default behavior to
> highlight the newline char.)
Fully agreed.
martin
[-- Attachment #2: font-lock-fontify-syntactically-region.el --]
[-- Type: application/emacs-lisp, Size: 1395 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
2018-12-30 17:46 ` martin rudalics
@ 2018-12-30 18:23 ` Drew Adams
2018-12-30 19:00 ` martin rudalics
0 siblings, 1 reply; 8+ messages in thread
From: Drew Adams @ 2018-12-30 18:23 UTC (permalink / raw)
To: martin rudalics, 33913
> > Please consider letting users easily (e.g. user option) not highlight a
> > newline character when it ends a comment, such as in Lisp.
> >
> > The effect should be to highlight only the chars of the line, starting
> > with `comment-start', up to but not including the newline char.
>
> For my private solution to this problem look at the attached file.
Maybe you could fix that up to become a
general replacement, to fix this bug (only)?
But I do think a user option might be good,
or even a non-option variable.
> > (I never would have noticed how annoying the default behavior is if
> > I hadn't tried putting a background color on comments, as the OP
> > did. I don't even think it should be the default behavior to
> > highlight the newline char.)
>
> Fully agreed.
I doubt that such an incompatible change (to
the default) would be accepted immediately.
But a fix for the bug might be.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
2018-12-30 18:23 ` Drew Adams
@ 2018-12-30 19:00 ` martin rudalics
0 siblings, 0 replies; 8+ messages in thread
From: martin rudalics @ 2018-12-30 19:00 UTC (permalink / raw)
To: Drew Adams, 33913
> Maybe you could fix that up to become a
> general replacement, to fix this bug (only)?
No. It's a hack to use fontification for that purpose.
> But I do think a user option might be good,
> or even a non-option variable.
This problem should be solved with the help of a new :no-extend-to-eol
face attribute. Whenever set - typically in 'font-lock-comment-face',
'font-lock-doc-face' and 'font-lock-string-face' - the display engine
would show the default background on the rest of the line. The idea
sounds deceptively simple but I never got around coding it.
> I doubt that such an incompatible change (to
> the default) would be accepted immediately.
> But a fix for the bug might be.
If it's made a face property, users are free to customize it at their
will. But I obviously wouldn't oppose an :extend-to-eol attribute.
martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
2018-12-29 22:39 bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = "" Drew Adams
` (2 preceding siblings ...)
2018-12-30 17:46 ` martin rudalics
@ 2019-10-30 19:20 ` Lars Ingebrigtsen
3 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-30 19:20 UTC (permalink / raw)
To: Drew Adams; +Cc: 33913
Drew Adams <drew.adams@oracle.com> writes:
> Please consider letting users easily (e.g. user option) not highlight a
> newline character when it ends a comment, such as in Lisp.
>
> The effect should be to highlight only the chars of the line, starting
> with `comment-start', up to but not including the newline char.
>
> (I never would have noticed how annoying the default behavior is if I
> hadn't tried putting a background color on comments, as the OP did. I
> don't even think it should be the default behavior to highlight the
> newline char.)
I agree that this would have been useful earlier, but Emacs now has
support for not extending faces to the end of the line when the newline
has a face, so this no longer seems pertinent, and I'm closing this bug
report. If others think that it's still worth doing something about,
please reopen.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-10-30 19:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-29 22:39 bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = "" Drew Adams
[not found] ` <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org>
2018-12-30 11:51 ` Alan Mackenzie
[not found] ` <mailman.6551.1546170751.1284.bug-gnu-emacs@gnu.org>
2018-12-30 12:33 ` Alan Mackenzie
2018-12-30 17:21 ` Drew Adams
2018-12-30 17:46 ` martin rudalics
2018-12-30 18:23 ` Drew Adams
2018-12-30 19:00 ` martin rudalics
2019-10-30 19:20 ` Lars Ingebrigtsen
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).