unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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

* 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

* 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).