unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: Indentation conventions for Info manuals; recognizing code
Date: Sun, 07 Mar 2021 08:33:37 +0200	[thread overview]
Message-ID: <83pn0btqv2.fsf@gnu.org> (raw)
In-Reply-To: <SA2PR10MB4474CB7322BEDE862DD42BBFF3949@SA2PR10MB4474.namprd10.prod.outlook.com> (message from Drew Adams on Sun, 7 Mar 2021 01:58:43 +0000)

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 7 Mar 2021 01:58:43 +0000
> 
> I don't know what conventions/styles are defined for our Info manuals, if there are any.  Is that documented somewhere?

It's documented in the Texinfo manual.

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

> But other manuals don't seem to use the same indentation.  Several (org, eintr, ccmode, efaq(-w32),...) indent code (including Elisp) 5 spaces - which is the same amount that other, non-code text is indented.
> 
> (There are also lines in the Emacs manual and ccmode represent user input or program output.  Those too are indented only 5 chars, so they won't appear in fixed-pitch font.)
> 
> And if a code block is indented only 5 chars, but some of its lines are indented at least 10 chars, then this optional fontifying kicks in for those latter lines - not great, obviously.
> 
> The CC-Mode manual is somewhat like the Elisp manual - it too indents many code blocks 10 chars, but others are indented 5 chars.
> 
> Ccmode also has some bullets that are, themselves, indented under indented paragraphs.  (Why is the bullet itself indented wrt the preceding paragraph?  Same thing for numbered lists - why indent the number itself?)

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.

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

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



  reply	other threads:[~2021-03-07  6:33 UTC|newest]

Thread overview: 10+ 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 [this message]
2021-03-08  3:47   ` [External] : " Drew Adams
2021-03-08  5:49     ` 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

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=83pn0btqv2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=drew.adams@oracle.com \
    --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).