From: Alan Mackenzie <acm@muc.de>
To: Drew Adams <drew.adams@oracle.com>
Cc: 33913@debbugs.gnu.org
Subject: bug#33913: 26.1; Optionally not font-lock newline char when `comment-end' = ""
Date: 30 Dec 2018 11:51:25 -0000 [thread overview]
Message-ID: <20181230115125.44900.qmail@mail.muc.de> (raw)
In-Reply-To: <mailman.6534.1546123809.1284.bug-gnu-emacs@gnu.org>
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).
next prev parent reply other threads:[~2018-12-30 11:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
[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
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=20181230115125.44900.qmail@mail.muc.de \
--to=acm@muc.de \
--cc=33913@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/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.