From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@jurta.org>
Cc: ruediger@c-plusplus.de, 16439@debbugs.gnu.org, sva-news@mygooglest.com
Subject: bug#16439: [feature request] Highlighting of strings within Info buffers
Date: Mon, 20 Jan 2014 10:06:13 -0800 (PST) [thread overview]
Message-ID: <d85cebb8-ef34-49f9-811a-c4dde888bf19@default> (raw)
In-Reply-To: <874n4z3tb7.fsf@mail.jurta.org>
> The problem is how to highlight strings only in code samples
> because in other places highlighting "..." makes no sense.
> Look for example in the node (info "(emacs) Package Keywords"):
>
> Most optional features in Emacs are grouped into "packages".
>
> Should "packages" be highlighted as a string. Of course not.
> There is no additional emphasis on quotations in books.
1. That is not "the problem", IMO. When I proposed this feature,
long ago, the complaints (against even providing it optionally,
via a user option) were that the highlighting is not foolproof,
in that there are some cases where ` or " is not matched (e.g.,
?").
For that, I tested each node of the Emacs and Elisp manuals (at
the time), and I showed that that problem is very rare. And
making the highlighting optional and togglable, deals quite well
with that rarity - just hit a key in any of the very few nodes
where the highlighting is problematic, to get rid of it. Or
turn the option off in your init file if you really prefer what
Emacs does now (no such highlighting).
2. Wrt the "problem" you bring up now -
Sorry, I don't agree. I've used this feature for decades now,
and I can assure you that it is very helpful to have all "..."
highlighted. Just my opinion, obviously.
It is also possible to separate the control over highlighting of
`...' and "...", e.g., by either having different user options
or giving the option more possible values. I have not done that
in `info+.el', as I have not see the need for it. (However, I
do have separate options for `...' and "...", on the one hand,
and <...>, on the other.)
3. More importantly, I'm hoping that Emacs will at some point
(soon) move to supporting different quoting methods for
semantically different constructs, as was discussed in this bug
thread: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16292.
I did not bring this up in that thread, because it had already
been decided what to do in the immediate, but there are some
very different uses of "..." in the Elisp and Emacs manuals.
And here I am with you to some extent: "..." to represent a
string is different in meaning from "..." to represent, say,
the introduction of a glossary term (in-place term definition),
which is yet again different from actual quotation (citation),
such as the FSF's Back-Cover Text.
Strings should be represented using straight " quotes, as
is done currently. Actual quotations (citations) should be
represented using curly double-quotes. And glossary terms
should be represented using either curly double-quotes or
another typographical convention (bold or italic is often
used for this, but it could also be a different color or
other convention).
If we do ever represent these different things in different
ways, instead of the single "..." notation, then your
problem will disappear.
4. During the one or two days that curly single-quotes were
actually used in Emacs, during the discussion of bug #16292,
I adjusted `info+.el' to DTRT for that, and it worked very
well. Unfortunately, the builds for that did not also affect
double-quotes, so there was no test for that. But taking
care of that in `info+.el' would be trivial also.
I'm not knowledgable about TexInfo etc., but I would guess
that the changes to support different appearances for what
are now handled as "..." would also be straightforward.
That is, I would expect that "..." as strings or as
term definitions might already be handled differently at
the TexInfo level, and are just being mapped to the same
Info representation, "...". Just a guess.
I see no obstacle to providing helpful highlighting to
Emacs such as is provided by `info+.el', except the will
of Emacs Dev.
FWIW, `info+.el' also highlights <...> (controlled by a
separate user option). Thus keys represented using this
syntax are highlighted the same as other keys.
5. Note, BTW, that there is no real difference between
"..." and `...' wrt "the problem" you cite. Look at the
`Top' node of the Emacs manual, for example, and you will
see this:
This is the `GNU Emacs Manual', updated for
That use of `...' is semantically different from its use in
`forward-char' or `C-x 4 f' or `.emacs'.
prev parent reply other threads:[~2014-01-20 18:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 10:15 bug#16439: [feature request] Highlighting of strings within Info buffers Sebastien Vauban
2014-01-14 14:34 ` Rüdiger Sonderfeld
2014-01-14 20:05 ` Drew Adams
2014-01-20 9:18 ` Juri Linkov
2014-01-20 14:10 ` Stefan Monnier
2020-09-18 14:03 ` Lars Ingebrigtsen
2014-01-20 15:17 ` Eli Zaretskii
2014-01-21 7:54 ` Juri Linkov
2014-01-21 15:53 ` Eli Zaretskii
2014-01-22 8:09 ` Juri Linkov
2014-01-22 15:42 ` Eli Zaretskii
2014-01-20 18:06 ` Drew Adams [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d85cebb8-ef34-49f9-811a-c4dde888bf19@default \
--to=drew.adams@oracle.com \
--cc=16439@debbugs.gnu.org \
--cc=juri@jurta.org \
--cc=ruediger@c-plusplus.de \
--cc=sva-news@mygooglest.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 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).