> I've also implemented a "@publication" command in texinfo.tex, that
> should contain information about the publisher and any other details
> specific to the act of publication. [...]
This looks nice, thank you.
Werner
> I edited the documentation slightly. It should be covered by the
> sentence, "Menu comment lines and any empty lines are kept in the
> output."
Thanks, this looks good.
Werner
>> Ouch! I simply searched for the string 'footer' in the Texinfo
>> info pages and I got no hit. I now see that the description of
>> `WORDS_IN_PAGE` is in the 'Customization of Navigation and Headers'
>> section (as it should be), which I missed.
>
> You could also have checked the indices w
>> Both are OK to me. However, what I have a problem with are cases
>> where too much empty vertical space remains, which could be easily
>> filled with a chapter entry and four lower-level entries, say.
>
> I've made a change changing this dimension down to 30pt.
Thanks.
> I know you said yo
>> OK, so please document this. Looking at section `Writing a menu`
>> in the Texinfo info file (of current git) I don't see anything
>> about HTML output of `@menu` blocks and how it is formatted (and
>> the description of `FORMAT_MENU` doesn't mention this either).
>
> In general, we do not d
>> Maybe you can provide a list of the most important CSS changes, or
>> maybe add a section that describes how to do the transition to
>> Texinfo 7.0 and newer?
>
> Here is what is in tta/TODO (which is more notes than TODO). We
> have not formally described that in the Texinfo manual because we
>> Comparing the HTML of version 6.8 with version 7.2, I see that many
>> classes got new names. This means that we essentially have to
>> rewrite our custom CSS file, which is not fun.
>>
>> What about providing a script
>>
>> ```
>> texinfo-css-update --from 6.8 --to 7.2 < infile > outfile
>> ``
Hello Patrice and Gavin,
thanks for your answers.
>> Why ``? I consider this surprising since the item description
>> of a menu entry (i.e., the third part of an entry) is not output
>> with ``.
>
> The idea was that the users may have wanted to have the end lines
> and spaces to be signific
>> What must I do to always get a navigation panel in the footer
>> (i.e., `NODE_FOOTER_BUTTONS`)?
>
> texi2any --html -c FORMAT_MENU=menu -c WORDS_IN_PAGE=0 test.texi
>
> The setting of FORMAT_MENU is immaterial.
Thanks!
> This question has been asked so many times before that I wonder if
>
Comparing the HTML of version 6.8 with version 7.2, I see that many
classes got new names. This means that we essentially have to rewrite
our custom CSS file, which is not fun.
What about providing a script
```
texinfo-css-update --from 6.8 --to 7.2 < infile > outfile
```
that does the job, r
[texi2any 6.8, 7.2]
Consider the following example file `menu.texinfo`.
```
\input texinfo
@node Top
@top Top
@menu
* Foo:: Foo foo foo.
* Bar:: Bar bar bar.
@end menu
@node Foo
@chapter Foo
Foo
@node Bar
@chapter Bar
Baz
@bye
```
If I process this with
```
texi2any --html -c FORMAT_M
[texi2any 7.2]
Consider the following example file `menu.texinfo`.
```
\input texinfo
@node Top
@top Top
@menu
* Foo:: Foo foo foo.
XXX @var{yyy} ZZZ
* Bar:: Bar bar bar.
@end menu
@node Foo
@chapter Foo
Foo
@node Bar
@chapter Bar
Baz
@bye
```
If I process this with
```
texi2any -
>> Thanks, this helps: for my version of the LilyPond Notation
>> Reference a value of 10pt works just fine. Before that I tried
>> 20pt, however, I got a different but equally bad gap as reported
>> originally. This makes me wonder whether we are we really turning
>> the right screw...
>
> I tr
>> While playing around with adding parts to LilyPond's Notation
>> Reference, I got the attached layout in the ToC. As can be seen,
>> there is a vertical gap corresponding to approx. 8 lines(!) at the
>> bottom of page vi; I've never noticed such a large gap before in any
>> Texinfo document. [
>> I played around a bit more, and I think it looks good if the
>> vertical space right before the part entry gets increased a bit,
>> see attached image.
>
> I think it will be safest to keep the same size for the text,
> and just to use increased spacing before the part line to separate
> it v
> Since `@part` is outside of the sectioning hierarchy I suggest to
> not indent it at all, see the second attached image; doing so has
> the additional bonus that it sticks out more prominently – right
> now, because it uses the same font and size as ToC entries for
> `@chapter`, it can be easily
> While playing around with adding parts to LilyPond's Notation
> Reference, I got the attached layout in the ToC. As can be seen,
> there is a vertical gap corresponding to approx. 8 lines(!) at the
> bottom of page vi; I've never noticed such a large gap before in any
> Texinfo document.
>
> I
Right now, `@part` in the ToC is typeset with an empty box for the
sectioning number. This doesn't look correctly formatted if there are
more than 9 chapters, see the attached image.
Since `@part` is outside of the sectioning hierarchy I suggest to not
indent it at all, see the second attached i
> I have tested that with texi2any 6.8, the following invocation:
>
> ../tp/texi2any.pl --html -c TREE_TRANSFORMATIONS=complete_tree_nodes_menus
> -c FORMAT_MENU=menu menu.texinfo
This works.
Thanks a lot for the answers, Patrice and Gavin!
Werner
Folks,
for technical reasons we use `texi2any` version 6.8 in LilyPond, not
wanting to upgrade to version 7.2 right now. There is a difference in
behaviour regarding automatically generated `@menu` blocks, and I
wonder whether it is possible to achieve the desired result with some
extra code or
>> [...] However, as can be seen in the luatex output, the use of
>> `\nolig` to suppress ligatures (commit 0f849a41145) no longer
>> works.
>
> It appears I got the \ifluatex conditional back to front. It should
> be fixed now.
Thanks for the quick fix, it works.
Werner
[texinfo.tex 2025-03-02.20]
Please consider the following input, which uses U+2019 four times in a
row in the first line.
```
\input texinfo
c
c@quoteright@kern 0pt @quoteright@kern 0pt @quoteright@kern 0pt @quoteright
@bye
```
Attached is the output of both pdftex and luatex (using bin
>> > ... 'menu_no_detailmenu' sounds good to me.
>>
>> Sounds good to me too.
>
> I will implement then. It will apply to Info output too.
+1, and thanks.
Werner
>> I was just bitten by the undocumented feature that `texi2any`
>> generates a `@detailmenu` block if it auto-generates menus, and the
>> top-level menu of a document is not present.
>
> Is it an issue for you for Info or HTML output format?
HTML.
> In Info, it seems to me that a @detailmenu
I was just bitten by the undocumented feature that `texi2any`
generates a `@detailmenu` block if it auto-generates menus, and the
top-level menu of a document is not present.
Please make this controllable. For example, an empty
```
@detailmenu
@end detailmenu
```
block at the top-level could
> A target is an anchor, where it is placed. Maybe @identifier could
> be better than @label?
If this is what people like most then I suggest to use `@id`, which is
shorter. (I'm not really happy with the name, though, but I can't
explain why this is so :-)
Werner
>> > So, this is not different if a @node is before an @XXXheading, it
>> > may appear in an explicit node direction and in another @node
>> > menu.
>>
>> Well, the behaviour of `@node` in a split HTML document is to start
>> a new file. However, this is exactly what I would like to avoid.
>
> O
>> Ah, ok. Then `@label` should be indeed avoided. I would still
>> like to have a snappy command name, maybe `@mark` or `@tag`?
>
> 2. "Label" as the anchor name:
>
> @label Bows
> @heading Bögen
>
> Here there would be an anchor created called "Bows". @xref{Bows}
> would
>> Yes, exactly – in HTML split mode, `@anchorlabel` (or `@label`,
>> which I won't stop advertising :-) plus `@XXXheading` should be on
>> the same page as the last `@node` command.
>
> @label could be ok for the command, but it could be confusing as
> there is a \label command in LaTeX [...]
Ah
> I propose that, if USE_NEXT_HEADING_FOR_LONE_NODE is set, the
> @*heading appearing after a @node be treated as much as possible
> like a sectioning command.
What about HTML split mode?
Werner
[folding answers to two e-mails into one]
>> Because in Info a `@node` always needs a `@menu` entry, AFAIK,
>> which is inconsistent with the `@XXXheading` behaviour.
>
> The @node directions and @menu entries, if explicit, are, in
> principle, fully independent from sectioning commands such as
>> Well, I think that your `@anchorlabel` suggestion is the way to go.
>> Actually, I would prefer a shorter name, say, `@label`. Then you
>> can demote
>>
>> ```
>> @node Foo
>> @subsection Foo doodle doo
>> ```
>>
>> to
>>
>> ```
>> @label Foo
>> @subsubheading Foo doodle doo
>> ```
>
> I st
>> > But do you really want to get the old sectioning name back for
>> > printed output?
>>
>> Yes, because using `@anchor` would be the result of demoting, say,
>> `@subsection` to `@subsubheading`.
>
> It seems to me that this specific use case would benefit even more
> from another options, wh
> I do not like the automatic association of an inline command like
> @anchor, that may happen anywhere, to another command. I think that
> it would be cleaner to have an @-command with two arguments,
> instead, like
>
> @anchorlabel Bows, Bögen
>
> A comma in the anchor part would need to be e
> Your proposal from a few days ago of using a @*heading command
> appears relevant. We could use a command like
> "@xrefanchorlabelisheading" (hard to get a descriptive, short name).
>
> So with input like:
>
> @heading Bögen
> @anchor{Bows}
>
> Then @ref{Bows} would produce "Bögen", etc.
>
>> * For translators, having the same anchor name as in the original
>> document helps a lot in translation. And vice versa, it helps
>> maintainers who don't speak the particular language to still do
>> various maintenance tasks easier.
>
> I do not think that this is such a good reason t
>> Rationale: The `@node` command is tightly bound with a section
>> command like `@chapter`; this gets reflected by the command
>> `@xrefautomaticsectiontitle`, which makes `@xref` and friends
>> actually print the sectioning title instead of the node name.
>>
>> For the `@anchor` command, howeve
>> And Japanese people are probably even offended because, as it
>> currently happens, almost all Japanese characters are represented
>> with Chinese syllables...
>
> I didn't appreciate the point you were making initially and thought
> you were making some joke about the origin of the Japanese
Folks,
I suggest to add a second, optional argument to `@anchor` that gives
the default printed label.
Rationale: The `@node` command is tightly bound with a section command
like `@chapter`; this gets reflected by the command
`@xrefautomaticsectiontitle`, which makes `@xref` and friends actual
>> And Japanese people are probably even offended because, as it
>> currently happens, almost all Japanese characters are represented
>> with Chinese syllables...
>
> In addition to --no-transliterate-file-names, it is also possible to
> set the customization variable USE_UNIDECODE to 0, [...]
>> Alas, this fails with `@xrefautomaticsectiontitle on` and non-ASCII
>> characters. Attached is an example that worked with `texinfo.tex`
>> version 2025-01-31.21, and which now yields
>>
>> ```
>> ./ref.texinfo:19: Missing @endcsname inserted.
>
> It should be fixed now.
It is, thanks!
>> My initial recalling was that the transliteration in file name was
>> Karl demand. [...]
>
> It makes sense for Ukrainian or other non-Latin alphabet languages
> but not so much for French or German, in my opinion.
>
> German speakers tend to protest, in my experience, if the umlauts
> are d
[texinfo.tex 2025-02-06.22]
> Yes, it was a bug. I've committed a fix in version 2025-02-06.22,
> and rethought how the space trimming works for macro arguments and
> hopefully made the implementation in texinfo.tex a bit simpler.
> Thanks for the report.
Thanks for the quick fix!
> > > This
> To handle such cases, texi2any offers the
> --transliterate-file-names command line option. [...]
>
> This is the default.
Well, it is customary to always show the opposite option of the
default in the `--help` screen. For file name transliteration,
however, this is not the case: Th
>> 'o' is definitely *not* the NFC of 'ö'! AFAICS, the above warning
>> message points to a bug in `texi2any`.
>
> Not the part about the regular rules, but about transliteration for file
> names:
>
> To handle such cases, texi2any offers the
> --transliterate-file-names command line o
>> [texinfo.tex 2025-02-03.17]
>> [texi2any 7.2]
>>
>> ```
>> bogen.texinfo:17: warning: @anchor `Bögen' file Bogen.html for redirection
>> exists
>> bogen.texinfo:10: warning: conflict with @anchor `Bogen' redirection file
>> ```
>>
>> And indeed, a redirection file for 'Bögen' is missing, AFA
>> Interestingly, the translated strings were there from the very
>> beginning (i.e., since 2016) – I guess this has worked then, and
>> later on Texinfo was modified somehow, and updating the PO file was
>> forgotten.
>
> I would be quite surprised that this worked with texi2any since the
> 5.0 r
[texinfo.tex 2025-02-03.17]
[texi2any 7.2]
Consider the following input file `bogen.texinfo`. The German word
'Bögen' is the plural of 'Bogen' – in music, this is 'slur'
vs. 'slurs'.
```
\input texinfo
@node Top
@top Top
top
@node Foo
@chapter Foo
@anchor{Bogen}Bogen
@page
@node Bar
@chapt
While processing LilyPond documentation in Catalan I noticed that I
get messages like
```
translation 1 error(s)
translated string: Inici del cap@'@dotless{i}tol actual o previ
Error messages:
@' expected braces
translation 1 error(s)
translated string: Cap@'@dotless{i}tol seg@"uent
Error messag
[texinfo.tex 2025-02-03.17]
> We should document that node names should not contain @macro-defined
> macros, and texi2any could give a warning if a document does this.
Yes, please do.
> One possibility is to expand to the entire @node line instead, as in:
>
> @macro Node {name}
> @node \n
> The reason, AFAICS, is that user-defined macros are not immediately
> expanded while writing an entry to the `.toc` file. Is there a
> reason for it?
Note that it works just fine if I use `@set` and `@value` for the
purpose shown in the file, and this is probably even a better solution
for th
[texinfo.tex 2025-02-03.17]
> Please consider the attached example.
Oops, here is the right example.
Werner
\input texinfo
@macro A
urgh
@end macro
@contents
@node Top
@top Top
Top
@unmacro A
@macro A
foo
@end macro
@node @A{}
@chapter @A{}
@A{}
@page
@unmacro A
@macro A
bar
Please consider the attached example. It works as expected if
processed with `texi2any`. However, the output of `texi2pdf` is
incorrect, producing a bad ToC.
The reason, AFAICS, is that user-defined macros are not immediately
expanded while writing an entry to the `.toc` file. Is there a reaso
> I see this was previously discussed, although I don't remember this:
Me neither :-) However, the older discussion is slightly different.
Werner
> The problem with changing the output for a cross-reference to
> anchors is that some manuals may be depending on the existing
> output, with the anchor names used in HTML output. So I think we
> should change the output in DVI/PDF instead to match the current
> HTML output, and use the anchor
>> > It should be possible to fix this by outputting the combining accent
>> > character, but this will take me time to implement.
>>
>> OK, looking forward to that :-)
>
> It should be done in version 2025-01-31.21.
It works fine with LilyPond's documentation, thanks!
Werner
>> > The --internal-links=file.txt should do what you want to, I
>> > believe, it is only available for HTML. Or you can set the
>> > INTERNAL_LINKS customization variable.
>>
>> Thanks, but this isn't what I need, since (a) it adds the section
>> number to the argument of `@node`,
>
> I think
>> I'm searching a way to make `texi2any` dump all cross-reference
>> targets (i.e., the arguments of `@node` and `@anchor`) to a file
>> for a given document, for example, by adding some code to a file
>> loaded via `--init-file`. How can I achieve that?
>
> The --internal-links=file.txt shoul
Folks,
I'm searching a way to make `texi2any` dump all cross-reference
targets (i.e., the arguments of `@node` and `@anchor`) to a file for a
given document, for example, by adding some code to a file loaded via
`--init-file`. How can I achieve that?
Werner
> Apologies, this was due to \endlink actually being defined *twice*
> for XeTeX and the second definition was the one that was actually
> used. I've committed a fix (version 2025-01-30.16).
Thanks.
Werner
[texinfo.tex 2025-01-29.23]
> The reason is the way that the translation is given in the
> translation file, (txi-tr.tex), which uses the accent commands:
>
> \gdef\putwordTOC{\dotaccent{I}\,cindekiler}
>
> If I change this to use UTF-8 instead, the outline is produced
> correctly with the acc
Below is a detailed reply to Eli, but while writing this I found out
what I *really* want :-)
Please make *all* heading commands – including `@XXXheading` – control
the default print label of `@xref` in the PDF if
`@xrefautomaticsectiontitle` is active. This would make my suggestion
of an option
Folks,
I suggest to add an option that controls whether `@anchor` honors
`@xrefautomaticsectiontitle on`.
Right now, if `@xrefautomaticsectiontitle` is active and I have
```
@node A
@chapter A
... many pages ...
@anchor{This is a meaningful anchor label}
```
and I reference this with
```
@
[texinfo.tex 2025-01-20.21]
Consider the following example file `tr.texi`.
```
\input texinfo
@documentlanguage tr
@tracingall
@tracingonline0
@contents
@node A
@chapter A
A
@page
@bye
```
If compiled with pdfTeX or LuaTeX this shows 'Icinderkiler' in the PDF
outline. However, IIUC, the c
> I have committed changes to add an entry for the table of contents,
It works just fine, thanks a lot!
Werner
>> Could we change the referent index to the last one, rather than the
>> first, as Werner mentioned it may often be more appropriate:
>>
>> Assuming that a large document has multiple indices, the most
>> general index is normally the last one, not the first.
>>
>> I don't know how true th
>> So: can this be fixed on the side of `texinfo.tex` at least for the
>> space character, circumventing the luatex bug for the most common
>> case?
>
> I have minimal understanding of lua and luatex. I've edited
> texinfo.tex in the obvious way: [...]
>
> Is there any testing you can do of this t
>> > I prefer to allow this kind of customization, especially for
>> > functionality that is of a wide interest, through options or
>> > variables, rather than the customization API, as the former would
>> > be easier for users and also less likely to break.
>>
>> It is always better indeed. Bu
> Find attached a possible init file doing what you want. I have
> hardcoded the selected printindex.
Thanks a lot for the code! If I ever need this I know where to
look :-)
Werner
Please have a look at
https://bugs.ghostscript.com/show_bug.cgi?id=708234
and the thread on the 'luatex' mailing list starting with
https://tug.org/pipermail/luatex/2025-January/008035.html
which discusses the problem that luatex creates invalid PDF outlines.
While some PDF viewers like `e
[texinfo 7.2]
The documentation in the 'Direction' section of 'texi2any_api' says
_Index_
The first output unit with ‘@printindex’.
This is not ideal. Assuming that a large document has multiple
indices, the most general index is normally the last one, not the
first. Sometimes, howe
> I'm inclined not to do it for the title page, but do it for the
> contents.
Sounds good, thanks.
Werner
>> The new feature seems to work just fine, thanks!
>
> That's great thanks for testing.
A minor thing: I miss an entry in the outlines for the ToC itself. Is
this intentional? Or maybe even an entry for the very first page of
the document...
Werner
> It is also possible that this is a GhostScript bug: to get
> smaller-sized output PDFs, LilyPond creates the more than thousand
> included PDF images without embedded fonts, and GhostScript does the
> font embedding as a post-processing step (doing so shrinks the PDF
> size from about 40MByte t
>> I would really like to test it, however, I've just found out that
>> appendices B and higher don't appear at all in the PDF outline (see
>> attached image). Looks like a bug...
>
> I don't know why that would be as I didn't get anything like that in
> my testing with various input files. It
>> Another solution might be to do what Adobe does in its PDF
>> reference, which also comes with an excessively large index; see
>> attached image.
>
> I've finally implemented this commit 6b9163b2b4f (today). It does
> not work perfectly if the index is under a @section rather than an
> @appen
>> I ask to implement the same for the PDF format (and probably for
>> Info, too) to help with very large indices – for example,
>> LilyPond's main index has a length of almost 30 pages.
>
> [...] PDF readers also have search commands, so I'm not sure what
> exactly is missing here.
Well, a big
The HTML version of a Texinfo index has the nice feature of displaying
a 'Jump to' line so that a user can quickly navigate to the starting
letter of an index entry.
I ask to implement the same for the PDF format (and probably for Info,
too) to help with very large indices – for example, LilyPond
> I have made this change in commit 5661fc4c01b (today). (It was not
> as hard as I expected as I just bypassed the code in \pdfgettoks,
> which is kind of a black box to me.)
Thanks!
> I'm afraid this is really not possible at the moment. A single
> index entry could even have multiple page nu
[texinfo.tex 2024-11-01.22]
> Thanks for the quick fix!
Unfortunately, your fix is buggy; it swallows the space after the
quotation mark.
```
\input texinfo
c’’ a
@bye
```
Werner
>> Trying out this new feature – which is great! – I have to agree
>> with Bruno: That I get two different positions depending on whether
>> I click on the title or on the page number is unexpected (and I
>> haven't seen such a feature in other PDF documents, as far as I can
>> remember). Can you
> I found the following in the LuaTeX manual:
>
> See chapter 5 for many small changes related to paragraph
> building, language handling and hyphenation. The most important
> change is that adding a brace group in the middle of a word (like
> in of{}fice) does not prevent ligature creatio
>> So we now encourage not to use @documentencoding at all if it's UTF-8?
>
> Indeed.
It doesn't sound to my ears that the manual 'encourages' to not tag a
file with `@documentencoding`. However, it is no longer necessary
since more than five years.
Werner
> Shouldn't you use @documentencoding if you include UTF-8 encoded
> characters verbatim? (I have no idea if that affects the problem.)
UTF-8 is meanwhile the default encoding.
Werner
Consider this input file (the second line uses U+2019).
```
\input texinfo
c
c
@bye
```
If processed with pdftex (or xetex), everything's fine. In the first
line, gets resolved into two closing double quotes via TeX's
input ligature mechanism, as expected. In the second line, t
>> And what about the page number itself? As a user, I would expect
>> that clicking on the the entry text and clicking on the page number
>> at the right of it bring me to the same position.
>
> I had thought about the page number, but it is not a big deal, as
> most users will be clicking on the
> The patch below hangs TeX, for some reason.
Interesting.
> I have committed a change to put \prime in superscript, which is
> what ' is supposed to do in plain TeX.
Thanks!
Werner
[texinfo.tex version 2024-10-28.18]
If I try the following small example
```
\input texinfo.tex
All pitches from G to c.
@bye
```
I get the attached result, which is bad. What about applying the
trivial patch below?
Werner
> This was reported some time ago and this warning has been removed in
> the current code.
Ah, excellent, thanks!
Werner
> It was already fixed in Texinfo 7.1.1, released 2024-09-07:
>
> * texi2any
> . do not complain about presence of @anchor inside @item in a table
>
> Previously discussed:
>
> https://lists.gnu.org/archive/html/help-texinfo/2023-11/msg2.html
Thanks. I've missed the discussion then.
W
>> why are `@anchor` and friends discouraged on an `@item` line?
>> AFAICS, the reason for this restriction is not documented in the
>> manual, and it seems to work just fine...
>
> Do you have a specific output showing it discouraged? And if yes,
> with which version of GNU Texinfo?
This is wi
Folks,
why are `@anchor` and friends discouraged on an `@item` line? AFAICS,
the reason for this restriction is not documented in the manual, and
it seems to work just fine...
Werner
> I agree that it is a potential use case that makes using the Texinfo
> file modification time to set the time incorrect. Another similar
> case is if a user wants to set the modification date because of a
> change in texi2any EPUB conversion in the published work.
>
> However, I still do not
>> I suggest
>>
>> ```
>> '@asis' needs braces here; say '@itemize @asis{}'.
>> ```
>
> I do not like much that option, because we do not have any idea why
> the user ended up using '@itemize @asis'. Maybe with @asis, it will
> be in general the case that @asis{} is correct, but with other
> @
> Here is another proposal, which seems much clearer to me, but is
> probably too long:
> @itemize command argument with omitted braces should not require an
> argument, but @asis does. Use braces for @asis
I suggest
```
'@asis' needs braces here; say '@itemize @asis{}'.
```
IMHO it is not
>> (Note that "cmp" is documented not to work with "use locale" for UTF-8
>> strings: [...]
>
> Thanks. This is very confusing to me, then, as it is not told that way
> in perllocale, especially the section: [...]
Perhaps Bruno Haible can help?
Werner
>>You can undefine a macro FOO with ‘@unmacro FOO’. It is not an
>>error to undefine a macro that is already undefined. For
>>example:
>>
>> @unmacro foo
>>
>> However, this doesn't work.
>
> I don't know if this is a regression as the code for this error
> message existed as fa
>> An alternative is not to have such a variable but just to have an
>> option to collate according to the user's locale. Then the user
>> would run e.g. "LC_COLLATE=ll_LL.UTF-8 texi2any ..." to use
>> collation from the ll_LL.UTF-8 locale. They would have to have the
>> locale installed that
In the texinfo manual of version 7.1 I can find the following about
`@unmacro`:
You can undefine a macro FOO with ‘@unmacro FOO’. It is not an
error to undefine a macro that is already undefined. For example:
@unmacro foo
However, this doesn't work. This input document
``` u.te
> Nobody is arguing for "codepoint-order" sorting,
OK, I obviously misunderstood, thanks for the clarification.
Werner
1 - 100 of 591 matches
Mail list logo
