Re: Numbering Menu Items in html output

2020-11-28 Thread Christopher Dimech



> Sent: Saturday, November 28, 2020 at 7:13 PM
> From: "Gavin Smith" 
> To: "Christopher Dimech" 
> Cc: "help-texinfo gnu" 
> Subject: Re: Numbering Menu Items in html output
>
> On Sat, Nov 28, 2020 at 06:27:06PM +0100, Christopher Dimech wrote:
> > > On Sat, Nov 28, 2020 at 1:48 PM Christopher Dimech  wrote:
> > > >
> > > > Have asked Eli to number the menu items for the "Emacs Lisp Reference 
> > > > Manual"
> > > > who informed me that the menu gets unnumbered by Texinfo.
> > > >
> > > > Have done a test and can confirm.
> > > >
> > > > If one is using a Web Browser, it is much quicker to find if
> > > > you say "See 10.4 Backquote".  You just scroll to 10, then to
> > > > four, rather than by a Brain Regexp.
> > > >
> > > > Regards
> > > > Christopher
>
> If you are referring to numbering menus in Info output then this cannot
> be changed, as Info reading programs need menu entries to begin with "* ",
> not with a number.

I am referring to html when using a web browser. See
https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html

@chapter, @section, @sub.. do get numbered.  I was introspecting the notion
that the numbering is introduced according to what is customarily done when
numbering chapters and sections.  Eli mentioned that @menu is generated
automatically.

We want to avoid writing the numbers manually.




Re: Numbering Menu Items in html output

2020-11-28 Thread Gavin Smith
On Sat, Nov 28, 2020 at 06:27:06PM +0100, Christopher Dimech wrote:
> > On Sat, Nov 28, 2020 at 1:48 PM Christopher Dimech  wrote:
> > >
> > > Have asked Eli to number the menu items for the "Emacs Lisp Reference 
> > > Manual"
> > > who informed me that the menu gets unnumbered by Texinfo.
> > >
> > > Have done a test and can confirm.
> > >
> > > If one is using a Web Browser, it is much quicker to find if
> > > you say "See 10.4 Backquote".  You just scroll to 10, then to
> > > four, rather than by a Brain Regexp.
> > >
> > > Regards
> > > Christopher

If you are referring to numbering menus in Info output then this cannot
be changed, as Info reading programs need menu entries to begin with "* ",
not with a number.




Re: Numbering Menu Items in html output

2020-11-28 Thread Christopher Dimech


> Sent: Saturday, November 28, 2020 at 6:20 PM
> From: "Gavin Smith" 
> To: "Christopher Dimech" 
> Cc: "Patrice Dumas" 
> Subject: Re: Numbering Menu Items in html output
>
> Please send any queries to the public mailing lists
> bug-texi...@gnu.org or help-texinfo@gnu.org.

Missed the mailing list. Now I include it


> On Sat, Nov 28, 2020 at 1:48 PM Christopher Dimech  wrote:
> >
> > Have asked Eli to number the menu items for the "Emacs Lisp Reference 
> > Manual"
> > who informed me that the menu gets unnumbered by Texinfo.
> >
> > Have done a test and can confirm.
> >
> > If one is using a Web Browser, it is much quicker to find if
> > you say "See 10.4 Backquote".  You just scroll to 10, then to
> > four, rather than by a Brain Regexp.
> >
> > Regards
> > Christopher
> >
> >
> >
> >
>



Re: Copying image files for HTML output

2020-11-28 Thread Christopher Dimech
For when are you planning the next release?

> Sent: Saturday, November 28, 2020 at 10:36 AM
> From: "Gavin Smith" 
> To: "Patrice Dumas" , "bug-texinfo gnu" 
> 
> Subject: Copying image files for HTML output
>
> On Thu, Nov 19, 2020 at 11:10:55PM +0100, Patrice Dumas wrote:
> > I think that if the path does not starts with . or .. or is an absolute
> > path, it would make sense
> > 1) to search in include directories (I think that the current directory
> >   is always in front of of the search path)
> > 2) to check if the directories and image file exist in the destination
> >   directory and if not copy the file
> >
> > For point 2), there could be a customization variable to prevent the
> > copy, that would be off in the default case, but can be turned on for
> > the users who want backward compatibility or do something else by
> > themselves, for instance use links.
>
> I think it's a good idea but I think it should be left until after the
> next release to implement, as I suspect there will be enough issues from
> other changes to deal with.
>
>



Re: Copying image files for HTML output

2020-11-28 Thread Christopher Dimech
> Sent: Saturday, November 28, 2020 at 10:36 AM
> From: "Gavin Smith" 
> To: "Patrice Dumas" , "bug-texinfo gnu" 
> 
> Subject: Copying image files for HTML output
>
> On Thu, Nov 19, 2020 at 11:10:55PM +0100, Patrice Dumas wrote:
> > I think that if the path does not starts with . or .. or is an absolute
> > path, it would make sense
> > 1) to search in include directories (I think that the current directory
> >   is always in front of of the search path)
> > 2) to check if the directories and image file exist in the destination
> >   directory and if not copy the file
> >
> > For point 2), there could be a customization variable to prevent the
> > copy, that would be off in the default case, but can be turned on for
> > the users who want backward compatibility or do something else by
> > themselves, for instance use links.
>
> I think it's a good idea but I think it should be left until after the
> next release to implement, as I suspect there will be enough issues from
> other changes to deal with.

Have no qualms about that.



Copying image files for HTML output

2020-11-28 Thread Gavin Smith
On Thu, Nov 19, 2020 at 11:10:55PM +0100, Patrice Dumas wrote:
> I think that if the path does not starts with . or .. or is an absolute
> path, it would make sense
> 1) to search in include directories (I think that the current directory 
>   is always in front of of the search path)
> 2) to check if the directories and image file exist in the destination 
>   directory and if not copy the file
> 
> For point 2), there could be a customization variable to prevent the
> copy, that would be off in the default case, but can be turned on for
> the users who want backward compatibility or do something else by
> themselves, for instance use links.

I think it's a good idea but I think it should be left until after the
next release to implement, as I suspect there will be enough issues from
other changes to deal with.