From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Indentation conventions for Info manuals; recognizing code
Date: Mon, 8 Mar 2021 03:47:38 +0000 [thread overview]
Message-ID: <SA2PR10MB44744D32B0AC35A4C9380F7FF3939@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83pn0btqv2.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]
> > Given only an Info buffer, i.e., not Texinfo source code but its output
> that's used by Emacs users, is there a convention wrt indentation of, say
> code blocks? Or is there some other way (e.g. a text property) to recognize
> code or similar text that really deserves a fixed-pitch font?
>
> No, I don't think so. Not from examining the indentation, anyway.
> You could try some heuristics to detect code from the contents,
> perhaps.
I don't see any possible heuristics. It could be
any kind of code. And not just code. Shell input
and output, ASCII art,... Really anything that it
makes sense to put in a fixed-pitch font. The kind
of thing that usually gets something like an HTML
<code> tag.
> I think it's hopeless to rely on indentation for such a feature. As
> you discovered, the indentation can vary if the code block is inside
> some other "environment", like a table (this is what causes
> multi-level indentation in CC Mode manual). Moreover, there's a
> (rarely used) Texinfo directive that changes the default indentation
> of a code block, even if it is not nested inside some other indented
> text. If, for example, such a directive is used in the ELisp manual,
> it will immediately ruin the results for your feature.
Yeah, I've discovered as much.
> > I know that the use of Texinfo output (what ends up as Info buffer text) is
> wider than just Emacs Info. But is there, at the Texinfo level at least,
> some semantic markup that distinguishes something like code?
>
> Yes, the @example, @smallexample, @lisp, and @smallisp are such
> markup in Texinfo.
Is what `makeinfo' produces for them for Info
hard-coded, or can it be modified in some ways?
Or even if hard-coded, is it possible for the
resulting Info text to be somehow distinguished
as such - e.g., as we get '...' in the Info text,
resulting from some Texinfo @ construct? (I
don't have a Texinfo or `makeinfo' manual.)
I don't see any way to recognize this in the Info
output we currently get, but is there perhaps
some way to get some indication there, e.g., to
define what Info output `makeinfo' produces for
something like @example or @lisp?
> > If there is, could that info be maintained - transferred to Info buffers in
> some way, or does the translation just have to be lossy in this way?
>
> The conversion to Info is performed by 'makeinfo', a program that is
> part of the Texinfo package. Its output must be mostly plain text,
> and the format of that file must be understood by the various Info
> readers out there. So if some kind of "code" marker would be retained
> in the Info output, it would need to be implemented in the 2 or 3
> other Info readers out there, not just in Emacs. The chances of such
> a change in the Info output format, just for the sake of some fancy
> display in a single Emacs-related package sound small -- but you need
> to talk about this with the Texinfo developers, not with us.
Too bad the translation has to be lossy. The
effect of showing <code>-like stuff is helpful
(and is common in technical doc).
And something will be needed if we ever hope to
allow for variable-pitch text for most regular
text while using fixed-pitch for places it makes
sense (e.g. code).
With the `...' quoting there's no problem
recognizing (most) code (and key) bits embedded
in ordinary text, and using a fixed-pitch font
on the former.
I don't suppose it's feasible to have another
such construct to indicate the equivalent of
<code>...</code>? We already have some Texinfo
markup or whatever that gets converted to '...'.
Is there some existing Texinfo construct that
could be leveraged for @lisp etc.?
See attached screenshots, for an idea of the
usefulness. They're the same node - the only
difference is toggling minor mode
`Info-variable-pitch-text-mode'.
[-- Attachment #2: throw-emacs-Info-code-block.png --]
[-- Type: image/png, Size: 95468 bytes --]
[-- Attachment #3: throw-emacs-Info-var-pitch+code-block.png --]
[-- Type: image/png, Size: 95836 bytes --]
next prev parent reply other threads:[~2021-03-08 3:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-07 1:58 Indentation conventions for Info manuals; recognizing code Drew Adams
2021-03-07 6:33 ` Eli Zaretskii
2021-03-08 3:47 ` Drew Adams [this message]
2021-03-08 5:49 ` [External] : " Yuri Khan
2021-03-08 14:07 ` Eli Zaretskii
2021-03-08 15:33 ` Drew Adams
2021-03-08 5:37 ` Richard Stallman
2021-03-08 13:57 ` Eli Zaretskii
2021-03-08 15:33 ` [External] : " Drew Adams
-- strict thread matches above, loose matches on Subject: below --
2021-03-08 9:51 tydrdn
2021-03-08 15:33 ` [External] : " Drew Adams
2021-03-26 5:12 ` scame
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=SA2PR10MB44744D32B0AC35A4C9380F7FF3939@SA2PR10MB4474.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.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 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).