Re: @itemize @asis is not well supported

[Raymond Toy]

On Tue, Mar 12, 2024 at 11:40 AM Gavin Smith 
wrote:

> On Thu, Mar 07, 2024 at 09:49:24AM +0100, Patrice Dumas wrote:
> > On Wed, Mar 06, 2024 at 09:54:18PM +0100, Bruno Haible wrote:
> > > Gavin Smith wrote:
> > > > it is not worth changing and making practically every use of
> > > > @itemize in a Texinfo manual being flagged as incorrect, in my
> opinion.
> > >
> > > I agree. Counting the number of existing usages in Debian [1][2]:
> > >   - 8753 times '@itemize @bullet' without braces,
> > >   - 288 times '@itemize @bullet{}' with braces.
> >
> > I understand that it is the current practice, and I do not advocate
> > those uses to be flagged as incorrect.  I propose to change the
> > documentation such that this use is not proposed as a valid use anymore,
> > such that there are braces in future manuals, and also when people
> > change manuals they use braces.
>
> I think both should be documented as being valid.  I don't mind which one
> is presented as more normal.  I have edited the node in the documentation
> slightly.
>
> It would be ok to change the example to show "@itemize @bullet{}" instead
> of "@itemize @bullet" as long as the possibility of omitting the braces
> was still shown somewhere.  This might potentially make the documentation
> easier to read, as the discussion of braces could be given less prominence.
>

I haven't been following too closely, but I think the manual should only
have examples of recommended practice.  If @bullet{} is the recommended
way, then examples should only have that.  If the parser is lax and not
enforcing this, then that's ok.  Just don't confuse people that @bullet and
@bullet{} are both valid ways.  (Well, unless you are really saying both
are valid now and in the probable future, in which case, ignore me.)

-- 
Ray

Re: @itemize @asis is not well supported

[Raymond Toy]

On Mon, Mar 4, 2024 at 1:23 PM Patrice Dumas  wrote:

> On Mon, Mar 04, 2024 at 06:23:23PM +0100, Bruno Haible wrote:
> >
> > Yes, please. Since "make" only produces the info-formatted output by
> default,
> > without the warning, developers won't realize their mistake until the
> time
> > they run "make distcheck" (since "make distcheck" creates the dvi/ps/pdf
> > formatted documentation). It is better to get the developers' attention
> > already during "make".
>
> Ok, I propose as warning message :
>
>  "non-mark brace command `\@%s' as \@%s argument should have braces"
>
> leading to something like
>
>  non-mark brace command `@asis' as @itemize argument should have braces
>
> Any comments/proposals on the warning message?

As a casual user, I don't know what a non-mark brace command is, but the
message makes it pretty clear I need to write @asis{}.

> --
Ray

Re: Texinfo 7.0.90 pretest available

[Raymond Toy]

On 8/16/23 3:52 AM, Gavin Smith wrote:

A pretest distribution for the next Texinfo release (7.1) has been
uploaded to

https://alpha.gnu.org/gnu/texinfo/texinfo-7.0.90.tar.xz

In the upcoming release, the Texinfo language has been extended with a
new @link command for making unobtrusive hyperlinks.  In Info output, the
@nodedescription command allows for more thorough automatic generation of
node menus.  In HTML output, there is more support for automatic syntax
highlighting of computer code.  In PDF (and DVI) output with texinfo.tex,
the default has changed so that the  ` and ' characters in code samples
are output as the more usual asymmetric backquote and apostrophe glyphs,
rather than as directed quote marks.  This release also gives more
flexibility for making "definitions" like those made by built-in commands
like @deffn.

We make these pretests to help find any problems before we make an official
release to a larger audience, so that the release will be as good as it
can be.


I built from git and  used it to build some of the docs I (somewhat) 
regularly update.  Everything works fine, except a couple of issues with 
maxima's html user manual.  I think these are my fault now that texinfo 
doesn't produce directed quote marks.  I'll have to investigate.


The concept index looks fantastic since it indents the subentries very 
nicely.  So much easier to understand that it's a subentry. Thanks!


I haven't tried out any of the new features, though.  I  will look into 
using the new @defblock/@defline to see how it works with the weird 
Cmucl Hemlock manual that was converted from scribe.  More on that later.




Please send any feedback to bug-texinfo@gnu.org.

Here is the full news:

* Language
  . new generic definition commands, @defblock, @defline and @deftypeline,
for definitions without automatic index entries
  . new @linemacro facility eases use of generic definition commands
  . new command @link creates plain links (supported output formats only)
  . @cartouche takes an argument to specify the cartouche title
  . you can use the new commands @nodedescription and @nodedescriptionblock
to give text to be used in menu descriptions in Info and HTML output

* texi2any
  . @itemx at the beginning of a @table is now an error, not a warning
  . better validity checking of deeply nested commands
  . check that @set and @clear only appear at the start of a line
  . warn about missing menu entries even if CHECK_NORMAL_MENU_STRUCTURE is
not set.  you can turn this off by setting CHECK_MISSING_MENU_ENTRY to 0.
  . no longer use --enable-encoding and --disable-encoding to determine
whether to output encoded characters (instead of entities or commands)
for HTML, XML, DocBook and LaTeX; instead, use the value of the
OUTPUT_CHARACTERS customization variable.
  . stricter checks on input encoding, in particular more warnings and
errors with malformed UTF-8
  . support any input file encoding if support exists in the operating
system, not just a selected list of encodings
  . resolve an alias referring to another alias at definition time
  . internally, use "source marks" to keep all Texinfo source information that
is not in the final tree (location of macros, values and included files
expansion, @if* blocks, DEL comment, and @ protecting end of line on @def*
lines)
  . HTML output:
 . format @subentry and index entries with @seealso or @seeentry in a more
   similar way to printed output
 . output @shortcontents before @contents by default
 . omit colons after index entries by default.  this can still be
   configured with INDEX_ENTRY_COLON.
 . add @example syntax highlighting as a texi2any extension
 . no more capitalization of @sc argument in HTML Cross-references
 . change @point expansion to U+22C6 in HTML Cross-references
 . if a @node is not associated with a sectioning command but is
   followed by a heading command not usually associated to nodes
   such as @heading and this command appears before other formatted
   content, the heading command is assumed to supply the node heading.
   you can customize this with USE_NEXT_HEADING_FOR_LONE_NODE.
  . Info output:
 . new variable ASCII_DASHES_AND_QUOTES, on by default,
   outputs ASCII characters for literal quote or hyphen characters
   in source, rather than UTF-8.  this makes it easier to search
   Info files.
 . new ASCII_GLYPH variable for using ASCII renditions for glyph
   commands (like @bullet)
 . ASCII_PUNCTUATION still includes the effect of these new variables.
 . new variables AUTO_MENU_DESCRIPTION_ALIGN_COLUMN and AUTO_MENU_MAX_WIDTH
   control the format of descriptions in generated menus
  . XML output:
 . place menu leading text and menu separators in elements instead
   of attributes

