Re: html manual +css
On Wed, Jan 15, 2020 at 10:52:06PM +0900, Jean-Christophe Helary wrote: > > > > On Jan 15, 2020, at 22:43, Patrice Dumas wrote: > > > > On Wed, Jan 15, 2020 at 09:12:15PM +0900, Jean-Christophe Helary wrote: > >>> > >>> The Guix developers managed to implement syntax highlighting by > >>> post-processing the HTML. > >>> (https://lists.gnu.org/archive/html/bug-texinfo/2019-11/msg4.html) > >> > >> Wow, I just checked this page: > >> https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html > >> > >> and the source if full of css "hooks" even for the parens in the code... > >> > >> What they do is interesting, and I guess some kind of postprocessing would > >> be possible to achieve what I suggest, but instead of that, I'm guessing > >> that just having texinfo add the css selectors would be easier. > > > > There are already hooks to customize the HTML produced, but it requires > > knowing perl and digging into the HTML customization API which is not > > documented anywhere. > > Are you talking about HTML.pm ? Yes. -- Pat
Re: html manual +css
On Wed, Jan 15, 2020 at 09:12:15PM +0900, Jean-Christophe Helary wrote: > > > > The Guix developers managed to implement syntax highlighting by > > post-processing the HTML. > > (https://lists.gnu.org/archive/html/bug-texinfo/2019-11/msg4.html) > > Wow, I just checked this page: > https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html > > and the source if full of css "hooks" even for the parens in the code... > > What they do is interesting, and I guess some kind of postprocessing would be > possible to achieve what I suggest, but instead of that, I'm guessing that > just having texinfo add the css selectors would be easier. There are already hooks to customize the HTML produced, but it requires knowing perl and digging into the HTML customization API which is not documented anywhere. My wild guess is that it could be possible to generate the same output using this facility, maybe using something similar with how @math and @tex blocks are processed by outside commands in tp/init/latex2html.pm or tp/init/tex4ht.pm. I do not know if it is the best way, though, maybe it makes sense to use guile to highlight code in the guile manual. > Also, what's interesting with the current HTML export is that even though it > is quite "old" in terms of standard (supposed to accept HTML 3.2 if I > remember correctly ?) adding appropriate classes and IDs is just enough to > access even bleeding edge CSS. Hence the idea of adding the appropriate > "hooks" directly from texinfo. Currently the default is 4.01 Transitional. But there is a customization file to produce HTML 3.2 in tp/init/html32.pm. -- Pat
Re: No table of contents in split HTML output
> On Jan 15, 2020, at 20:37, Gavin Smith wrote: > > On Fri, Dec 27, 2019 at 12:49 AM Jean-Christophe Helary > wrote: >> >> Apologies. >> >> The behavior is only seen in the Elisp Reference. >> >> The split Emacs Manual has Contents that points at >> emacs.html/index.html#SEC_Contents >> >> and Index that points at >> emacs.html/Key-Index.html#Key-Index >> >> And both files exist. >> >> So, maybe there is a naming conflict in the Elisp generation process where >> index.html#SEC_Contents is later overwritten by index.html#Index and since >> the html file exists (even if not the node name), the browser just points at >> it without generating an error. >> > > I haven't tried building the elisp manual myself, but > https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html#Top > doesn't have any Contents or Index links at all. I don't know how > those pages were generated as there is no comment in the files saying > "Generated by texi2any version" or similar. Would you mind trying to build locally with just "make docs" ? Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune
Re: html manual +css
Thank you for the reply Gavin. > On Jan 15, 2020, at 20:20, Gavin Smith wrote: > >> I have eventually resumed "work" on this and here is what I got: >> >> Original: >> https://www.gnu.org/software/emacs/manual/html_node/elisp/Visiting-Functions.html >> >> Sample: >> https://brandelune.github.io/code/Visiting-Functions.html >> >> The css I wrote: >> https://github.com/brandelune/brandelune.github.io/blob/gh-pages/code/emacs.css > > This looks quite good. If you change the width, or look at the file in a mobile phone or table the menu should be able to change. Also, I've put online the emacs manuals for real life testing of that css, if you want to try other manuals (they all share the same css so it's not very exciting) you can find the set here: https://doublet.jp/gnu/ I'll probably remove the set when I am done testing. >> Also, there are plenty of things that would be nice to have but in a way >> we're hitting the limits of the texinfo output (and my css skills too, of >> course). >> >> For ex: >> >> @deffn Command find-file filename wildcards >> >> becomes >> >> Command: find-file >> filename optional wildcards >> >> it would be nice to have the arguments tagged individually and the >> or keywords tagged in a different way. Also to have the various >> templates identified for what they are. > > Possibly: this should be possible if somebody would implement it in > texi2any. texinfo.tex already detects the keyword and > outputs it in boldface. Thank you for the hints. >> Also, examples should have similar tagging: >> >> @smallexample >> (switch-to-buffer (find-file-noselect filename nil nil wildcards)) >> @end smallexample >> >> could be something like >> >> @smallexample >> (@commandname switch-to-buffer (@commandname find-file-noselect @arguments >> filename nil nil wildcards)) >> @end smallexample >> >> so that we can have ways to target their contents with css. > > The Guix developers managed to implement syntax highlighting by > post-processing the HTML. > (https://lists.gnu.org/archive/html/bug-texinfo/2019-11/msg4.html) Wow, I just checked this page: https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html and the source if full of css "hooks" even for the parens in the code... What they do is interesting, and I guess some kind of postprocessing would be possible to achieve what I suggest, but instead of that, I'm guessing that just having texinfo add the css selectors would be easier. Your video too is quite exciting, in the end that would be nice to have a number of css variations if you manage to complete the system. Also, what's interesting with the current HTML export is that even though it is quite "old" in terms of standard (supposed to accept HTML 3.2 if I remember correctly ?) adding appropriate classes and IDs is just enough to access even bleeding edge CSS. Hence the idea of adding the appropriate "hooks" directly from texinfo. Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune
Re: No table of contents in split HTML output
On Fri, Dec 27, 2019 at 12:49 AM Jean-Christophe Helary wrote: > > Apologies. > > The behavior is only seen in the Elisp Reference. > > The split Emacs Manual has Contents that points at > emacs.html/index.html#SEC_Contents > > and Index that points at > emacs.html/Key-Index.html#Key-Index > > And both files exist. > > So, maybe there is a naming conflict in the Elisp generation process where > index.html#SEC_Contents is later overwritten by index.html#Index and since > the html file exists (even if not the node name), the browser just points at > it without generating an error. > I haven't tried building the elisp manual myself, but https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html#Top doesn't have any Contents or Index links at all. I don't know how those pages were generated as there is no comment in the files saying "Generated by texi2any version" or similar.
Re: html manual +css
On Mon, Dec 23, 2019 at 5:02 PM Jean-Christophe Helary wrote: > > I have eventually resumed "work" on this and here is what I got: > > Original: > https://www.gnu.org/software/emacs/manual/html_node/elisp/Visiting-Functions.html > > Sample: > https://brandelune.github.io/code/Visiting-Functions.html > > The css I wrote: > https://github.com/brandelune/brandelune.github.io/blob/gh-pages/code/emacs.css This looks quite good. > It is something I had done a while ago so I just spent a few hours today > cleaning it up but I'm really not sure how I came up with the various values > anymore :) > > Anyway, if it looks useful I'd like to think of ways to have it more widely > used. > > Also, there are plenty of things that would be nice to have but in a way > we're hitting the limits of the texinfo output (and my css skills too, of > course). > > For ex: > > @deffn Command find-file filename wildcards > > becomes > > Command: find-file filename > optional wildcards > > it would be nice to have the arguments tagged individually and the > or keywords tagged in a different way. Also to have the various > templates identified for what they are. Possibly: this should be possible if somebody would implement it in texi2any. texinfo.tex already detects the keyword and outputs it in boldface. > Also, examples should have similar tagging: > > @smallexample > (switch-to-buffer (find-file-noselect filename nil nil wildcards)) > @end smallexample > > could be something like > > @smallexample > (@commandname switch-to-buffer (@commandname find-file-noselect @arguments > filename nil nil wildcards)) > @end smallexample > > so that we can have ways to target their contents with css. The Guix developers managed to implement syntax highlighting by post-processing the HTML. (https://lists.gnu.org/archive/html/bug-texinfo/2019-11/msg4.html)
Re: Proper use of deftypemethod and the like
On Sat, Nov 9, 2019 at 7:31 AM Akim Demaille wrote:
> >> The documentation is not clear/consistent on how one should document typed
> >> functions. For instance it says:
> >>
> >> @deftypefn Function int foo (@code{const std::vector@&} bar)
> >> Documentation of @code{foo}.
> >> @end deftypefn
> >>
> >> where the type of the argument is in @code, while the argument itself is
> >> naked.
> >
> > This is in the "Inserting an Ampersand" node. I notice in the Info
> > output for this there are single quotes output for the @code: this is
> > wrong.
>
> Bummer, that's also what I observe in Info now :(
I've attempted to fix this in commit 57884fc74.
> Good, so it's clear: I should use @code. But it's broken in Info output :)
> Is there already an (approximate) release date for the next Texinfo?
There isn't.