* texi2dvi
  . macro expansion with texi2any requires at least version 5.0 (only
happens with --expand 

Re: ref macro works as expected for html and info, but not pdf?

[Raymond Toy]

On 8/5/23 8:16 AM, Gavin Smith wrote:

On Sat, Aug 05, 2023 at 08:07:31AM -0700, Raymond Toy wrote:

I have a set of simple macros:

|@macro kwd {keyword} @code{:\keyword\} @end macro @c Macro to generate a
cross-reference to a keyword. @macro keyref {arg} @xref{\arg\, @kwd{\arg\}}
@end macro |

And I use it like |@keyref{context-declarations}|. In the html doc, I see a
link with text “:context-declarations” in a fixed-width font. That’s what I
was expecting. In the info file, I also see “:context-declarations”, as
desired.

However, in the pdf, I only see “context-declarations” without the colon,
and the text appears to be the default serif font, and not a fixed-width
font.

Is this expected behavior?


The reason is that the second argument of @xref is not used for printed
cross-references, only the third argument.  The following uses the fixed-width
font (linebreaks fixed):


Oh, I'm terribly sorry!  I failed to make the distinction between online 
label and printed label.  This works nicely.


Sorry for the noise. (Trying to clean up some warnings in the manual.)

ref macro works as expected for html and info, but not pdf?

[Raymond Toy]

I have a set of simple macros:

|@macro kwd {keyword} @code{:\keyword\} @end macro @c Macro to generate 
a cross-reference to a keyword. @macro keyref {arg} @xref{\arg\, 
@kwd{\arg\}} @end macro |


And I use it like |@keyref{context-declarations}|. In the html doc, I 
see a link with text “:context-declarations” in a fixed-width font. 
That’s what I was expecting. In the info file, I also see 
“:context-declarations”, as desired.


However, in the pdf, I only see “context-declarations” without the 
colon, and the text appears to be the default serif font, and not a 
fixed-width font.


Is this expected behavior?

​

Re: Warning about ":" in @ref

[Raymond Toy]

On 8/4/23 11:47 PM, Patrice Dumas wrote:

On Fri, Aug 04, 2023 at 04:06:47PM -0700, Raymond Toy wrote:

With texinfo 7.0.2 (which comes with Fedora 38), I get warnings like:

|warning: @ref node name should not contain `:' |

The offending ref is “@ref{ext:encapsulate}”, and corresponding anchor is
“ext:encapsulate”. I didn’t see anything in the manual about this
constraint, but I didn’t look too hard. However, if there shouldn’t be a
colon in a @ref, shouldn’t there a corresponding warning if an anchor
contains a colon too?

There is no actual issue with anchors containing : in Info, only when
they are referred to.  Even in references, if the names are 'quoted',
which is the default with texi2any and the info reader supports the quotes
there is no issue.  I do not think that it is the way forward to add
warnings for such names.  The way forward would be to have the Emacs
Info reader modified to read the quoted nodes such that all the warnings
can be off in the default case.
Ah, so the issue is with certain info readers?  For this particular 
document, I don't think anyone actually uses the info version, even 
though it is created.  AFAIK, users either read the pdf or the html version.


In the "‘@node’ Line Requirements" node, this is explicit:

• Unfortunately, you cannot reliably use periods, commas, or colons
  within a node name; these can confuse some Info readers.
  ‘texi2any’ quotes problematic node names and labels by default, but
  some Info readers do not recognize this syntax.  Node name and
  label quoting causes ‘DEL’ characters (‘CTRL-?’, character number
  127, often rendered as ‘^?’) to appear around the name.  To remove
  node names and labels quoting, you can set the customization
  variable ‘INFO_SPECIAL_CHARS_QUOTE’ to ‘0’ (*note Other
  Customization Variables::).

  ‘texi2any’ warns about such problematic usage in node names, menu
  items, and cross-references.  If you don't want to see the
  warnings, you can set the customization variable
  ‘INFO_SPECIAL_CHARS_WARNING’ to ‘0’ (*note Other Customization
  Variables::).

Re: Warning about ":" in @ref

[Raymond Toy]

On 8/4/23 4:56 PM, Gavin Smith wrote:

On Fri, Aug 04, 2023 at 04:06:47PM -0700, Raymond Toy wrote:

With texinfo 7.0.2 (which comes with Fedora 38), I get warnings like:

|warning: @ref node name should not contain `:' |

The offending ref is “@ref{ext:encapsulate}”, and corresponding anchor is
“ext:encapsulate”. I didn’t see anything in the manual about this
constraint, but I didn’t look too hard. However, if there shouldn’t be a
colon in a @ref, shouldn’t there a corresponding warning if an anchor
contains a colon too?

 From (texinfo)Node Line Requirements:
 Unfortunately, you cannot reliably use periods, commas, or colons
 within a node name; these can confuse some Info readers.

 From (texinfo)@anchor:
Anchor names share the same constraints as nodes on the characters
 that can be included (*note Info Node Names Constraints::).
Thanks.  As I said, I didn't look too hard; I trusted the warning to be 
correct.


I guess an anchor with a problematic name only becomes a problem if you
actually link to it, but I've nothing against such warnings being added
in principle, if somebody wanted to do the work to do so.

Sorry, I'm illiterate in Perl. :-(




In the particular manual, there are lots of anchors that contain colons but
most of them are not referenced via @ref. (For whatever reason.)


How curious!
Yeah, I don't really know the history of this.   It's a document that 
was, possibly, in Scribe, that was later converted to latexinfo, then 
latex (using hevea to convert to html) and then finally texinfo.  It's 
possible that somewhere along the line,references to the anchors were 
dropped.  It was hard getting a supported tool to convert latex to html, 
so converting to texinfo seemed like the best way given that texinfo 
probably won't go away and does support html.   (Thanks!)

Warning about ":" in @ref

[Raymond Toy]

With texinfo 7.0.2 (which comes with Fedora 38), I get warnings like:

|warning: @ref node name should not contain `:' |

The offending ref is “@ref{ext:encapsulate}”, and corresponding anchor 
is “ext:encapsulate”. I didn’t see anything in the manual about this 
constraint, but I didn’t look too hard. However, if there shouldn’t be a 
colon in a @ref, shouldn’t there a corresponding warning if an anchor 
contains a colon too?


In the particular manual, there are lots of anchors that contain colons 
but most of them are not referenced via @ref. (For whatever reason.)


​

Re: toc multiline section titles misaligned in TeX

[Raymond Toy]

On 7/26/23 3:20 PM, Gavin Smith wrote:


On Wed, Jul 26, 2023 at 06:54:59PM +0100, Gavin Smith wrote:

I've committed a change for aligning the sections in a chapter only.
(version 2023-07-26.15).  I will do the other levels of sectioning soon.

Done now.

10 or more subsubsections in a subsection is rare, but there is a
case of it in the Emacs Lisp manual (see image).


This looks really nice!  The cmucl user manual 
 has more than 10 
subsections in a couple of sections and I never noticed this before.


​

Re: toc multiline section titles misaligned in TeX

[Raymond Toy]

On 7/16/23 1:52 PM, Karl Berry wrote:

In the toc, if a chapter/section/whatever titles breaks across lines,
the second line is not aligned with the first.  The output in the main
text is ok.  Example doc follows. I'll attach the output I get
with texinfo.tex [version 2023-07-02.10]. --thanks, karl.

\input texinfo
@contents

@node chap
@chapter Some very long chapter title with lots and lots and plenty of extra 
words to see where it breaks

@node sec
@section A very long section title with lots and lots and plenty of extra words 
to see where it breaks

@node subsec
@subsection A very long subsection title with lots and plenty of lots of extra 
words to see where it breaks

@bye

Interesting example.  I also noticed that the chapter title in the ToC 
has a line break way past the location of the page number. This is kind 
of weird.  The subsections look nice though (except for the 
aforementioned misalignement).

Re: Inconsistency in writing apostrophe in info and html output with version 7.0.3

[Raymond Toy]

On 6/5/23 10:50, Gavin Smith wrote:

On Mon, Jun 05, 2023 at 07:18:00AM -0700, Raymond Toy wrote:

Maxima grovels over the html file to find appropriate links to use for the
html version of the manual. This was working fine with 6.8 and earlier
because I found appropriate regexps to find the links.

This stopped working in 7.0.3 (and maybe earlier?). The regexps no longer
work. This is fine; there was no promise that the format of html links would
be consistent.

The problem I’m seeing is that in the texi source, we have:

|@vrindex Euler's number |

That apostrophe is really an apostrophe character, unicode U+27.

However, in the generated info file, the index has:

|* Euler’s number: Functions and Variables for Constants. |


We'd already addressed this problem for Info output:

https://lists.gnu.org/archive/html/bug-texinfo/2023-02/msg00048.html


The summary is that words with apostrophes, like "don't", should be
output in Info with an ASCII apostrophe so it is easy to search for these
words.

The end result of this was that we made the output for ' and `
in Texinfo, as well as hyphen characters, use ASCII characters
by default, with a new customiation variable to control this
(ASCII_DASHES_AND_QUOTES).  This will be included in the next Texinfo
release.
Didn't know how to use this, but it's in the new docs, so there was 
nothing for me to do to enable this.  This works great!  The two entries 
that were problems now use simple apostrophes.


Are you easily able to check this with the current Texinfo development
sources?

If you use Texinfo 7.0.3 then you could try setting OPEN_QUOTE_SYMBOL
or CLOSE_QUOTE_SYMBOL to ' (ASCII apostrophe) to turn this off.


In emacs , the apostrophe shows up as |\342\200\231|, which is
Right_Single_Quotation_Mark, unicode U+2019.

This is a problem because we use the info file as the source of truth, but
the HTML file only uses an apostrophe, so we end up with an entry that we
can find in the info file but not in the html file. This did not happen in
texinfo 6.8.

We should check the output in HTML for these constructs to check they
are what they should be.  Consistency with Info output sounds like a good
idea.  I hope to look into this issue soon.


Was this intentional? If so, are all apostrophes (U+27) converted to
right_single_quotation_mark (U+2019) in the info file? That’s something I
can deal with since it’s consistent.

I think so but it will change in future Texinfo releases.

Re: Inconsistency in writing apostrophe in info and html output with version 7.0.3

[Raymond Toy]

On 6/5/23 10:50, Gavin Smith wrote:


On Mon, Jun 05, 2023 at 07:18:00AM -0700, Raymond Toy wrote:

Maxima grovels over the html file to find appropriate links to use for the
html version of the manual. This was working fine with 6.8 and earlier
because I found appropriate regexps to find the links.

This stopped working in 7.0.3 (and maybe earlier?). The regexps no longer
work. This is fine; there was no promise that the format of html links would
be consistent.

The problem I’m seeing is that in the texi source, we have:

|@vrindex Euler's number |

That apostrophe is really an apostrophe character, unicode U+27.

However, in the generated info file, the index has:

|* Euler’s number: Functions and Variables for Constants. |


We'd already addressed this problem for Info output:

https://lists.gnu.org/archive/html/bug-texinfo/2023-02/msg00048.html


The summary is that words with apostrophes, like "don't", should be
output in Info with an ASCII apostrophe so it is easy to search for these
words.

The end result of this was that we made the output for ' and `
in Texinfo, as well as hyphen characters, use ASCII characters
by default, with a new customiation variable to control this
(ASCII_DASHES_AND_QUOTES).  This will be included in the next Texinfo
release.

Are you easily able to check this with the current Texinfo development
sources?

If you use Texinfo 7.0.3 then you could try setting OPEN_QUOTE_SYMBOL
or CLOSE_QUOTE_SYMBOL to ' (ASCII apostrophe) to turn this off.


I added |--set-customization-variable OPEN_QUOTE_SYMBOL=' 
--set-customization-variable CLOSE_QUOTE_SYMBOL='| to the invocation of 
makeinfo. This seemed to work. Kind of. We have:


|11 Maxima’s Database  * Menu: * Introduction to 
Maxima's Database:: |


That’s an actual apostrophe. However, I think maxima parses the info 
file using the section title:


|11.1 Introduction to Maxima’s Database |

and that’s U+2019, not an apostrophe (U+27).

This isn’t catastrophic. There appear to be only two places where this 
happens so I can just make a special case for them.


.

​

Re: Inconsistency in writing apostrophe in info and html output with version 7.0.3

[Raymond Toy]

On 6/5/23 10:50, Gavin Smith wrote:

On Mon, Jun 05, 2023 at 07:18:00AM -0700, Raymond Toy wrote:

Maxima grovels over the html file to find appropriate links to use for the
html version of the manual. This was working fine with 6.8 and earlier
because I found appropriate regexps to find the links.

This stopped working in 7.0.3 (and maybe earlier?). The regexps no longer
work. This is fine; there was no promise that the format of html links would
be consistent.

The problem I’m seeing is that in the texi source, we have:

|@vrindex Euler's number |

That apostrophe is really an apostrophe character, unicode U+27.

However, in the generated info file, the index has:

|* Euler’s number: Functions and Variables for Constants. |


We'd already addressed this problem for Info output:

https://lists.gnu.org/archive/html/bug-texinfo/2023-02/msg00048.html


Oops.  Sorry.  I'm on the mailing list, but I don't recall seeing this.  
My memory is not so good anymore. :-(






The summary is that words with apostrophes, like "don't", should be
output in Info with an ASCII apostrophe so it is easy to search for these
words.

The end result of this was that we made the output for ' and `
in Texinfo, as well as hyphen characters, use ASCII characters
by default, with a new customiation variable to control this
(ASCII_DASHES_AND_QUOTES).  This will be included in the next Texinfo
release.

Are you easily able to check this with the current Texinfo development
sources?

If you use Texinfo 7.0.3 then you could try setting OPEN_QUOTE_SYMBOL
or CLOSE_QUOTE_SYMBOL to ' (ASCII apostrophe) to turn this off.


I'll look into this soon; thanks for the tip.  It's a bit of a problem 
though because people use all different versions of texinfo to build 
maxima docs.  I've pretty much stayed with 6.8, but some want to use the 
ancient 5.1, and some are building with 7.0.3.


I can check with the current dev version.  But it will take a while 
since I'm in the middle of getting this to work with 7.0.3.

Re: Inconsistency in writing apostrophe in info and html output with version 7.0.3

[Raymond Toy]

On 6/5/23 08:32, Eli Zaretskii wrote:


Date: Mon, 5 Jun 2023 08:11:00 -0700
From: Raymond Toy

It appears not to be consistent. We have this in the texinfo source:


@fnindex N'th previous output

with a real apostrohpe. The info file has


* N'th previous output:  Functions and Variables for Command 
Line.

and that’s also a real apostrophe. Don’t know what’s different between the two 
cases.

I'm guessing that @fnindex is the index of function names, in which
case it generates a "code" typeface, where ASCII characters are not
converted to their Unicode typographical equivalents.

So this is consistent, jut not the kind of consistency you expected.


Ah, that makes sense. Except that it’s not really a function. For 
context, we do:


|@anchor{%th} @deffn {Function} %th (@var{i}) @fnindex N'th previous output |

Not sure what else we should do here. I’ll have to play around with the 
customization variables to see what I can do.


Thanks for you help.

​

Re: Inconsistency in writing apostrophe in info and html output with version 7.0.3

[Raymond Toy]

On 6/5/23 07:18, Raymond Toy wrote:



This is a problem because we use the info file as the source of truth, 
but the HTML file only uses an apostrophe, so we end up with an entry 
that we can find in the info file but not in the html file. This did 
not happen in texinfo 6.8.


Was this intentional? If so, are all apostrophes (U+27) converted to 
right_single_quotation_mark (U+2019) in the info file? That’s 
something I can deal with since it’s consistent.


​


It appears not to be consistent. We have this in the texinfo source:

|@fnindex N'th previous output |

with a real apostrohpe. The info file has

|* N'th previous output: Functions and Variables for Command Line. |

and that’s also a real apostrophe. Don’t know what’s different between 
the two cases.


​

Inconsistency in writing apostrophe in info and html output with version 7.0.3

[Raymond Toy]

Maxima grovels over the html file to find appropriate links to use for 
the html version of the manual. This was working fine with 6.8 and 
earlier because I found appropriate regexps to find the links.


This stopped working in 7.0.3 (and maybe earlier?). The regexps no 
longer work. This is fine; there was no promise that the format of html 
links would be consistent.


The problem I’m seeing is that in the texi source, we have:

|@vrindex Euler's number |

That apostrophe is really an apostrophe character, unicode U+27.

However, in the generated info file, the index has:

|* Euler’s number: Functions and Variables for Constants. |

In emacs , the apostrophe shows up as |\342\200\231|, which is 
Right_Single_Quotation_Mark, unicode U+2019.


This is a problem because we use the info file as the source of truth, 
but the HTML file only uses an apostrophe, so we end up with an entry 
that we can find in the info file but not in the html file. This did not 
happen in texinfo 6.8.


Was this intentional? If so, are all apostrophes (U+27) converted to 
right_single_quotation_mark (U+2019) in the info file? That’s something 
I can deal with since it’s consistent.


​

Re: No bug tracker

[Raymond Toy]

On 3/23/23 13:36, Patrice Dumas wrote:

There was a bugtracker at some point, but it was not so useful.

On Thu, Mar 23, 2023 at 07:44:47PM +, Gavin Smith wrote:

The scale of this project is also a factor here, and if it were a larger
project a bug tracking system might be more useful, although I don't really
have experience of this.

To me that is the main factor here, no much point in such an
infrastructure with such a small project.


I work on some small (one person)  and not so small open source projects 
that also have mailing lists. I like bug trackers because then I have a 
fairly easy way to find a bug instead of having to fish through tons of 
email with possibly incorrect subject lines that might be spread out 
over many threads to find the relevant discussion.  But this also 
requires discipline to discuss the bugs on the tracker instead of the 
mailing list.  And sometimes the mailing list is easier for bug 
discussion than a bug tracker. Hopefully someone will update the bug 
with links to the mailing list or summarizes the mailing list. But that 
means extra work.


I also don't have any qualms about closing bugs as wontfix or not-a-bug, 
as long as I explain (briefly) why.


But each project needs to do whatever works best for them

Re: @multitable with prototype row has no effect in html

[Raymond Toy]

I really appreciate all of the investigation done for this small issue.

Thanks.

On Sun, Jan 15, 2023 at 9:07 AM Patrice Dumas  wrote:

> On Sat, Jan 14, 2023 at 10:19:53AM +, Gavin Smith wrote:
> > On Sat, Jan 14, 2023 at 10:41:10AM +0100, Patrice Dumas wrote:
> > > It seems that the portability of "visibility: collapse" and
> > > implementation is not good, and that it would be better to use
> > > display: none
> > > https://developer.mozilla.org/en-US/docs/Web/CSS/visibility
> >
> > With "display: none" the table row does not affect the column widths at
> > all.
>
> Ok, so not real point trying to implement anything.
>
> --
> Pat
>


-- 
Ray

Re: @multitable with prototype row has no effect in html

[Raymond Toy]

On Wed, Jan 4, 2023 at 4:59 AM Patrice Dumas  wrote:

> On Mon, Jan 02, 2023 at 09:39:33AM -0800, Raymond Toy wrote:
> > On Sun, Jan 1, 2023 at 10:12 AM Patrice Dumas  wrote:
> >
> > > I do not remember any discussion about that.  But it is not clear to me
> > > what should be done.  There is no obvious way to get the width of
> > > rendered text in HTML.
> > >
> > >
> > I am no HTML expert, but couldn't you create a hidden row containing the
> > prototype text for each column?
>
> I don't know how to do that.  An additional constraint is that, at least
> for the default output, it should look ok with no CSS, so if an header
> pops up when there is no CSS this is not good.
>

I did some googling and some experiments but nothing really looked right to
me.  I didn't try super-hard.

So maybe the best thing is for the manual to say that prototypes have no
effect in HTML.  I would be satisfied with that answer. Then I wouldn't
have tried to use it and just used the columnfractions method to space out
the table columns.

>
> > Of course, the prototype is itself a bit
> > problematic with proportional fonts.  However, it does look nice in the
> PDF
> > version.
> >
> > Perhaps this is not worth the effort
>
> If somebody knows the HTML that allows to do it I could add it.
>
> It would also be nice to implement correctly in LaTeX output.
> Currently, for the LaTeX output, the prototype is converted to plain
> text and used to compute the fractions, which is bad (maybe doing
> nothing would be better actually), but if it is doable in Texinfo TeX
> (and it seems to be done with a little bit of code) it should be doable
> in LaTeX too.
>

I haven't tried the LaTeX output; I'm not really interested (currently) in
having makeinfo produce a LaTeX file.

>
> --
> Pat
>


-- 
Ray

Re: @multitable with prototype row has no effect in html

[Raymond Toy]

On Sun, Jan 1, 2023 at 10:19 AM Patrice Dumas  wrote:

> On Thu, Dec 29, 2022 at 11:06:45AM -0800, Raymond Toy wrote:
> > One other thing.  Each item from headitem is left-justified for both info
> > and pdf.  But it's centered in html.  For consistency, should they all be
> > left-justified?  (Or maybe allow a way to control that?  It looks funny
> in
> > html if the columns are wide, but the actual entries are narrow.)
>
> This depends on the browser rendering of .  You can use CSS to
> align, with 'text-align: start;'.  There may be other  in Texinfo
> output, so you could use something like the following to select th in
> multitables:
>
>  table.multitable th {
>   text-align: start;
>  }
>
>
Thanks, this should work.  I was just wondering if texinfo should be more
consistent in the output since the PDF output has left-aligned columns, as
does the info output.

> --
> Pat
>


-- 
Ray

Re: @multitable with prototype row has no effect in html

[Raymond Toy]

On Sun, Jan 1, 2023 at 10:12 AM Patrice Dumas  wrote:

> On Thu, Dec 29, 2022 at 10:59:43AM -0800, Raymond Toy wrote:
> > Consider the following table (taken in part from maxima's user manual):
> >
> > @multitable {greater than or equal to 333} {notequal 333} {relational
> > function}
> > @headitem Operation @tab Symbol @tab Type
> > @item less than  @tab @code{<}@tab relational
> infix
> > @item less than or equal to  @tab @code{<=}   @tab relational
> infix
> > @item equality (syntactic)   @tab @code{=}@tab relational
> infix
> > @end multltable
> >
> > In the pdf and info file, the columns are spaced out nicely according to
> > the prototype.  If the prototype is made wider, then the columns are
> > wider.  But this doesn't happen in the html output.  The width of each
> > column is pretty much fixed to the entry with the widest element.
>
> There is nothing specific in HTML with prototypes, so a plain HTML table
> is output, with the rendering based on the browser.
>
> > But if I replace the prototype with @columnfractions, everything works
> > nicely in info, pdf, and html.
> >
> > The prototype form is much easier to use; it's hard to know a priori what
> > column fractions to use to make the columns spaced nicely.
>
> I do not remember any discussion about that.  But it is not clear to me
> what should be done.  There is no obvious way to get the width of
> rendered text in HTML.
>
>
I am no HTML expert, but couldn't you create a hidden row containing the
prototype text for each column?  Of course, the prototype is itself a bit
problematic with proportional fonts.  However, it does look nice in the PDF
version.

Perhaps this is not worth the effort

> --
> Pat
>


-- 
Ray

Re: @multitable with prototype row has no effect in html

[Raymond Toy]

On Thu, Dec 29, 2022 at 10:59 AM Raymond Toy  wrote:

> Consider the following table (taken in part from maxima's user manual):
>
> @multitable {greater than or equal to 333} {notequal 333} {relational
> function}
> @headitem Operation @tab Symbol @tab Type
> @item less than  @tab @code{<}@tab relational infix
> @item less than or equal to  @tab @code{<=}   @tab relational infix
> @item equality (syntactic)   @tab @code{=}@tab relational infix
> @end multltable
>
> In the pdf and info file, the columns are spaced out nicely according to
> the prototype.  If the prototype is made wider, then the columns are
> wider.  But this doesn't happen in the html output.  The width of each
> column is pretty much fixed to the entry with the widest element.
>
> But if I replace the prototype with @columnfractions, everything works
> nicely in info, pdf, and html.
>
>
>
One other thing.  Each item from headitem is left-justified for both info
and pdf.  But it's centered in html.  For consistency, should they all be
left-justified?  (Or maybe allow a way to control that?  It looks funny in
html if the columns are wide, but the actual entries are narrow.)
-- 
Ray

@multitable with prototype row has no effect in html

[Raymond Toy]

Consider the following table (taken in part from maxima's user manual):

@multitable {greater than or equal to 333} {notequal 333} {relational
function}
@headitem Operation @tab Symbol @tab Type
@item less than  @tab @code{<}@tab relational infix
@item less than or equal to  @tab @code{<=}   @tab relational infix
@item equality (syntactic)   @tab @code{=}@tab relational infix
@end multltable

In the pdf and info file, the columns are spaced out nicely according to
the prototype.  If the prototype is made wider, then the columns are
wider.  But this doesn't happen in the html output.  The width of each
column is pretty much fixed to the entry with the widest element.

But if I replace the prototype with @columnfractions, everything works
nicely in info, pdf, and html.

The prototype form is much easier to use; it's hard to know a priori what
column fractions to use to make the columns spaced nicely.

I tested this with texinfo 6.8 and 7.0.1; they both have the same html
column problem.

-- 
Ray

Re: ambiguous @*table with argument missing formatter argument message

[Raymond Toy]

On Fri, Dec 9, 2022 at 11:40 PM Eli Zaretskii  wrote:

> > From: Gavin Smith 
> > Date: Sat, 10 Dec 2022 00:35:19 +
> >
> > > d.texi:2: bad @table argument
> >
> > would be sufficient.  It could be difficult to explain the usage
> > of @table in an short error message.
> >
> > Perhaps if there is no argument at all it could be
> >
> > > d.texi:2: @table requires an argument
> >
> > instead, although this wouldn't be necessary.
>
> How about "bad or missing @table argument: 'FOO'" ?
>

This works for me, except I'd separate out the two cases:  "Missing @table
argument." and "Bad @table argument: FOO".  I think error messages should
be as simple and as explicit as possible and provide whatever information
that caused it to make it easier for a user to figure out what's going on.


-- 
Ray

Re: ambiguous @*table with argument missing formatter argument message

[Raymond Toy]

On Thu, Dec 8, 2022 at 2:59 PM Patrice Dumas  wrote:

> Hello,
>
> Not sure about that as I am not a native english speaker.  When a
> @*table does not have an @-command formatter for the items, the error
> message is
>
> d.texi:2: table requires an argument: the formatter for @item
>
> This message seems fine to me if there is no argument for @*table,
> however, if there is an argument it seems ambiguous as there is already
> an argument, only not of the good type.
>
> For example the following case of @table with an incorrect argument
> triggers the error message above:
>
> @table foo
> @end table
>
> Maybe the message could be changed to something like
>
> d.texi:2: table requires as argument the formatter for @item
>
> What do you think?
>

Perhaps something like this would be clearer?

d.texi:2: Unrecognized @table argument for the formatter for @item: foo

I find error messages that give the offending value really helpful.  This
also assumes that @table will only recognize a certain set of possible
formatters.  I don't know if that is true.  IIRC, maxima was using @var as
the formatter, but @var was redefined, so I don't know if that would count
as a recognized formatter.  But it definitely didn't work.

>
> --
> Pat
>
>

-- 
Ray

Re: @subentry, @seealso and @seenentry better formatted in HTML

[Raymond Toy]

On Sun, Nov 20, 2022 at 11:24 AM Patrice Dumas  wrote:

> On Sun, Nov 20, 2022 at 11:07:34AM -0800, Raymond Toy wrote:
> >
> > Thank you so much for working on this!  It looks way better and more
> useful
> > than the old way.
> >
> > The only issue I have is that the subentries aren't indented enough.  I
> > think it would be easier to read if they were indented by default by,
> say,
> > about 4 chars or so to make the subentries stand out a bit more.  If you
> > glance at the index, it's easy to miss that the items are indented.
>
> On small screens a level two subentry would lead to too much
> indentation.  But using 2 and 4 would already indent much more.  I'll
> see if it looks ok.
>

Ah, yes, you're right.  In portrait mode, it might make things look really
funny, especially if both the entry and section are rather long, causing
the text to wrap.  This was also a problem in the old scheme.  And in all
cases, it's pretty hard to tell what lines up with what because everything
is wrapped.

But at least with phones and tablets you can just rotate the device to
landscape mode and get something that's reasonable.


> --
> Pat
>


-- 
Ray

Re: @subentry, @seealso and @seenentry better formatted in HTML

[Raymond Toy]

On Sat, Nov 19, 2022 at 1:22 AM Patrice Dumas  wrote:

> Hello,
>
> Some formatting for @subentry, @seenentry and @seealso in HTML more in
> line with TeX output has been implemented in the developpement source:
>
>
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=76485d9ea1f8e411b6b4e4196babe1089d286a42
>
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=cf772b028c696fc58b42d17363e0334af5e5c7d4
>
> (Discussed in
> ttps://lists.gnu.org/archive/html/bug-texinfo/2022-08/msg00103.html).
>

Thank you so much for working on this!  It looks way better and more useful
than the old way.

The only issue I have is that the subentries aren't indented enough.  I
think it would be easier to read if they were indented by default by, say,
about 4 chars or so to make the subentries stand out a bit more.  If you
glance at the index, it's easy to miss that the items are indented.

I haven't tried anything with @seentry or @seealso.

>
> For @seenentry and @seealso, I am not sure about the classes to use, but
> my impression is that the formatting is ok.
>
> for @subentry, I am less sure, as the implementation uses different
> table lines and indentation with a .  In addition, the change has
> probably implications on the info.js reader.  A @subentry is rendered as
> different lines in table, only the last one having a  to link to the
> index entry and to the section or node containing the index entry.  For
> example, for
>
> @findex f---bb @subentry f---cc
>
> the HTML is:
>
>  class="printindex-index-entry">f---bb class="printindex-index-section">
>  class="index-entry-level-1"> href="#index-f_002d_002d_002dbb">f---cc class="printindex-index-section">1 chapter
>
> In this case there is only one entry with f---bb as amin entry, but if
> there was another one, it could be before the part corresponding to
> @subentry f---cc.
>
> Any proposition for a better formatting?  Any idea on how to help
> javascript-ing, maybe with a custom attribute with the full entry with
> commas separating the subentries?
>
> --
> Pat
>
>

-- 
Ray

Re: Release branch added to git

[Raymond Toy]

On Sat, Nov 12, 2022 at 2:56 PM Gavin Smith 
wrote:

> On Sat, Nov 12, 2022 at 02:30:11PM -0800, Raymond Toy wrote:
> > On Sat, Nov 12, 2022 at 2:27 PM Gavin Smith 
> > wrote:
> >
> > > On Tue, Nov 08, 2022 at 07:55:44PM +, Gavin Smith wrote:
> > > > > No, you just cut a new release branch.  The release branch is only
> for
> > > > > a certain release or a series of releases, depending on the
> > > > > development strategy.  Basically, as long as you expect the next
> > > > > release to be a bugfix release, you keep developing it on the same
> > > > > release branch, and once you decide on a feature release, you cut a
> > > > > new release branch.  The name of the release branch can be the
> first
> > > > > version released from that branch, or some variant of that.
> > > >
> > > > Thanks, that makes sense.
> > >
> > >
> > > I have added a release branch to the git repository, called
> "release/7.0".
> > > Please do not commit anything to it right now if you have access.
> > >
> >
> > Can you clarify how this is related to the tag texinfo-7.0?  Will they
> have
> > the same stuff?
>
> The tag texinfo-7.0 is a fixed tag, which is at the base of the release/7.0
> branch.  As more commits are made to release/7.0, the release/7.0 branch
> will move ahead, leaving texinfo-7.0 behind.  At some point soon, there
> will be a texinfo-7.0.1 release, which will occur on the release/7.0
> branch.  If there are more bug-fixes/translation updates/other minor or
> harmless updates, these may also be made on the release/7.0 branch, tagged
> in fixed positions as texinfo-7.0.2, texinfo-7.0.3, etc., along the branch.
>

Perfect!  Thanks for letting me know.


-- 
Ray

Re: Release branch added to git

[Raymond Toy]

On Sat, Nov 12, 2022 at 2:27 PM Gavin Smith 
wrote:

> On Tue, Nov 08, 2022 at 07:55:44PM +, Gavin Smith wrote:
> > > No, you just cut a new release branch.  The release branch is only for
> > > a certain release or a series of releases, depending on the
> > > development strategy.  Basically, as long as you expect the next
> > > release to be a bugfix release, you keep developing it on the same
> > > release branch, and once you decide on a feature release, you cut a
> > > new release branch.  The name of the release branch can be the first
> > > version released from that branch, or some variant of that.
> >
> > Thanks, that makes sense.
>
>
> I have added a release branch to the git repository, called "release/7.0".
> Please do not commit anything to it right now if you have access.
>

Can you clarify how this is related to the tag texinfo-7.0?  Will they have
the same stuff?

-- 
Ray

Re: On mobile, menu items examples are too small

[Raymond Toy]

On Fri, Nov 11, 2022 at 5:32 PM Gavin Smith 
wrote:

> On Fri, Nov 11, 2022 at 04:16:46PM -0800, Raymond Toy wrote:
> > texinfo 7.0 makes a difference.  The tables are not in a tiny font.  (At
> > least when I use chrome and firefox developer tools to simulate a mobile
> > device.)
> >
> > It might be good to know what changed to make this work so it doesn't
> > regress in the future, but I guess basically it's all working now with
> 7.0.
>
> This has been discussed several times in the past on this mailing list.
> The issue is a so-called "font boosting" feature in mobile web browsers.
>
> We worked around this both with a
>
> 
>

Ah, yes, I had to do that too for some other pages I have.

>
> declaration in the document, and with less use of tables by default.
>

It seems for these pages, building with 6.8 was enough to make everything
work.  I didn't change anything other than building with texinfo 6.8.


-- 
Ray

Re: On mobile, menu items examples are too small

[Raymond Toy]

On Fri, Nov 11, 2022 at 1:40 PM Raymond Toy  wrote:

>
>
> On Fri, Nov 11, 2022 at 12:18 PM Patrice Dumas  wrote:
>
>> On Fri, Nov 11, 2022 at 10:34:05AM -0800, Raymond Toy wrote:
>> > The following examples were built using texinfo 6.8 (haven't upgraded
>> to 7
>> > yet).  No custom css is used.
>> >
>> > Look at
>> >
>> https://cmucl.org/docs/cmu-user/html/More-About-Types-in-Python.html#More-About-Types-in-Python
>> > on a mobile device.  I'm using a Pixel 4 phone with both Chrome and
>> > Firefox.  At the bottom, there are links for more sections.  They are
>> very
>> > tiny and almost unreadable.
>> >
>> > Now look at
>> https://cmucl.org/docs/cmu-user/html/The-Values-Declaration.html.
>> > The code snippets (@example) are really tiny.
>> >
>> > And curiously,
>> >
>> https://cmucl.org/docs/cmu-user/html/Advanced-Compiler-Use-and-Efficiency-Hints.html
>> > has the entire page in tiny font, including the heading and text.
>> >
>> > This seems really odd.  In general, the pages look nice on mobile.  Just
>> > menu items and examples seem to be using a really tiny font.
>>
>> The menu items are in a table, and another table has the same issue:
>>
>> https://cmucl.org/docs/cmu-user/html/Relative-Package-Names.html#Relative-Package-Names
>>
>> So it looks like things in  and in  get tiny.  I have no
>> idea what could be going on.
>>
>
> I don't know either, but I was able to get chrome remote debugging
> attached to my phone.  So, it says I'm using a Times New Roman font.  The
> paragraph above the table has a font size of 51.7199px.  I guess that makes
> sense since I have android set up for large fonts.  But the table has a
> font size of 16px.  That would certainly explain it.  I have no idea where
> that font size comes from.
>
> Oh,  and the files say I used texinfo 6.7; I'm pretty sure I intended to
> use 6.8.  I'll give that a try and see if it makes a difference.
>

texinfo 7.0 makes a difference.  The tables are not in a tiny font.  (At
least when I use chrome and firefox developer tools to simulate a mobile
device.)

It might be good to know what changed to make this work so it doesn't
regress in the future, but I guess basically it's all working now with 7.0.

>
>> --
>> Pat
>>
>
>
> --
> Ray
>


-- 
Ray

Re: On mobile, menu items examples are too small

[Raymond Toy]

On Fri, Nov 11, 2022 at 12:18 PM Patrice Dumas  wrote:

> On Fri, Nov 11, 2022 at 10:34:05AM -0800, Raymond Toy wrote:
> > The following examples were built using texinfo 6.8 (haven't upgraded to
> 7
> > yet).  No custom css is used.
> >
> > Look at
> >
> https://cmucl.org/docs/cmu-user/html/More-About-Types-in-Python.html#More-About-Types-in-Python
> > on a mobile device.  I'm using a Pixel 4 phone with both Chrome and
> > Firefox.  At the bottom, there are links for more sections.  They are
> very
> > tiny and almost unreadable.
> >
> > Now look at
> https://cmucl.org/docs/cmu-user/html/The-Values-Declaration.html.
> > The code snippets (@example) are really tiny.
> >
> > And curiously,
> >
> https://cmucl.org/docs/cmu-user/html/Advanced-Compiler-Use-and-Efficiency-Hints.html
> > has the entire page in tiny font, including the heading and text.
> >
> > This seems really odd.  In general, the pages look nice on mobile.  Just
> > menu items and examples seem to be using a really tiny font.
>
> The menu items are in a table, and another table has the same issue:
>
> https://cmucl.org/docs/cmu-user/html/Relative-Package-Names.html#Relative-Package-Names
>
> So it looks like things in  and in  get tiny.  I have no
> idea what could be going on.
>

I don't know either, but I was able to get chrome remote debugging attached
to my phone.  So, it says I'm using a Times New Roman font.  The paragraph
above the table has a font size of 51.7199px.  I guess that makes sense
since I have android set up for large fonts.  But the table has a font size
of 16px.  That would certainly explain it.  I have no idea where that font
size comes from.

Oh,  and the files say I used texinfo 6.7; I'm pretty sure I intended to
use 6.8.  I'll give that a try and see if it makes a difference.

>
> --
> Pat
>


-- 
Ray

On mobile, menu items examples are too small

[Raymond Toy]

The following examples were built using texinfo 6.8 (haven't upgraded to 7
yet).  No custom css is used.

Look at
https://cmucl.org/docs/cmu-user/html/More-About-Types-in-Python.html#More-About-Types-in-Python
on a mobile device.  I'm using a Pixel 4 phone with both Chrome and
Firefox.  At the bottom, there are links for more sections.  They are very
tiny and almost unreadable.

Now look at https://cmucl.org/docs/cmu-user/html/The-Values-Declaration.html.
The code snippets (@example) are really tiny.

And curiously,
https://cmucl.org/docs/cmu-user/html/Advanced-Compiler-Use-and-Efficiency-Hints.html
has the entire page in tiny font, including the heading and text.

This seems really odd.  In general, the pages look nice on mobile.  Just
menu items and examples seem to be using a really tiny font.

-- 
Ray

Re: Building texinfo 7 from git

[Raymond Toy]

On Wed, Nov 9, 2022 at 4:01 AM Patrice Dumas  wrote:

> On Tue, Nov 08, 2022 at 02:02:46PM -0800, Raymond Toy wrote:
> > On Tue, Nov 8, 2022 at 8:34 AM Gavin Smith 
> wrote:
> >
> > >
> > > Can you check the output from "automake --version" as I believe older
> > > automake required "@setfilename" in Texinfo files.
> > >
> >
> > It says 1.15.1. On a different linux box, I have 1.16.2, but I haven't
> > tried building texinfo there yet.
>
> I checked the automake NEWS, and indeed,
> New in 1.16.2:
>   - automake no longer requires a @setfilename in each .texi file
>
> I started removing @setfilename everywhere to be in line with the
> evolutions of Texinfo, but I can readd to the texi2any_api and
> texi2anay_internals manuals.  Alternatively, we may bump the requirement
> of AM_INIT_AUTOMAKE to 1.16.2.
>

Not sure what is best, but on my up-to-date openSuSE Leap 15.4 system,
automake version is 1.15.1.  My Fedora 35 system has 1.16.2.  Don't know
what other up-to-date releases have, but if there are many current distros
with 1.15.1, perhaps the requirement for 1.16.2 is premature?

>
> --
> Pat
>


-- 
Ray

Re: Building texinfo 7 from git

[Raymond Toy]

On Tue, Nov 8, 2022 at 2:02 PM Raymond Toy  wrote:

>
>
> On Tue, Nov 8, 2022 at 8:34 AM Gavin Smith 
> wrote:
>
>>
>> Can you check the output from "automake --version" as I believe older
>> automake required "@setfilename" in Texinfo files.
>>
>
> It says 1.15.1. On a different linux box, I have 1.16.2, but I haven't
> tried building texinfo there yet.
>

For the record, it builds fine on my other system with automake 1.16.2.

>
>
> --
> Ray
>


-- 
Ray

Re: Building texinfo 7 from git

[Raymond Toy]

On Tue, Nov 8, 2022 at 8:34 AM Gavin Smith  wrote:

>
> Can you check the output from "automake --version" as I believe older
> automake required "@setfilename" in Texinfo files.
>

It says 1.15.1. On a different linux box, I have 1.16.2, but I haven't
tried building texinfo there yet.


-- 
Ray

Building texinfo 7 from git

[Raymond Toy]

I did a git clone of texinfo, changed to the texinfo-7.0 branch and tried
to build it.  It didn't work.

I ran autogen.sh and got the message:

Preparing Texinfo development infrastructure:
  ./tp/maintain/regenerate_file_lists.pl
  (cd tp && ./maintain/regenerate_docstr.sh Makefile.docstr)
  (cd tp/tests && ../maintain/regenerate_cmd_tests.sh Makefile.onetst .
-base 'formatting sectioning indices nested_formats contents layout'
-tex_html 'tex_html' -other 'other')
  aclocal -I gnulib/m4 && autoconf && autoheader && automake
doc/Makefile.am: error: 'doc/texi2any_api.texi' missing @setfilename

Afterwards, I run configure, but it fails:
config.status: error: cannot find input file: `doc/Makefile.in'

However, if I download the texinfo-7.0 tarballs, everything works fine.

-- 
Ray

Re: Missing bottom nav bar on some html pages?

[Raymond Toy]

On Tue, Nov 8, 2022 at 8:04 AM Patrice Dumas  wrote:

> On Tue, Nov 08, 2022 at 07:48:20AM -0800, Raymond Toy wrote:
> > On most html manuals that I've looked at that have split the manual into
> > multiple html pages, I see a navbar  (next/previous/up) at the top of
> each
> > page and also at the bottom.
> >
> > However, once in a while I see pages where the bottom navbar is
> missing.  I
> > noticed this first at
> >
> https://cmucl.org/docs/cmu-user/html/Without-Object-Sets.html#Without-Object-Sets
> .
> > I thought this was a bug in the texinfo sources, but then I noticed that
> >
> https://www.gnu.org/software/make/manual/html_node/Makefile-Conventions.html
> > doesn't have a bottom navbar either.
> >
> > Is this a bug?  An intentional design decision? (If so, I how do I know
> > when a bottom navbar is produced or not?)
>
> It is intentional, when there are less than a given number of word,
> there is no footer, at least when split at nodes.  See WORDS_IN_PAGE
> to customize:
>
>
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/HTML-Customization-Variables.html#index-WORDS_005fIN_005fPAGE


Ah, thanks!  I didn't know that.  (There are so many options!)

>
>
> --
> Pat
>


-- 
Ray

Missing bottom nav bar on some html pages?

[Raymond Toy]

On most html manuals that I've looked at that have split the manual into
multiple html pages, I see a navbar  (next/previous/up) at the top of each
page and also at the bottom.

However, once in a while I see pages where the bottom navbar is missing.  I
noticed this first at
https://cmucl.org/docs/cmu-user/html/Without-Object-Sets.html#Without-Object-Sets.
I thought this was a bug in the texinfo sources, but then I noticed that
https://www.gnu.org/software/make/manual/html_node/Makefile-Conventions.html
doesn't have a bottom navbar either.

Is this a bug?  An intentional design decision? (If so, I how do I know
when a bottom navbar is produced or not?)

For the record, the doc at cmucl.org was generated using texinfo 6.8.  I
guess the gnu make doc was using texinfo 6.7.

-- 
Ray

Re: behavior of @math with HTML output

[Raymond Toy]

On Fri, Oct 14, 2022 at 12:43 PM Vincent Lefevre  wrote:

> On 2022-10-14 08:40:58 -0700, Raymond Toy wrote:
> > For one example of a texinfo doc using Mathjax, see
> > https://maxima.common-lisp.dev/.  In particular, you can look at
> > https://maxima.common-lisp.dev/docs/maxima_79.html.  A maxima user (who
> > might be blind?) says that the MathJax-enabled formulas work really well
> > with a screen reader.  Mathjax appears to support accessibility well.
> >
> > I don't have lynx and actually have no interest in using a text-only
> > browser.
>
> Here's what I get for bessel_y with lynx:
>

I was mostly responding to Patrice who asked about a doc that used
mathjax.  I didn't expect this to work with a text browser that doesn't
have javascript.

>
>   bessel_y is defined as
>  ▒
>
>  ▒
>   \[Y_v(z) = {{\cos(\pi v)\, J_v(z) - J_{-v}(z)}\over{\sin{\pi
>  ▒
>   v}}} \]
> ▒
>
>  ▒
>   when \(v\) is not an integer. When \(v\) is an integer \(n\),
> ▒
>   the limit as \(v\) approaches \(n\) is taken.
> ▒
>
> With w3m, this is very similar.
>
> But even in Firefox, this is very poorly supported: variables, such as
> n in "integer n", are rendered as SVG instead of normal text.
>

Hmm, my default browser is Firefox.  The output looks right, but I didn't
check to see how it was actually rendered.  I think texinfo 6.8 mathjax
uses the SVG output instead of CHTML.  Not sure why that is and if it
really matters or not.  (In my own stuff, I've used CHTML).

>
> The consequences are:
>   * These variables do not look the same as in the prototype.
> And the SVG is not scaled correctly: these variables are
> much smaller than the normal text.
>

Interesting.  For me SVG sizes look right, but when I switch to CHTML,
everything is too small compared to the text.  Perhaps that's an artifact
of the font I'm using to display normal text.

>   * These variables cannot be selected, e.g. for copy-paste.
>
> SVG can be changed to CHTML, which fixes the font size, but the
> rendering is ugly, and the variables still cannot be selected.
> I'm wondering why MathML (presentation markup) isn't available,
> as according the test at
>
>   http://eyeasme.com/Joe/MathML/MathML_browser_test.html
>
> it seems to be well supported by Firefox. It is as nice as SVG,
> these doesn't seem to be scaling issues, and the text can be
> selected.
>

Possibly a bug in Mathjax?  Or because Mathjax is using SVG instead of
MathML for displaying math.  I'll have to read the Mathjax docs again to
know what Mathjax uses to render equations.


> However, MathML wouldn't solve the issue with lynx. A better solution
> would be w3m instead of lynx. I suppose that MathML could be converted
> to plain HTML with XSLT.
>
> --
> Vincent Lefèvre  - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>


-- 
Ray

Re: behavior of @math with HTML output

[Raymond Toy]

On Fri, Oct 14, 2022 at 7:02 AM Patrice Dumas  wrote:

> On Fri, Oct 14, 2022 at 01:31:20PM +0200, Vincent Lefevre wrote:
> > > On Fri, Oct 14, 2022 at 12:40:08AM +0200, Vincent Lefevre wrote:
> > > >
> > > >   * l2h generates image files as documented, which have many
> drawbacks
> > > > (do not work with text browsers, not accessible, font size issues
> > > > with a graphical browser...).
> >
> > Well, so, broken design. It does not conform to the accessibility
> > rules and does not give correct rendering.
>
> There is an ALT tag with the original LaTeX code.  Can you elaborate on
> what is missing and how this could be improved?
>
> > > >   * mathjax is not compatible with text browsers.
> >
> > Also broken design as there is no correct fallback for text browsers.
>
> I tested the page
> https://mathjax.github.io/MathJax-demos-web/tex-chtml.html
> with lynx (there are no Texinfo manuals with mathjax enabled I know of,
> if anybody knows about one, please tell me), and the result seems good
> to me, the LaTeX code is shown which is not a bad choice for math in
> a terminal.
>

For one example of a texinfo doc using Mathjax, see
https://maxima.common-lisp.dev/.  In particular, you can look at
https://maxima.common-lisp.dev/docs/maxima_79.html.  A maxima user (who
might be blind?) says that the MathJax-enabled formulas work really well
with a screen reader.  Mathjax appears to support accessibility well.

I don't have lynx and actually have no interest in using a text-only
browser.

>
> --
> Pat
>
>

-- 
Ray

Re: @documentlanguage and locale file

[Raymond Toy]

On Wed, Sep 28, 2022 at 2:56 PM Gavin Smith 
wrote:

> On Wed, Sep 28, 2022 at 01:24:00PM -0700, Raymond Toy wrote:
> > The manual says:
> >
> > For TeX, this command causes a file txi-locale.tex to be read (if it
> > exists).
> >
> > But when I run texi2pdf maxima.texi, I get
> >
> > ./maxima.texi:4: Cannot read language file txi-ru.tex.
> >
> > Which is true, but I was expecting TeX to ignore this.
>
> txi-ru.tex is distributed with Texinfo and needs to be placed in a
> directory
> where TeX will find it.
>

Sorry for the delay.  Thanks for the info.  For some reason, I think this
used to work, but I've since upgraded my OS so I guess some things are
messed up.  I'll look into getting these missing files installed in the
right place.


-- 
Ray

@documentlanguage and locale file

[Raymond Toy]

The manual says:

For TeX, this command causes a file txi-locale.tex to be read (if it
exists).

But when I run texi2pdf maxima.texi, I get

./maxima.texi:4: Cannot read language file txi-ru.tex.

Which is true, but I was expecting TeX to ignore this.

maxima.texi (for Russian) is basically:

\input ../texinfo
@setfilename  maxima.info
@documentencoding UTF-8
@documentlanguage ru
@include include-maxima.texi

@bye

include-maxima.texi includes all the various sections of the maxima manual.


-- 
Ray

Re: Format of html index vs pdf

[Raymond Toy]

On Fri, Aug 12, 2022 at 9:46 AM Gavin Smith 
wrote:

> On Fri, Aug 12, 2022 at 08:01:06AM -0700, Raymond Toy wrote:
> > I created a new index ct and have entries like
> >
> > @ctindex Package @subentry diag @subentry mat_function
> > @ctindex Package @subentry distrib @subentry pdf_normal
> >
> > The index in the pdf file looks something like
> >
> > Package,
> >   diag,
> > mat_function  
> >   distrib,
> > pdf_normal 
> >
> > This looks really, really nice.
> >
> > But the html version looks like
> >
> > P
> >   Package, diag, mat_function: Functions and Variables for
> diag
> >   Package, distrib, pdf_normal:Normal Random Variable
> >
> > This is perfectly usable, but it would be nice if it could be arranged a
> > bit more like the pdf manual to make the distinction between the
> subentries
> > better.  I was kind of expecting something more like the pdf version
> which
> > is nice because it shows the hierarchy of the subentries very nicely.
>
> Somebody would have to implement this in HTML.  I think it was felt
> at the time when implementing the multi-level indices that HTML and
> Info indices were not looked at as much as in DVI or PDF.  I've no
> objection in principle to this but it may complicate automatic processing
> of indices in HTML (as in the Javascript reader).
>

The PDF version looks great. :-)

>
> >
> > I'm basically trying to replace Documentation Categories
> > <https://maxima.common-lisp.dev/docs/maxima_407.html> that is generated
> by
> > using a bunch of scripts to extract categories in the texi sources.
> Using
> > a new index pretty much works just fine at the expense of a one-time cost
> > of manually adding all the index entries.  It would be nice if the html
> > index looked more like the pdf index.  Or at least separated out the
> > 2-level subentries a little better.
>
> Before creating a new index for every package check that TeX can handle
> that many indices.  I remember in the past having an issue with the
> number of indices because there is a limit of 16 open files for output
> in TeX and nothing was done in texinfo.tex to work around this limitation.
>

I'm not creating a new index for each package.  It's just one giant index.
There are other entries like "Special Functions", "Elliptic Functions",
etc.  "Package" is just another entry with 2 subentries: the package name
and the function in the package.  However, I think this can be modified by
adding yet another index to handle Package, so index entries are only 2
levels.  That should work out fine.


> I am not sure that an index would be an improvement on the page you
> have there.
>

In terms of what's displayed, no, there's not.  But that index is created
by a bunch of scripts that grovel over the texi files to create a file that
is then used to create the actual section.

Using texinfo's indexing feature allows us to get rid of the messy
scripts.  (I haven't actually converted everything, but the snippet I gave
seems to work fine.)

>
> It's possible that Texinfo should have more support for this kind of
> thing (and API documentation in general) although I am not sure what
> to suggest.  It looks like you are doing a pretty good job as it is
> with the page.
>
> As there is already an index entry being created by the @def*
> command produces the definition block, as at
>
> https://maxima.common-lisp.dev/docs/maxima_211.html#index-mat_005ffunction
>
> ideally, the extra @ctindex wouldn't need to be in there and the
> package name could be included in the @def* command.  Something on the
>

Unfortunately this doesn't quite work.  Functions can be in more than one
category.  For example, bessel_j is in both the Special Functions category
and the Bessel Functions category.

Texinfo side would be needed to produce a page like that Document
> Categories one, somehow.  I think this is work for the future.  (At
> the same time, we could also automatically provide some way of cross-
> referencing a def block without a need for an extra @anchor to appear
> in the source.  This is too much change for the immediate future.)
>

Yeah, I always assumed that you wanted people to insert anchors only as
needed.

Thanks for your help.


-- 
Ray

Format of html index vs pdf

[Raymond Toy]

I created a new index ct and have entries like

@ctindex Package @subentry diag @subentry mat_function
@ctindex Package @subentry distrib @subentry pdf_normal

The index in the pdf file looks something like

Package,
  diag,
mat_function  
  distrib,
pdf_normal 

This looks really, really nice.

But the html version looks like

P
  Package, diag, mat_function: Functions and Variables for diag
  Package, distrib, pdf_normal:Normal Random Variable

This is perfectly usable, but it would be nice if it could be arranged a
bit more like the pdf manual to make the distinction between the subentries
better.  I was kind of expecting something more like the pdf version which
is nice because it shows the hierarchy of the subentries very nicely.

I'm basically trying to replace Documentation Categories
 that is generated by
using a bunch of scripts to extract categories in the texi sources.  Using
a new index pretty much works just fine at the expense of a one-time cost
of manually adding all the index entries.  It would be nice if the html
index looked more like the pdf index.  Or at least separated out the
2-level subentries a little better.








































-- 
Ray

Re: @displaymath in @iftex

[Raymond Toy]

Ah, thanks.  I see now that my m4 macro invocation was adding an extra line
because trailing whitespace of an arg is included as part of the arg.  And
the offending code did this.

Really sorry for all of the trouble!

On Wed, Aug 10, 2022 at 1:28 PM Gavin Smith 
wrote:

> On Wed, Aug 10, 2022 at 01:07:31PM -0700, Raymond Toy wrote:
> >
> > I must be doing something wrong.  This is what I have:
> > ---
> > The following relationships are true:
> >
> >
> > @ifhtml
> > @displaymath
> > \eqalign{
> > m &= k^2 \cr
> > k &= \sin\alpha
> > }
> >
> > @end displaymath
> > @end ifhtml
> > @ifinfo
> > @math{m = k^2}
> >
> > @math{k = sin(alpha)}
> >
> > @end ifinfo
> > @iftex
> > @displaymath
> > \eqalign{
> > m &= k^2 \cr
> > k &= \sin\alpha
> > }
> >
> > @end displaymath
> > @end iftex
> >
> >
> > Note that Abramowitz and Stegun uses the notation
> > -
>
> If you put that into a Texinfo file and process it with texinfo.tex,
> you get an error message like
>
> ! Missing $ inserted.
> 
> $
> 
>@par
> l.24
>
>
> @par is a token that is inserted at the end of a paragraph, indicated
> by blank lines.  l.24 refers to line 24, which was blank.  If you
> remove that blank line, the file processes without error and the output
> appears to be as expected:
>
> > @iftex
> > @displaymath
> > \eqalign{
> > m &= k^2 \cr
> > k &= \sin\alpha
> > }
> > @end displaymath
> > @end iftex
>


-- 
Ray

Re: @displaymath in @iftex

[Raymond Toy]

On Wed, Aug 10, 2022 at 9:15 AM Gavin Smith 
wrote:

> On Wed, Aug 10, 2022 at 09:07:20AM -0700, Raymond Toy wrote:
> > The manual isn't clear about what @displaymath does.  I have something
> like
> >
> > @ifhtml
> > @displaymath
> > eqn
> > @end displaymath
> > @end ifhtml
> > @iftex
> > @displaymath
> > eqn
> > @end displaymath
> > @end iftex
> >
> > The html version looks great with the eqn displayed as expected.  But in
> > the pdf manual, there's an error about missing $ that is inserted.
> >
> > Everything works as expected if I do
> >
> > @tex
> > $$eqn$$
> > @end tex
> >
> > This is a perfectly fine solution for me, but I just wanted to know if
> > @displaymath should work in @iftex.
>
> Yes, it should work.  I've just tested it and it appears to work fine.
>

I must be doing something wrong.  This is what I have:
---
The following relationships are true:


@ifhtml
@displaymath
\eqalign{
m &= k^2 \cr
k &= \sin\alpha
}

@end displaymath
@end ifhtml
@ifinfo
@math{m = k^2}

@math{k = sin(alpha)}

@end ifinfo
@iftex
@displaymath
\eqalign{
m &= k^2 \cr
k &= \sin\alpha
}

@end displaymath
@end iftex


Note that Abramowitz and Stegun uses the notation
-

What happens is that the pdf file complains that $ needs to be inserted at
the blank line right before @displaymath inside the @iftex.

The html file displays correctly, as does the info file.

This is makeinfo 6.8.

Not a big deal.  I can use the @tex/@end tex that I was using before that
worked fine.

-- 
Ray

@displaymath in @iftex

[Raymond Toy]

The manual isn't clear about what @displaymath does.  I have something like

@ifhtml
@displaymath
eqn
@end displaymath
@end ifhtml
@iftex
@displaymath
eqn
@end displaymath
@end iftex

The html version looks great with the eqn displayed as expected.  But in
the pdf manual, there's an error about missing $ that is inserted.

Everything works as expected if I do

@tex
$$eqn$$
@end tex

This is a perfectly fine solution for me, but I just wanted to know if
@displaymath should work in @iftex.

-- 
Ray

Re: @inlinefmt(tex, foo)

[Raymond Toy]

On Wed, Aug 10, 2022 at 8:53 AM Gavin Smith 
wrote:

>
> You could also do
>
> > @ifhtml
> > @math{{\rm Ai}(x)} @c
> > @end ifhtml
> > @ifinfo
> > @math{Ai(x)} @c
> > @end ifinfo
> > @iftex
> > @math{{\rm Ai}(x)} @c
> > @end iftex
> > and
>
> although I don't know how easy this would be with your macros.
>

That's easy.  But then if I want a period to follow instead of "and",
there's an extra space.  What I do know is define another macro that just
appends a dot after each math equation in each block to get the period in
the right place.

This is ok.  @inlinefmt(tex, foo) would simplify this a bit, but since it's
all with m4 macros, this is fine as it is.

Thanks for your help!  The math equations in the maxima manual are looking
pretty good now, after cleaning up the issue with extra space between a
formula and a period or comma.


-- 
Ray

Re: @inlinefmt(tex, foo)

[Raymond Toy]

On Wed, Aug 10, 2022 at 7:43 AM Raymond Toy  wrote:

>
> This appears to produces good results but you would have to try it in
>> your document to be sure.  If you don't want an extra space to appear then
>> you need to use
>>
>> @iftex
>> @math{{\rm Ai}(x)@c
>> @end iftex
>>
>> to comment out the newline.
>>
>
> Ah, this is great!  I'd previously been using block conditionals, but
> there was always an extra space, which meant the inline formulas followed
> by a period had an extra space.  That's why I was thinking of using
> @inlinefmt for this.
>

Ah, not quite.  With the @c, any following spaces get swallowed.  What I
have is something like

The Airy functions
@ifhtml
@math{{\rm Ai}(x)}@c
@end ifhtml
@ifinfo
@math{Ai(x)}@c
@end ifinfo
@iftex
@math{{\rm Ai}(x)}@c
@end iftex
 and

This gets rendered in the pdf as "y = Ai(x)and".  No space between the
function and "and".  The block for the formula is generated by an m4 macro.

(I couldn't get a texinfo macro to do what I wanted.  Maybe because I was
too stupid or because I was using a fairly old version when I tried.)

Anyway, this is a nice path forward and I know how I can swallow the
trailing space if needed when the formula is followed by a period or other
punctuation.


> And previously I was also doing
>
> @tex
> ${\rm Ai}(x)$
> @end tex
>
> but @iftex seems nicer. since I can add @math{} around it.
>
>>
>> The reason that the texinfo.tex implementation is flawed is that when
>> @inlinefmt reads its arguments, \ is not an escape character, and it
>> is not reinterpreted after checking the conditional.  This shows
>> a possible fix:
>>
>> --- a/doc/texinfo.tex
>> +++ b/doc/texinfo.tex
>> @@ -3343,7 +3343,7 @@ $$%
>>  \long\def\inlinefmt#1{\doinlinefmt #1,\finish}
>>  \long\def\doinlinefmt#1,#2,\finish{%
>>\def\inlinefmtname{#1}%
>> -  \ifx\inlinefmtname\outfmtnametex \ignorespaces #2\fi
>> +  \ifx\inlinefmtname\outfmtnametex \ignorespaces \scantokens{#2}\fi
>>  }
>>  %
>>  % @inlinefmtifelse{FMTNAME,THEN-TEXT,ELSE-TEXT} expands THEN-TEXT if
>>
>> although I would rather not touch this code if possible.  It might be
>> better just to document the limitation and workaround in the manual.
>>
>
> I think it would be nice if inlinefmt(tex,...) worked, but I'll leave that
> to you.  I have a workaround that is perfectly fine and AFAICT, would work
> just as well as inlinefmt.
>
>
> --
> Ray
>


-- 
Ray

Re: @inlinefmt(tex, foo)

[Raymond Toy]

On Wed, Aug 10, 2022 at 2:49 AM Gavin Smith 
wrote:

> > If I do
> >
> > @inlinefmt{tex, {\rm Ai}(x)}
> >
> > The output is "\rm Ai(x)" in a normal roman font.
>
> A workaround is to use a block conditional instead:
>
> @iftex
> @math{{\rm Ai}(x)
> @end iftex
>
> This appears to produces good results but you would have to try it in
> your document to be sure.  If you don't want an extra space to appear then
> you need to use
>
> @iftex
> @math{{\rm Ai}(x)@c
> @end iftex
>
> to comment out the newline.
>

Ah, this is great!  I'd previously been using block conditionals, but there
was always an extra space, which meant the inline formulas followed by a
period had an extra space.  That's why I was thinking of using @inlinefmt
for this.

And previously I was also doing

@tex
${\rm Ai}(x)$
@end tex

but @iftex seems nicer. since I can add @math{} around it.

>
> The reason that the texinfo.tex implementation is flawed is that when
> @inlinefmt reads its arguments, \ is not an escape character, and it
> is not reinterpreted after checking the conditional.  This shows
> a possible fix:
>
> --- a/doc/texinfo.tex
> +++ b/doc/texinfo.tex
> @@ -3343,7 +3343,7 @@ $$%
>  \long\def\inlinefmt#1{\doinlinefmt #1,\finish}
>  \long\def\doinlinefmt#1,#2,\finish{%
>\def\inlinefmtname{#1}%
> -  \ifx\inlinefmtname\outfmtnametex \ignorespaces #2\fi
> +  \ifx\inlinefmtname\outfmtnametex \ignorespaces \scantokens{#2}\fi
>  }
>  %
>  % @inlinefmtifelse{FMTNAME,THEN-TEXT,ELSE-TEXT} expands THEN-TEXT if
>
> although I would rather not touch this code if possible.  It might be
> better just to document the limitation and workaround in the manual.
>

I think it would be nice if inlinefmt(tex,...) worked, but I'll leave that
to you.  I have a workaround that is perfectly fine and AFAICT, would work
just as well as inlinefmt.


-- 
Ray

@inlinefmt(tex, foo)

[Raymond Toy]

I have some code that looks like:

@inlinefmt{html, @math{{\rm Ai}(x)}}
@inlinefmt{info, @math{Ai(x)}}
@inlinefmt{tex, @math{{\rm Ai}(x)}}

The info file and html (with mathjax) look right where we have "Ai" in a
roman font and "(x)" in an italicized math font.

However, the pdf file basically prints out "\rmAi(x)" in an italic math
font.

If I do

@inlinefmt{tex, {\rm Ai}(x)}

The output is "\rm Ai(x)" in a normal roman font.

I can't figure out how to get this to render the pdf such that it matches
the html output.

I'm using makeinfo 6.8.

-- 
Ray

Re: @fnindex in html output vs info?

[Raymond Toy]

Oops.  I figured it out.  I didn't notice earlier because I was just using
grep to find the fnindex lines.

However, each of these @fnindex lines is inside @ifinfo/@end ifinfo.  That
would explain it.

Sorry for the noise!

On Wed, Jul 27, 2022 at 3:47 AM Gavin Smith 
wrote:

> On Tue, Jul 26, 2022 at 05:54:04PM -0700, Raymond Toy wrote:
> > On a related note, maxima has a few things like "@fnindex Logical
> > conjunction".  These show up in the info file.  However, I can't find
> that
> > anywhere in the html file(s).  Is that a bug too?
>
> I couldn't reproduce this.  I checked with --no-split and without.
>
> Could you try to produce a minimal failing example that you could
> post to this list?
>
> The code below has both bar and foo in the index.
>
> \input texinfo
> @synindex ky fn
> @synindex vr fn
> @synindex cp fn
>
> @node Top
>
> top node hello
>
> @node Two
>
> @fnindex foo
> @cindex bar
>
> @node Index
>
> @printindex fn
>
> @bye
>
>

-- 
Ray

Re: @fnindex in html output vs info?

[Raymond Toy]

On a related note, maxima has a few things like "@fnindex Logical
conjunction".  These show up in the info file.  However, I can't find that
anywhere in the html file(s).  Is that a bug too?

On Mon, Jul 25, 2022 at 3:26 PM Gavin Smith 
wrote:

> On Mon, Jul 25, 2022 at 03:14:47PM -0700, Raymond Toy wrote:
> > On Mon, Jul 25, 2022 at 3:03 PM Gavin Smith 
> > wrote:
> >
> > > On Mon, Jul 25, 2022 at 10:56 PM Raymond Toy 
> > > wrote:
> > > >
> > > > In the maxima user manual, there are few explicit uses of @fnindex.
> > > These show up in the info file in the "Function and Variable Index" as
> > > expected.
> > > >
> > > > However, these don't show up in the corresponding "Function and
> Variable
> > > index" section in the html file.
> > > >
> > > > Is this expected?
> > >
> > > No, it's not expected at all.
> > >
> > > @findex is the more common name of the command but I expect that
> > > @fnindex should work as well.
> > >
> >
> > Maybe it's because of these:
> >
> > @synindex ky fn
> > @synindex vr fn
> > @synindex cp fn
> >
> > I don't know why they're there except to merge everything into the
> fnindex.
> >
> > But perhaps I should change them to be @findex instead, since it seems
> > that's the normal way of saying it.
>
> @synindex is there to merge the indices together, as you said.  Everything
> in the four indices should be output by "@printindex fn".
>


-- 
Ray

Re: @fnindex in html output vs info?

[Raymond Toy]

On Mon, Jul 25, 2022 at 3:03 PM Gavin Smith 
wrote:

> On Mon, Jul 25, 2022 at 10:56 PM Raymond Toy 
> wrote:
> >
> > In the maxima user manual, there are few explicit uses of @fnindex.
> These show up in the info file in the "Function and Variable Index" as
> expected.
> >
> > However, these don't show up in the corresponding "Function and Variable
> index" section in the html file.
> >
> > Is this expected?
>
> No, it's not expected at all.
>
> @findex is the more common name of the command but I expect that
> @fnindex should work as well.
>

Maybe it's because of these:

@synindex ky fn
@synindex vr fn
@synindex cp fn

I don't know why they're there except to merge everything into the fnindex.

But perhaps I should change them to be @findex instead, since it seems
that's the normal way of saying it.


-- 
Ray

Re: Default DOCTYPE?

[Raymond Toy]

On Sun, Jul 24, 2022 at 8:47 AM Patrice Dumas  wrote:

> On Sun, Jul 24, 2022 at 08:33:53AM -0700, Raymond Toy wrote:
> > It looks like texinfo 6.8 inserts:
> >
> >  > http://www.w3.org/TR/html4/loose.dtd;>
> >
> > at the beginning of each html file.
> >
> > In this day and age, shouldn't it be just ? Or does
> texinfo
> > html output really need that?
>
> This should change with the next release,  is now the
> default.
>

Oh, ok.  I can wait until then.  Not that it really matters to me; I was
just getting a warning from Chrome Lighthouse about that.  As long as
texinfo does the right thing here, I'm perfectly fine with it.

>
> > I'm not a web dev but a few times I wrote web pages, my old emacs would
> > insert the loose.dtd lines, and reviewers would say I shouldn't. It
> should
> > be the simple one.
>
> What is produced by texi2any is actually HTML 4.01 Transitional,
> compatible with HTML5.  My personnal view is that the old DTD has
> advantages over the new  for various reasons:
> * we know which HTML version it is.   (and HTML5) is
>   an evolving standard which is anything but practical.
>

Yeah, as a "living" standard, it's really hard to know what is supported.
I guess you end up having to test for everything.  Or hope the browser is
up-to-date with the current spec version of the day.

Thanks for your comments.

* offline validation is easier.  I could not find an offline validator
>   easy to install on a debian testing for HTML5.
>
> (In fact, I disagree with the directions taken by the HTML standard with
> HTML5, but that's probably off topic...).
>
> Going forward we must abide to the new practices, even if they make our
> life as developpers worse, since some day we will use HTML5 constructs
> that are not compatible with HTML 4.01 Transitional.
>
> --
> Pat
>


-- 
Ray

Re: Funny line breaking with mathjax and html

[Raymond Toy]

You can find a fairly up-to-date version here for the special functions:
https://maxima.common-lisp.dev/docs/maxima_77.html

It's a few days out of date but I'll be updating in the next few days with
the fixed html code. You might also look at the elliptic functions/
integrals, orthopoly section and the distrib section.

6.8 helped quite a bit but even with 6.7 we were able to render Mathjax
nicely.

On Sun, Jul 24, 2022, 8:56 AM Gavin Smith  wrote:

> On Sun, Jul 24, 2022 at 08:30:47AM -0700, Raymond Toy wrote:
> > On Sun, Jul 24, 2022 at 3:58 AM Gavin Smith 
> > wrote:
> >
> > > On Fri, Jul 22, 2022 at 02:58:21PM -0700, Raymond Toy wrote:
> > > > I'm getting a funny line break when displaying MathJax inline
> formulas on
> > > > an html page.  The TeX version doesn't have a line break.
> > > >
> > > > It's part of a much larger document from maxima, but the relevant
> part is
> > > > given below.   On the html page, there's a line break before "is the
> > > > solution subject".  All the other parts have no unexpected line
> breaks.
> > > > Other than that, the formulas and everything display very nicely.
> > > >
> > > > This is with texinfo 6.8.
> > > >
> > >
> > > The problem is that you are using @html as well as @ifhtml.  If you
> > > take the @html lines out the results are good.
> > >
> > Indeed it does.  Thanks!
> >
> > This example comes from maxima, and before the manual was updated to use
> > texinfo 6.8, the @html block contained html that contained the mathjax
> > formula to be shown.  Since it mostly worked when the formula was updated
> > to use @math{}, I didn't think about it.  It should all be fixed now.
>
> I'm looking forward to seeing the Maxima manual on the web with proper
> math rendering!
>

Default DOCTYPE?

[Raymond Toy]

It looks like texinfo 6.8 inserts:

http://www.w3.org/TR/html4/loose.dtd;>

at the beginning of each html file.

In this day and age, shouldn't it be just ? Or does texinfo
html output really need that?

I'm not a web dev but a few times I wrote web pages, my old emacs would
insert the loose.dtd lines, and reviewers would say I shouldn't. It should
be the simple one.


-- 
Ray

Re: Funny line breaking with mathjax and html

[Raymond Toy]

On Sun, Jul 24, 2022 at 3:58 AM Gavin Smith 
wrote:

> On Fri, Jul 22, 2022 at 02:58:21PM -0700, Raymond Toy wrote:
> > I'm getting a funny line break when displaying MathJax inline formulas on
> > an html page.  The TeX version doesn't have a line break.
> >
> > It's part of a much larger document from maxima, but the relevant part is
> > given below.   On the html page, there's a line break before "is the
> > solution subject".  All the other parts have no unexpected line breaks.
> > Other than that, the formulas and everything display very nicely.
> >
> > This is with texinfo 6.8.
> >
>
> The problem is that you are using @html as well as @ifhtml.  If you
> take the @html lines out the results are good.
>
Indeed it does.  Thanks!

This example comes from maxima, and before the manual was updated to use
texinfo 6.8, the @html block contained html that contained the mathjax
formula to be shown.  Since it mostly worked when the formula was updated
to use @math{}, I didn't think about it.  It should all be fixed now.

>
> Although using Texinfo commands like @math in @html appeared to work
> here, this is not at all recommended and the results are unpredictable.
> @html is for raw HTML only.  To my knowledge, the only Texinfo commands
> that should occur in these "raw blocks" are @@, @{ and @}, as well as
> possibly macros and conditionals.  There might be more work to be done
> here on texi2any to issue warnings for invalid command nestings.
>
> Processed with '../texi2any.pl mathjax.texi --html -c HTML_MATH=mathjax'
> for development version:
>
>
> \input texinfo
>
> These two solutions are oscillatory for @math{x < 0}.
>
> @ifhtml
> @math{{\rm Ai}(x)}
> @end ifhtml
> @ifinfo
> @math{Ai(x)}
> @end ifinfo
> @tex
> ${\rm Ai}(x)$
> @end tex
> is the solution subject to the
> condition
> @ifhtml
> @math{y\rightarrow 0}
> @end ifhtml
> @ifinfo
> @math{y -> 0}
> @end ifinfo
> @tex
> $y\rightarrow 0$
> @end tex
>  as
> @ifhtml
> @math{x\rightarrow \infty}
> @end ifhtml
> @ifinfo
> @math{x -> inf}
> @end ifinfo
> @tex
> $x\rightarrow \infty$
> @end tex
> .
> @html
> @math{{\rm Bi}(x)}
> @end html
> @ifinfo
> @math{Bi(x)}
> @end ifinfo
> @tex
> ${\rm Bi}(x)$
> @end tex
>  is the second solution with the
> same amplitude as
> @ifhtml
> @math{{\rm Ai}(x)}
> @end ifhtml
> @ifinfo
> @math{Ai(x)}
> @end ifinfo
> @tex
> ${\rm Ai}(x)$
> @end tex
>  as
> @ifhtml
> @math{x
> \rightarrow -\infty}
> @end ifhtml
> @ifinfo
> @math{x -> minf}
> @end ifinfo
> @tex
> $x
> \rightarrow -\infty$
> @end tex
>  which differs in phase by
> @ifhtml
> @math{{\pi/2}}
> @end ifhtml
> @ifinfo
> @math{%pi/2}
> @end ifinfo
> @tex
> ${\pi/2}$
> @end tex
>
>
>
> @bye
>
>

-- 
Ray

Funny line breaking with mathjax and html

[Raymond Toy]

I'm getting a funny line break when displaying MathJax inline formulas on
an html page.  The TeX version doesn't have a line break.

It's part of a much larger document from maxima, but the relevant part is
given below.   On the html page, there's a line break before "is the
solution subject".  All the other parts have no unexpected line breaks.
Other than that, the formulas and everything display very nicely.

This is with texinfo 6.8.

These two solutions are oscillatory for @math{x < 0}.

@ifhtml
@html
@math{{\rm Ai}(x)}
@end html
@end ifhtml
@ifinfo
@math{Ai(x)}
@end ifinfo
@tex
${\rm Ai}(x)$
@end tex
is the solution subject to the
condition
@ifhtml
@html
@math{y\rightarrow 0}
@end html
@end ifhtml
@ifinfo
@math{y -> 0}
@end ifinfo
@tex
$y\rightarrow 0$
@end tex
 as
@ifhtml
@html
@math{x\rightarrow \infty}
@end html
@end ifhtml
@ifinfo
@math{x -> inf}
@end ifinfo
@tex
$x\rightarrow \infty$
@end tex
.
@ifhtml
@html
@math{{\rm Bi}(x)}
@end html
@end ifhtml
@ifinfo
@math{Bi(x)}
@end ifinfo
@tex
${\rm Bi}(x)$
@end tex
 is the second solution with the
same amplitude as
@ifhtml
@html
@math{{\rm Ai}(x)}
@end html
@end ifhtml
@ifinfo
@math{Ai(x)}
@end ifinfo
@tex
${\rm Ai}(x)$
@end tex
 as
@ifhtml
@html
@math{x
\rightarrow -\infty}
@end html
@end ifhtml
@ifinfo
@math{x -> minf}
@end ifinfo
@tex
$x
\rightarrow -\infty$
@end tex
 which differs in phase by
@ifhtml
@html
@math{{\pi/2}}
@end html
@end ifhtml
@ifinfo
@math{%pi/2}
@end ifinfo
@tex
${\pi/2}$
@end tex

-- 
Ray

Re: configure mathjax for less common commands and text in math

[Raymond Toy]

On Thu, Jan 20, 2022 at 3:01 PM Patrice Dumas  wrote:

> Hello,
>
> There are some constructs that are not correctly formatted by mathjax,
> uncommon commands that can be in math and other constructs, for
> instance:
>
>   \mathord{\text{\l{}}} \textsl{\c{\'{C}}} \copyright{} \mathsterling{}
>
> Does anybody knows how to get those to work?  I tried to load amsmath
> using the ams package for mathjax, but it didn't change anything and I
> think that it is already loaded.
>

I didn't try this, but according to
https://docs.mathjax.org/en/latest/search.html?q=mathsterling_keywords=yes=default#,
Mathjax 3 doesn't support mathsterling.  It does support mathord, though.


> Those constructs are ok when in a LaTeX document with preamble
>
> \documentclass{book}
> \usepackage{imakeidx}
> \usepackage{amsfonts}
> \usepackage{amsmath}
> \usepackage[gen]{eurosym}
> \usepackage[T1]{fontenc}
> \usepackage{textcomp}
> \usepackage{graphicx}
> \usepackage{needspace}
> \usepackage{etoolbox}
> \usepackage{array}
> \usepackage{mdframed}
> \usepackage{enumitem}
> \usepackage{titleps}
> \usepackage{float}
> % use hidelinks to remove boxes around links to be similar with Texinfo TeX
> \usepackage[hidelinks]{hyperref}
> \usepackage[utf8]{inputenc}
>
> (as a side note, these is some LaTeX used to format some Texinfo
> @-commands, but it does not matter, users may want to use those commands
> in @math/@displaymath in any case).
>
> --
> Pat
>
>

-- 
Ray

Re: js-info disabling sidebar for narrow windows (experimental)

[Raymond Toy]

>>>>> "Gavin" == Gavin Smith  writes:

Gavin> On Thu, Feb 18, 2021 at 08:05:42AM -0800, Raymond Toy wrote:
>> >>>>> "Per" == Per Bothner  writes:
>> 
Per> A goal was to automatically switch to "narrow" mode on
Per> smartphones, that isn't working yet.  (Smartphone browsers tend
Per> to do magic things with "viewport" and zooming, and dealing
Per> with that needs some more research and experimentation.)
>> 
>> Yeah, that would be awesome.  When I view the html version of
>> some texinfo docs, the display is rather messed up with tiny
>> fonts in some cases.  For example,
>> https://cmucl.org/docs/cmu-user/html/index.html looks great on
>> desktop, but the stuff at the very bottom renders in super tiny
>> fonts on my phone.

Gavin> This the font "boosting" issue.

Gavin> This issue should have been dealt with in two ways.  First,
Gavin> in the current development version, a  element is not
Gavin> used to lay out a menu by default (set with the FORMAT_MENU
Gavin> option).

Gavin> I had also thought it had been fixed after this discussion.

Gavin> https://lists.gnu.org/archive/html/bug-texinfo/2020-03/msg7.html

I'm pretty sure that page was generated using texinfo 3.7.

>> I suggest adding > content="width=device-width,initial-scale=1"> to the standard
>> HTML ... block. This will make the result noticeably
>> better on mobile/pads and is, so far as I have seen, harmless on
>> larger screens.

Gavin> It would be worth checking that both of these changes have
Gavin> happened properly.

Yes, the viewport ought to be set.

Still, while I'm dreaming, texinfo could do these for me since it's
generating the html files.  Ideally, texinfo would produce ok results
by default, and let the author fine tune things as needed.

But since I'm not actually contributing to fixing these issues, feel
free to ignore me. :-)

--
Ray

Re: js-info disabling sidebar for narrow windows (experimental)

[Raymond Toy]

> "Per" == Per Bothner  writes:

Per> A goal was to automatically switch to "narrow" mode on
Per> smartphones, that isn't working yet.  (Smartphone browsers tend
Per> to do magic things with "viewport" and zooming, and dealing
Per> with that needs some more research and experimentation.)

Yeah, that would be awesome.  When I view the html version of some
texinfo docs, the display is rather messed up with tiny fonts in some
cases.  For example, https://cmucl.org/docs/cmu-user/html/index.html
looks great on desktop, but the stuff at the very bottom renders in
super tiny fonts on my phone.

I have played around with making some html pages work nicely on desktop
and mobile, but I'm not a web dev, so it took a lot of googling and
experimenting to get something to look reasonable.  And these were plain
html, not pages generated by texinfo.

--
Ray

@var{x_1} is funny in pdf

[Raymond Toy]

This came up recently on the maxima list where @var{x_1} shows up fine
in html but looks weird in the pdf file.  For example,
https://maxima.sourceforge.io/docs/manual/maxima.pdf, page 55,
documentation of the 'create_list'-command.  The line for the
create_list function looks fine, but the first sentence shows @var{x_1}
in a funny way.

(The html version at
https://common-lisp.net/project/maxima/docs/maxima_21.html#index-create_005flist
looks fine.)

Is this an issue with texinfo or how @var{} is being used?

--
Ray

Re: HTML self links to anchor points

[Raymond Toy]

On Tue, Nov 3, 2020 at 11:57 AM Gavin Smith 
wrote:

> On Tue, Nov 03, 2020 at 07:53:08AM -0800, Raymond Toy wrote:
>
> > > I think links for @anchor is important since it's something the author
> had
> > > to say explicitly, so having that available in html seems appropriate.
> > > Perhaps I'll change my mind after I see what you've done so far.
> > >
> > Having seen these new links, I'm not sure what to do about anchors.  In
> > maxima's manual, the anchors often point to the first entry of a deffoo.
> > So now there would be two links to the same place, with different ids.
> In
> > this case, it's not terrible.  But if there's an @ref to some @anchor, to
> > get the link you'd have to find any @ref pointing the anchor to get the
> > link.  That's not so convenient.
>
> For @def* and @*table there is a clear "heading" which the link can
> be attached to.  In contrast, @anchors (like index entries) could be
> anywhere.  I don't think it would always look good to have a copiable
> anchor link (what do you call these things? - "permalink" seems to be
> promising too much) and there may not be a good place to put them.
> As with index entries, I feel that @anchors should be invisible at
> the target (although it would be interesting to see any examples from
> documents where having a copiable link for an @anchor would work well).
>

Hard to say.  I'm partially guided by what some W3C specs do.  For example,
https://www.w3.org/TR/webaudio/#render-quantum
This link defines what a "render quantum" is, and clicking on it also
brings up a list of where this term is referenced and also provides a link
to be copied. I think this is useful.

However, I'm not saying this needs to be implemented in texinfo.

>
> Texinfo's own manual mainly uses @anchor for renamed nodes so that
> old links still work.  Copiable links here would not be useful.
>

I think maxima's manual is essentially the same.  All the anchors are
basically placed just before some deffoo.


-- 
Ray

Re: HTML self links to anchor points

[Raymond Toy]

On Mon, Nov 2, 2020 at 2:32 PM Raymond Toy  wrote:

>
>
> On Sun, Nov 1, 2020 at 1:02 PM Gavin Smith 
> wrote:
>
> I've gone and implemented it anyway (in commit b9920b16), because I
>> wanted to see what it would be like.  It is for @def* commands only
>> at the moment, not for @anchor or for section headings.  Turn it off
>> with the -c PERMALINKS=0 option (variable name subject to change).
>>
>
> I'll try this out soon.  I think having such links is really important for
> the html version.
>

I tried this out using the maxima manual.  This  looks nice and  works very
well!  Not sure I like the fact that I can only see the link when I hover
over the item.  I didn't check on a mobile device, but if this is how it
works on mobile, that's not so good.  Presumably, I can change this
behavior with a bit of CSS.

>
> I think links for @anchor is important since it's something the author had
> to say explicitly, so having that available in html seems appropriate.
> Perhaps I'll change my mind after I see what you've done so far.
>
Having seen these new links, I'm not sure what to do about anchors.  In
maxima's manual, the anchors often point to the first entry of a deffoo.
So now there would be two links to the same place, with different ids.  In
this case, it's not terrible.  But if there's an @ref to some @anchor, to
get the link you'd have to find any @ref pointing the anchor to get the
link.  That's not so convenient.

-- 
Ray

Re: HTML self links to anchor points

[Raymond Toy]

On Sun, Nov 1, 2020 at 1:02 PM Gavin Smith  wrote:

> On Sun, Nov 01, 2020 at 05:18:24PM +, Gavin Smith wrote:
> > On Sat, Oct 31, 2020 at 03:16:26PM -0700, Per Bothner wrote:
> > > On 10/31/20 2:26 PM, Gavin Smith wrote:
> > > > Feel free not to consider it if you find implementing your desired
> > > > functionality enough, but there has also been discussion of
> outputting
> > > > an "anchor" at def items to provide a link that could be copied:
> > > >
> > > > https://lists.gnu.org/archive/html/bug-texinfo/2020-09/msg00022.html
> > > >
> > > > It would be good if this could be implemented with CSS too.
> > >
> > > I'm dubious CSS can add a link, but it can easily be done with
> JavaScript.
> > > Or you can have makeinfo create the link.
> >
> > You're right, there doesn't seem to any way to do it with CSS.  The
> > ::after and ::before selectors only support adding plain text, no tags.
> >
> > I am not sure if an anchor link should be output by default, or even
> > if there should be an option for it.  It could make the experience
> > worse when browsing the HTML in a text terminal, e.g. with lynx.  They
> > could get in the way of selecting another link with the keyboard.  Where
> > CSS is not available the anchor links would be visible all the time.
> >
> > Perhaps anchor links could be generated by Javascript for those who
> > want to use them.  They could also postprocess the output of texi2any.
>

Not everyone has Javascript enabled either.

>
> I've gone and implemented it anyway (in commit b9920b16), because I
> wanted to see what it would be like.  It is for @def* commands only
> at the moment, not for @anchor or for section headings.  Turn it off
> with the -c PERMALINKS=0 option (variable name subject to change).
>

I'll try this out soon.  I think having such links is really important for
the html version.

I think links for @anchor is important since it's something the author had
to say explicitly, so having that available in html seems appropriate.
Perhaps I'll change my mind after I see what you've done so far.


-- 
Ray

Re: Texinfo TeX accepts LaTeX math, how?

[Raymond Toy]

On Mon, Oct 26, 2020 at 9:45 AM Gavin Smith 
wrote:

> On Mon, Oct 26, 2020 at 11:58:56AM +0100, Patrice Dumas wrote:
> > Hello,
> >
> > Surprisingly (for me), the @displaymath example in the Texinfo manual
> > works when producing a pdf using texi2dvi.  However, it uses \frac{}{},
> > which is not not a plain TeX construct, as far as I know.  How is that
> > possible?  If the math in Texinfo is "LaTeX math" it is much simpler for
> > writers, as "plain TeX math" is less known that "LaTeX math" but also
> > for math rendering in HTML, as it means that latex2html can be used
> > without trouble and htlatex can be used instead of httex.
>
> I added \frac to texinfo.tex very recently as it is easy to implement
> and probably the most missed LaTeX command by far.  However, it could
> be confusing to use in the manual as it wouldn't get over that plain
> TeX should be used.
>

Being able to use \frac is pretty confusing.  If \frac worked, I would
naively expect all the other latex commands to work, but it doesn't.

I've never actually used plain tex (until very recently to write math with
texinfo), and googling for how to write math with plain tex is hard because
searches almost always brings up variants on latex or amstex. So having
@math and friends support latex (or amstex) would be ideal.  Until then,
I'll have to continue to add various iffoo to control the input form of the
math when using info, pdf, and html output.

>
> > If it is not the same as LaTeX math, but a superset of plain TeX math,
> > could you tell me how I can modify the TeX file produced by tex4ht.pm
> > for httex such that there is support of the same constructs in math
> > rendering through tex4ht?  Right now, \frac appears as undefined when
> > processing with httex.
>
> In that case it would be simpler just to use \over in the example.
> Another option is to use htlatex instead (if there is such a program),
> but that could be problematic if there are any important usages of
> plain TeX that don't work with LaTeX.
>
>

-- 
Ray

Re: MathJax support in texi2any

[Raymond Toy]

On Thu, Oct 8, 2020 at 12:37 PM Gavin Smith 
wrote:

> On Thu, Oct 08, 2020 at 12:26:28PM -0700, Raymond Toy wrote:
> > Does this also mean I can use AMSTeX features in @math?  I guess that
> also
> > means I still need @iftex and @ifhtml versions since tex output only
> > understands plain TeX, right?  Still this is a very nice feature!
>
> I couldn't tell you about AMSTeX (or other LaTeX macros) with MathJax, but
> it wouldn't work with TeX output unless the macros were defined.
>

Played around a bit.  This does look quite nice.  As others have mentioned,
a @displaymath would be very nice.

Since maxima's manual supports info, pdf, and html output, it has been
quite a bit of work to keep it all organized.  Until now, we didn't really
expect @math to do anything special for pdf and html.  But now that it can,
it's really tempting to use plain tex in @math to get nice inline formulas
for pdf and html. But these may not look so good in info format.

I think it's ok if someone wants to use the full capabilities of MathJax or
to have readable math in info files, then they'll have to do the
appropriate set of @iffoo @end iffoo.  Not great, but I don't see how you
can have @math with TeX that also would produce something nice for info.

For maxima, I think that instead of @math{\int_0^1 x dx}, we'd want to say
in maxima syntax 'integrate(x,x,0,1)', which probably wouldn't be done
using @math at all.

-- 
Ray

Re: MathJax support in texi2any

[Raymond Toy]

On Thu, Oct 8, 2020 at 9:31 AM Gavin Smith  wrote:

> On Thu, Oct 08, 2020 at 08:06:05AM -0700, Raymond Toy wrote:
> > On Wed, Oct 7, 2020 at 12:01 PM Gavin Smith 
> > wrote:
> >
> > > I've implemented basic MathJax support in texi2any in commit
> > > 7ff3cbdc4. To use it, run texi2any as "texi2any --html -c
> > > HTML_MATH=mathjax". Feedback would be appreciated on how well it works
> > > with Texinfo manuals containing math typesetting.
> > >
> >
> > This is really great news!  Maxima's manual has many formulas, but
> they're
> > all wrapped in @ifhtml and @iftex.
> >
> > With this new version, how do I get formulas typeset?  @math?  Something
> > else?
>
> Just use @math with no conditional.
>
> I downloaded maxima 5.44.0 and to build the documentation without building
> the package, I did
>
> texi2any.pl --html maxima.texi --no-validate -c HTML_MATH=mathjax
>
> and this worked.  For example, the file
> maxima/Functions-and-Variables-for-zeilberger.html in the output
> had math displayed OK in most cases if JavaScript is enabled (although
> there
> may be a few problems I need to look at).
>

This is really awesome!  And thanks for testing it out; I'll try myself
soon.

Does this also mean I can use AMSTeX features in @math?  I guess that also
means I still need @iftex and @ifhtml versions since tex output only
understands plain TeX, right?  Still this is a very nice feature!


-- 
Ray

Re: MathJax support in texi2any

[Raymond Toy]

On Wed, Oct 7, 2020 at 12:01 PM Gavin Smith 
wrote:

> I've implemented basic MathJax support in texi2any in commit
> 7ff3cbdc4. To use it, run texi2any as "texi2any --html -c
> HTML_MATH=mathjax". Feedback would be appreciated on how well it works
> with Texinfo manuals containing math typesetting.
>

This is really great news!  Maxima's manual has many formulas, but they're
all wrapped in @ifhtml and @iftex.

With this new version, how do I get formulas typeset?  @math?  Something
else?

I can also try this out this weekend.

>
> I think the main concern at the moment is making sure that the source
> code for MathJax is easily accessible from pages that reference it,
> and that users do not need to be dependent on MathJax's hosting.
>
>

-- 
Ray

Re: HTML self links to anchor points

[Raymond Toy]

On Mon, Sep 21, 2020 at 1:38 PM Gavin Smith 
wrote:

> On Mon, Sep 21, 2020 at 12:17:35PM -0700, Raymond Toy wrote:
> > Using CSS is fine too for deffn and friends instead of anchor.  But this
> > seems hard because I don't have a good way of figuring out where to put
> > such links.  AFAICT, the link is basically  id="Item_section+deffn">.
> > If it said , then I could do something.
>
> Yes, I was thinking that there would have to be some change to texi2any.
>

That would be really awesome!  If you should implement this, please ping me
for testing; I'd love to try it out.

Not sure if it matters, but perhaps allowing a distinction between deffn,
defvar, and anchor would be useful so each manual can distinguish between
them and perhaps do something different.  Anchors are interesting because
it's a hint that the author thought it important enough to add an anchor
for an item.

(Wish I had more time to hack on this.)


-- 
Ray

Re: HTML self links to anchor points

[Raymond Toy]

On Sun, Sep 20, 2020 at 1:24 AM Gavin Smith 
wrote:

> On Wed, Sep 16, 2020 at 04:32:23PM -0700, Raymond Toy wrote:
> > For example you can navigate to
> >
> https://common-lisp.net/project/maxima/docs/maxima_singlepage.html#Item_003a-Bugs_002fdeffn_002frun_005ftestsuite
> > and this works just fine.
> >
> > But once you get there and maybe scroll around a bit to look for other
> > functions or variables, you can't easily get a link to the
> > function/variable/section.  Currently, you have to go to the index to
> find
> > a link to the thing.
> >
> > These entries all have @anchor{}, so it would be really nice if the HTML
> > doc could add some kind of self-link so that when I find what I want, I
> can
> > copy the link and share it with someone.
>
> I agree that this could be a useful feature.  I don't think it should be
> done with @anchor{} but maybe with @deffn, @defop etc.  The interface
> could be an icon that appears when you mouse over the text, as at
>
>
> https://docs.readthedocs.io/en/stable/intro/getting-started-with-sphinx.html


That looks nice and would certainly fine with me.

>
>
> where mousing over any heading pops up such an icon.  E.g. at
>
>
> https://common-lisp.net/project/maxima/docs/maxima_singlepage.html#Functions-and-Variables-for-Bug-Detection-and-Reporting
>
> mousing over the "Function: run_testsuite" could pop up such an icon.
> This should be possible with CSS as this still works on the page linked
> above even when JavaScript is disabled.
>

Using CSS is fine too for deffn and friends instead of anchor.  But this
seems hard because I don't have a good way of figuring out where to put
such links.  AFAICT, the link is basically .
If it said , then I could do something.




-- 
Ray

HTML self links to anchor points

[Raymond Toy]

For example you can navigate to
https://common-lisp.net/project/maxima/docs/maxima_singlepage.html#Item_003a-Bugs_002fdeffn_002frun_005ftestsuite
and this works just fine.

But once you get there and maybe scroll around a bit to look for other
functions or variables, you can't easily get a link to the
function/variable/section.  Currently, you have to go to the index to find
a link to the thing.

These entries all have @anchor{}, so it would be really nice if the HTML
doc could add some kind of self-link so that when I find what I want, I can
copy the link and share it with someone.

-- 
Ray

Re: viewport declaration

[Raymond Toy]

I am no expert, but yes, I think it does. I added that to some other
website and the fonts were consistently sized. (I've since changed the site
to do something different, but it definitely helped.)

I'll test it out soon.

On Fri, Mar 27, 2020 at 4:08 AM Gavin Smith 
wrote:

> On Thu, Mar 26, 2020 at 10:56 PM Karl Berry  wrote:
> >
> > Gavin - I suggest adding
> > 
> > to the standard HTML ... block. This will make the result
> > noticeably better on mobile/pads and is, so far as I have seen, harmless
> > on larger screens.
> >
> > It looks like this would be in tp/Texinfo/Convert/HTML.pm,
> > where the charset http-equiv is output. FWIW ... --best, karl.
>
> I will certainly add it but could you explain what difference it
> makes? Does this fix the "font boosting" issue?
> (https://lists.gnu.org/archive/html/bug-texinfo/2019-06/msg0.html)
>
>

-- 
Ray

Re: Feature request: self links for sections

[Raymond Toy]

On Mon, Mar 2, 2020 at 12:07 AM Eli Zaretskii  wrote:

> (Why private email?)
>


Oops. That was unintentional.  Adding bug-texinfo back in.

>
> > From: Raymond Toy 
> > Date: Sun, 1 Mar 2020 17:33:58 -0800
> >
> > Not if I scrolled around and then found the section I really wanted.
>
> But that's not how you are supposed to read a manual, is it?
>

It is when the section titles aren't exactly what your looking for.  It's
much easier to scroll around the web page than to click on navigation
buttons moving you around in random ways.  It's much easier to scan text
while scrolling to find what I want.

Or what if I just did a text search in the browser for the keywords that
I'm looking for.  I eventually end up in some appropriate section.  Now I
want to send the section link to someone.


-- 
Ray

Feature request: self links for sections

[Raymond Toy]

A bit of a feature request for texinfo files converted to html.

For example, visit
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Writing-a-Texinfo-File.
You get to section "2 Writing a Texinfo File".  This is fine.  But it would
be nice if I could click on the title (or something) to get a link to that
section.

For example, visit https://webaudio.github.io/web-audio-api/#AudioContext.
You can click on the character at the very left to get a link to this
section.  Really handy when you want to send a link to someone.

-- 
Ray

Re: Math in texinfo files?

[Raymond Toy]

On Tue, Jan 14, 2020 at 10:42 AM Gavin Smith 
wrote:

> On Mon, Jan 13, 2020 at 9:40 PM Raymond Toy  wrote:
> >
> > I'm currently trying to write nice equations in some texinfo files.
> I've been using MathJax to generate the formulas for the html version of
> the doc.  However, since the TeX version of the doc doesn't use LaTeX, I
> have to either have different formulas for the html version and TeX
> version.  Sometimes I can use the same if I remember how to write a
> plain-TeX version that will work in MathJax.  But LaTeX with AMSTeX is so
> much easier to get equations arranged nicely.
> >
> > Any way to get that?  I'm assuming not since the TeX version really is
> just plain-TeX.
>
> Not really. Maybe some day Texinfo will have a LaTeX back-end but that
> would only work for outputting to LaTeX, not for other formats.
>
> The main difference as far as I am aware is that there is no such
> command as \frac in plain TeX. Maybe you could get around this with
> something like
>
> @tex
> \gdef\frac#1#2{{#1}\over{#2}}%
> @end tex
>
> Yeah, instead of defining this, I just converted the formula to use \over
for both TeX and LaTeX.  This works.


> (I haven't tested this). Of course, as you use more and more LaTeX
> features, this approach becomes increasingly impossible.
>

Although I haven't had to use it yet, but amstex makes formatting math much
easier for complicated cases.  I guess if I want not to duplicate formulas,
I'll have to learn plain TeX to do math and use it for both.  Googling for
math stuff almost always points to LaTeX and/or AMSTeX solutions, not plain
TeX.

>
> > (Does any one really use plain TeX anymore?)
>
> I have to use it to maintain Texinfo ;-) and of course anybody
> developing LaTeX or its packages has to understand it (although AFAIK
> LaTeX is not based on "plain TeX" per se), or any other "higher-level"
> format like ConTeXt.
>


-- 
Ray

Re: Texinfo 6.7 released

[Raymond Toy]

Thanks for the fix.  Everything works just fine now!

On Fri, Sep 27, 2019 at 4:54 AM Gavin Smith 
wrote:

> On Fri, Sep 27, 2019 at 7:09 AM Raymond Toy  wrote:
> > I can build texinfo from these files without any problems.
> >
> > However, if I use the git repo I can't.  I checked out the tag
> texinfo-6.7 and ran autogen.sh and get this error:
> >
> > Preparing Texinfo development infrastructure:
> >   ./tp/maintain/regenerate_file_lists.pl
> >   (cd tp && ./maintain/regenerate_docstr.sh Makefile.docstr)
> >   (cd tp/tests && ../maintain/regenerate_cmd_tests.sh Makefile.onetst .
> -base 'formatting sectioning indices nested_formats contents layout'
> -tex_html 'tex_html')
> >   aclocal -I gnulib/m4 && autoconf && autoheader && automake
> > missing file gnulib/lib/windows-mutex.c
> > configure.ac:90: error: expected source file, required through
> AC_LIBSOURCES, not found
> > gnulib/m4/gnulib-comp.m4:156: gl_INIT is expanded from...
> > configure.ac:90: the top level
> > autom4te: /usr/bin/m4 failed with exit status: 1
> > aclocal: error: echo failed with exit status: 1
>
>
> Thank for the report. What I have done is committed the files and
> moved the texinfo-6.7 tag. If you delete the local copy of the tag and
> check it out again, it should work now.
>


-- 
Ray

Re: Texinfo 6.7 released

[Raymond Toy]

On Mon, Sep 23, 2019 at 12:29 PM Gavin Smith 
wrote:

> We have released version 6.7 of Texinfo, the GNU documentation format.
>
> This package contains tools to produce documentation in various
> formats, including HTML and PDF, from source files in the Texinfo
> format.  Texinfo is a text-based format with commands for marking text,
> document structuring and indexing.
>
> The highlight of this release is improved indexing facilities.
>
>   http://ftpmirror.gnu.org/texinfo/texinfo-6.7.tar.xz
>   http://ftpmirror.gnu.org/texinfo/texinfo-6.7.tar.gz


I can build texinfo from these files without any problems.

However, if I use the git repo I can't.  I checked out the tag texinfo-6.7
and ran autogen.sh and get this error:

Preparing Texinfo development infrastructure:
  ./tp/maintain/regenerate_file_lists.pl
  (cd tp && ./maintain/regenerate_docstr.sh Makefile.docstr)
  (cd tp/tests && ../maintain/regenerate_cmd_tests.sh Makefile.onetst .
-base 'formatting sectioning indices nested_formats contents layout'
-tex_html 'tex_html')
  aclocal -I gnulib/m4 && autoconf && autoheader && automake
missing file gnulib/lib/windows-mutex.c
configure.ac:90: error: expected source file, required through
AC_LIBSOURCES, not found
gnulib/m4/gnulib-comp.m4:156: gl_INIT is expanded from...
configure.ac:90: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1

I used to be able to build from the git tree without problems.

>
> If automatic redirection fails, the list of mirrors is at:
>   https://www.gnu.org/prep/ftp.html
>
> Failing that, you can use the main server:
>   https://ftp.gnu.org/gnu/texinfo/texinfo-6.7.tar.xz
>   https://ftp.gnu.org/gnu/texinfo/texinfo-6.7.tar.gz
>
> Please email any comments to bug-texinfo@gnu.org.
> The Texinfo web page: https://www.gnu.org/software/texinfo/
>
> Full news:
> * Language:
>   . support of index subentries and sub-subentries with @subentry
>   . new commands @seeentry and @seealso in index entries
>   . no need to wrap Top node in @ifnottex - omitted automatically when
> processed with TeX
>   . UTF-8 is the default input encoding
>
> * texi2any
>   . for HTML output, mark index nodes in menus and tables of contents
> with the 'rel' attribute of the 'a' tag.
>   . TOP_NODE_UP is now only used in HTML if TOP_NODE_UP_URL is set.
> Also TOP_NODE_UP should now be formatted in the output format.
> In HTML TOP_NODE_UP should be suitable for inclusion in HTML
> element attributes, so for instance should not contain elements.
>   . support of noderename.cnf files has been removed
>   . INPUT_PERL_ENCODING, INPUT_ENCODING_NAME, NODE_FILE_EXTENSION,
> NODE_FILENAMES, SHORTEXTN and TOP_NODE_FILE removed as customization
> variables.
>   . TOP_NODE_FILE_TARGET now contains the extension.
>   . error messages translated when the XS parser module is in use
>
> * texi2dvi
>   . unconditionally run in --batch mode, i.e. without stopping if there
> is a TeX error
>   . keep on going after a TeX error if the index files changed
>   . with --tidy (or --build-dir), avoid reading index files from previous
> runs where --tidy was not used
>
> * info
>   . for a tree search (with M-/), '}' and '{' work as well as 'M-}' and
> 'M-{' to go through the results
>
> * Distribution:
>   . Several obsolete portability checks removed
>   . gettext 0.20.1, automake 1.16.1
>
>

-- 
Ray

Re: Output files for html?

[Raymond Toy]

Thanks!  That works great.

On Sat, Jun 22, 2019 at 12:00 AM Patrice Dumas  wrote:

> On Fri, Jun 21, 2019 at 11:52:03AM -0700, Raymond Toy wrote:
> > In version 6.6, if you had
> >
> > @setfilename foo.info
> >
> > all of the html files would be placed in the foo directory with names
> > foo_0.html, foo_1.html, and so on.
> >
> > With 6.6dev, this isn't true anymore.  The foo directory contains things
> > like index.html, section-title-1.html, section-title-2.html, and so on.
> >
> > Was this change intentional?  Is it possible to get back the old version?
>
> I think that this change was intentional.  To get back to the old
> version, you would need an init file, I believe.  I attach one which
> should do what you want, except maybe for the top file.
>
> you can use it with
>
> texi2any --html --init file_names_simple.pm toto.texi
>
> (As a side note, my guess would be that you do not have nodes in your
> texinfo file, otherwise you would have seen the "new behaviour" earlier).
>
> > In addition, a very old version of texi2html (was used in Maxima for a
> long
> > time) put the table of contents in foo_toc.html.  This was useful for
> > external interfaces to maxima to have a table of contents that could be
> > shown.  Right now, the toc is placed in one of the foo_*.html files.
>
> For that, you can set
>   -c INLINE_CONTENTS=0
>
> If you want more generally the texi2html style, you can use
>  -c TEXI2HTML
>
> --
> Pat
>


-- 
Ray

Output files for html?

[Raymond Toy]

In version 6.6, if you had

@setfilename foo.info

all of the html files would be placed in the foo directory with names
foo_0.html, foo_1.html, and so on.

With 6.6dev, this isn't true anymore.  The foo directory contains things
like index.html, section-title-1.html, section-title-2.html, and so on.

Was this change intentional?  Is it possible to get back the old version?

In addition, a very old version of texi2html (was used in Maxima for a long
time) put the table of contents in foo_toc.html.  This was useful for
external interfaces to maxima to have a table of contents that could be
shown.  Right now, the toc is placed in one of the foo_*.html files.

-- 
Ray

Tiny links for html pages on mobile

[Raymond Toy]

Visit, say,
https://common-lisp.net/project/cmucl/docs/cmu-user/html/Floats.html#Floats on
a mobile phone.  Everything looks quite nice but if if scroll down to the
bottom, the links to the next sections are super tiny.  When viewed on
desktop, this looks great.

This was created with 6.6dev.

-- 
Ray

Re: Feature request: multilevel indexing for TeX

[Raymond Toy]

On Sun, May 19, 2019 at 8:44 AM Raymond Toy  wrote:

> Thanks for looking into this.  I think I'm getting confused on which
> version of makeinfo and texindex.tex is getting used. (I have 3 version on
> my system).
>

Redid this on a different system which had just one installed texinfo.  I
installed the dev version into its own prefix, and everything works fine.
The multi-level index looks great and of course works fine with html (in a
different fashion, of course).

Not sure what's going on with my other system, but I'm quite happy with the
results on this system.

Thanks for your hard work on this!

>
> I think the issue I reported here is that I was using pdftex to create the
> doc.  Using makeinfo --pdf doesn't have that problem. But it complains
> about something else. I want to make sure it's from the dev texinfo stuff
> and not some older 6.6 (or earlier) version.
>
> On Sun, May 19, 2019 at 2:54 AM Gavin Smith 
> wrote:
>
>> On 5/18/19, Raymond Toy  wrote:
>> > With my old hack.  With the new texinfo, I changed the macro to say
>> >
>> > @cindex \topic\ @subentry \subtopic\
>> >
>> > makeinfo --pdf foo.texi
>> >
>> > has errors like:
>> >
>> > Unde
>> > fined control sequence.
>> > \temp ->\xeatspaces {unix} \subentry
>> >  \xeatspaces { pathnames}
>> > \dosubindwrite ...mpty \xdef \indexsortkey {\temp
>> >   }\ifx \indexsortkey
>> > \empty...
>> >
>> > \safewhatsit ... \else \vskip -\whatsitskip \fi #1
>> >   \ifx \lastskipmacro
>> > \zeros...
>> >
>> > \dosubind ...dcsname }\safewhatsit \dosubindwrite
>> >   }\fi
>> > l.2 ...s {unix} @subentry @xeatspaces { pathnames}
>> >
>> > \scanmacro ...\\=\active \scantokens {#1@texinfoc}
>> >   \aftermacro \catcode
>> > `\@=\...
>> > l.1657 @cpsubindex{unix, pathnames}
>>
>> I couldn't reproduce the problem. I found that @subentry worked OK
>> with macros, although it is not surprising that there should be a
>> problem here.
>>
>
>
> --
> Ray
>


-- 
Ray

Re: Feature request: multilevel indexing for TeX

[Raymond Toy]

Thanks for looking into this.  I think I'm getting confused on which
version of makeinfo and texindex.tex is getting used. (I have 3 version on
my system).

I think the issue I reported here is that I was using pdftex to create the
doc.  Using makeinfo --pdf doesn't have that problem. But it complains
about something else. I want to make sure it's from the dev texinfo stuff
and not some older 6.6 (or earlier) version.

On Sun, May 19, 2019 at 2:54 AM Gavin Smith 
wrote:

> On 5/18/19, Raymond Toy  wrote:
> > With my old hack.  With the new texinfo, I changed the macro to say
> >
> > @cindex \topic\ @subentry \subtopic\
> >
> > makeinfo --pdf foo.texi
> >
> > has errors like:
> >
> > Unde
> > fined control sequence.
> > \temp ->\xeatspaces {unix} \subentry
> >  \xeatspaces { pathnames}
> > \dosubindwrite ...mpty \xdef \indexsortkey {\temp
> >   }\ifx \indexsortkey
> > \empty...
> >
> > \safewhatsit ... \else \vskip -\whatsitskip \fi #1
> >   \ifx \lastskipmacro
> > \zeros...
> >
> > \dosubind ...dcsname }\safewhatsit \dosubindwrite
> >   }\fi
> > l.2 ...s {unix} @subentry @xeatspaces { pathnames}
> >
> > \scanmacro ...\\=\active \scantokens {#1@texinfoc}
> >   \aftermacro \catcode
> > `\@=\...
> > l.1657 @cpsubindex{unix, pathnames}
>
> I couldn't reproduce the problem. I found that @subentry worked OK
> with macros, although it is not surprising that there should be a
> problem here.
>


-- 
Ray

Re: Support for package names in defvr/deffn

[Raymond Toy]

A @sortas for this would be a nice addition.

But anyway, your solution would work fine.  For one project I already use
m4 macros to do things that texinfo can't so I just to write some more for
this case.

Thanks!


On Sun, May 19, 2019 at 2:44 AM Gavin Smith 
wrote:

> On 5/18/19, Raymond Toy  wrote:
> > In writing/updating an old doc to use texinfo, there are entries like
> >
> > @defvr Constant extensions:short-float-positive-infinity
> > @defvrx Constant extensions:short-float-negative-infinity
> > @defvrx Constant extensions:single-float-positive-infinity
> >
> > This all works, but the Common Lisp package name "extensions" causes
> > everything to be added to the index all at the same place.  Is there a
> way
> > to make this ignore the package name "extensions".
>
> I don't think so. I think the best way to support this would be to
> have a command that would output just like @defvr but would not create
> an index entry. The index entry would have to be created separately.
>
> A workaround is not to use the vr index at all and to create index
> entries in a separate index, like this:
>
> @defcodeindex va
>
> @vaindex short-float-positive-infinity
> @vaindex short-float-negative-infinity
> @vaindex single-float-positive-infinity
> @defvr Constant extensions:short-float-positive-infinity
> @defvrx Constant extensions:short-float-negative-infinity
> @defvrx Constant extensions:single-float-positive-infinity
>
> And output the index with "@printindex va" instead of "@printindex vr".
>


-- 
Ray

Support for package names in defvr/deffn

[Raymond Toy]

In writing/updating an old doc to use texinfo, there are entries like

@defvr Constant extensions:short-float-positive-infinity
@defvrx Constant extensions:short-float-negative-infinity
@defvrx Constant extensions:single-float-positive-infinity

This all works, but the Common Lisp package name "extensions" causes
everything to be added to the index all at the same place.  Is there a way
to make this ignore the package name "extensions". The old latex doc that
this came used a macro to have an optional package name that was used for
printing, but the index only included the symbol name.

Anything like that for texinfo?

-- 
Ray

Re: Feature request: multilevel indexing for TeX

[Raymond Toy]

Found a small issue and I'm not sure of the cause. I can easily workaround
this since @subentry works for all output formats that I care about (pdf,
html, info).

Before @subentry was available I used this macro:

@macro cpsubindex {topic,subtopic}
@iftex
@cindex \topic\!\subtopic\
@end iftex
@ifnottex
@cindex \topic\, \subtopic\
@end ifnottex
@end macro

With my old hack.  With the new texinfo, I changed the macro to say

@cindex \topic\ @subentry \subtopic\

makeinfo --pdf foo.texi

has errors like:

Unde
fined control sequence.
\temp ->\xeatspaces {unix} \subentry
 \xeatspaces { pathnames}
\dosubindwrite ...mpty \xdef \indexsortkey {\temp
  }\ifx \indexsortkey
\empty...

\safewhatsit ... \else \vskip -\whatsitskip \fi #1
  \ifx \lastskipmacro
\zeros...

\dosubind ...dcsname }\safewhatsit \dosubindwrite
  }\fi
l.2 ...s {unix} @subentry @xeatspaces { pathnames}

\scanmacro ...\\=\active \scantokens {#1@texinfoc}
  \aftermacro \catcode
`\@=\...
l.1657 @cpsubindex{unix, pathnames}

I'm assuming the macro call @cpsubindex{unix, pathnames} expands into

@cindex {unix} @subentry @xeatspaces { pathnames}

and that @xeatspaces is causing problems.

It's easy enough for me to work around this by just globally replacing
@cpsubindex{foo, bar} with @cindex foo @subentry bar


On Fri, May 10, 2019 at 12:41 AM  wrote:

> You're welcome. Gavin did most of the work.
>
> I've revised (but not yet merged) the index for the gawk manual to take
> advantage of the new features, and it too looks wonderful. I'm pleased
> with the new features and am glad other people are using them too.
>
> Regards,
>
> Arnold
>
> Raymond Toy  wrote:
>
> > Thanks so much for implementing this!  I can get rid of the hacks I had
> and
> > make use of it in other docs.
> >
> > I did use this new version to generate Maxima's manual in pdf.  The index
> > entries and subentries look fine for the most part, but there are a few
> > oddities.  I don't know if I messed up or if it's a bug in texinfo.
> When I
> > isolate the problem, I'll let you know.
> >
> > But in general it looks fantastic!  And much better than the hack I was
> > using!
> >
> >
> > On Sun, Apr 28, 2019 at 2:20 AM Gavin Smith 
> > wrote:
> >
> > > On Sun, Apr 28, 2019 at 02:33:25AM -0600, arn...@skeeve.com wrote:
> > > > Gavin Smith  wrote:
> > > >
> > > > > On Sat, Mar 02, 2019 at 04:33:30PM +, Gavin Smith wrote:
> > > > > > Implemented as @subentry in git commit 372cfab.
> > > > > >
> > > > > > A test file is attached. Please feel free to experiment.
> > > > > >
> > > > > > It still needs to be implemented in texi2any, once the syntax is
> > > > > > finalised. Volunteers are welcome.
> > > > >
> > > > > I've added some support for @seeentry and @seealso in index
> entries in
> > > > > texi2any.  They are ignored except for DocBook output.
> > > >
> > > > Truly awesome!!!
> > > >
> > > > How do mean "ignored"?  Do you simply remove the @subentry and use
> > > > the rest of the line as the index text, in Info, for example?
> > >
> > > I mean entries with @seeentry and @seealso do not add any index entries
> > > for HTML and Info output.  @subentry isn't ignored.
> > >
> > > > I'd suggest something like  s/ *@subentry +/, /g   in sed syntax
> > > > for Info, if that makes sense to you.
> > >
> > > In HTML and Info output, this is what is done already - the parts are
> > > separated by commas.
> > >
> > > > And once again, a huge THANK YOU for working with me to add this
> feature
> > > > to Texinfo.  I have been working on the gawk manual's index to take
> > > > advantage of this and it makes for an incredible improvement.
> > >
> > > That is very good to hear.  Thank you for suggesting the new features
> > > and working to implement them in texindex.  I'm sure others will find
> > > them useful too.
> > >
> > >
> >
> > --
> > Ray
>


-- 
Ray

Re: Feature request: multilevel indexing for TeX

[Raymond Toy]

Thanks so much for implementing this!  I can get rid of the hacks I had and
make use of it in other docs.

I did use this new version to generate Maxima's manual in pdf.  The index
entries and subentries look fine for the most part, but there are a few
oddities.  I don't know if I messed up or if it's a bug in texinfo.  When I
isolate the problem, I'll let you know.

But in general it looks fantastic!  And much better than the hack I was
using!


On Sun, Apr 28, 2019 at 2:20 AM Gavin Smith 
wrote:

> On Sun, Apr 28, 2019 at 02:33:25AM -0600, arn...@skeeve.com wrote:
> > Gavin Smith  wrote:
> >
> > > On Sat, Mar 02, 2019 at 04:33:30PM +, Gavin Smith wrote:
> > > > Implemented as @subentry in git commit 372cfab.
> > > >
> > > > A test file is attached. Please feel free to experiment.
> > > >
> > > > It still needs to be implemented in texi2any, once the syntax is
> > > > finalised. Volunteers are welcome.
> > >
> > > I've added some support for @seeentry and @seealso in index entries in
> > > texi2any.  They are ignored except for DocBook output.
> >
> > Truly awesome!!!
> >
> > How do mean "ignored"?  Do you simply remove the @subentry and use
> > the rest of the line as the index text, in Info, for example?
>
> I mean entries with @seeentry and @seealso do not add any index entries
> for HTML and Info output.  @subentry isn't ignored.
>
> > I'd suggest something like  s/ *@subentry +/, /g   in sed syntax
> > for Info, if that makes sense to you.
>
> In HTML and Info output, this is what is done already - the parts are
> separated by commas.
>
> > And once again, a huge THANK YOU for working with me to add this feature
> > to Texinfo.  I have been working on the gawk manual's index to take
> > advantage of this and it makes for an incredible improvement.
>
> That is very good to hear.  Thank you for suggesting the new features
> and working to implement them in texindex.  I'm sure others will find
> them useful too.
>
>

-- 
Ray

Re: Feature request: multilevel indexing for TeX

[Raymond Toy]

I'm excited to see this supported in texinfo/texindex.

In the attachment, is @cindex the only way to get this or is this expected
to work with any user-defined index command?

Maxima will use a couple of user-defined indices to produce a nice
cross-reference of categories, so this is important.

On Sat, Mar 2, 2019 at 8:33 AM Gavin Smith  wrote:

> On 3/1/19, arn...@skeeve.com  wrote:
> > @indent makes sense, since that's what happens on the page, but I
> > can live with @tab also, or something like @subind might be good too.
> > I don't have strong feelings, as long as it makes reasonable sense
> > and is easy to convert an existing entry to it.
>
> Implemented as @subentry in git commit 372cfab.
>
> A test file is attached. Please feel free to experiment.
>
> It still needs to be implemented in texi2any, once the syntax is
> finalised. Volunteers are welcome.
>
> (I wrote a longer reply but GMail lost it when my internet went down.)
>


-- 
Ray