gen-eclass-html.sh: Fix tildes'

[swagtoy]

Exactly what it says on the box.

Probably worth considering using another manpage parser like pandoc or something one day, it looks like we sed many things here. For now let's just grow that list of replacements.

[ulm]

Can you give an example of an eclass where this is a problem?

[swagtoy]

@ulm It's in the commit message. Not an eclass afaik

Seen in ebuild(5).

https://devmanual.gentoo.org/eclass-reference/ebuild/index.html

[ulm]

@ulm It's in the commit message. Not an eclass afaik

Seen in ebuild(5).

https://devmanual.gentoo.org/eclass-reference/ebuild/index.html

I see. However, there are also phrases like 'KEYWORDS = [-ti][x86,ppc,sparc,mips,alpha,arm,hppa,...]' and 'ACCEPT_KEYWORDS will be set to "amd64 tiamd64"' and your fix doesn't catch these.

[swagtoy]

@ulm It's in the commit message. Not an eclass afaik

Seen in ebuild(5).

https://devmanual.gentoo.org/eclass-reference/ebuild/index.html

I see. However, there are also phrases like 'KEYWORDS = [-ti][x86,ppc,sparc,mips,alpha,arm,hppa,...]' and 'ACCEPT_KEYWORDS will be set to "amd64 tiamd64"' and your fix doesn't catch these.

Can you show one please?

[ulm]

Search for these strings in https://devmanual.gentoo.org/eclass-reference/ebuild/index.html?

[swagtoy]

Ah shit... yeah! You're right. ;-/

Do you want to expand the regex for now to cover any corner cases until we later switch to a better man convert?

[ulm]

This Portage fix broke it: gentoo/portage@3b1e073

Maybe we could use \[ti] instead of \(ti which would make replacing the output easier?
@floppym

[swagtoy]

\fI\(ti\fR also seems to work if \[ti] wouldn't, at least for the sake of making formatting work

[ulm]

Maybe we could switch to app-text/mandoc for conversion, AFAICS it renders \(ti correctly. I have to check if there are any showstoppers.

[ulm]

Maybe we could switch to app-text/mandoc for conversion, AFAICS it renders \(ti correctly. I have to check if there are any showstoppers.

Unfortunately mandoc's style sheet collides with ours (for example, <a class="permalink">). Plus, I'm not convinced that the generated HTML is an improvement. For example, the first @CODE block of elisp-common.eclass is rendered as

<p class="Pp">
  <br/>
</p>
<pre>emacs? ( &gt;=app-editors/emacs-25.3:* )
</pre>
<br/>

which is terrible from a semantic point of view.

[floppym]

This Portage fix broke it: gentoo/portage@3b1e073

Maybe we could use \[ti] instead of \(ti which would make replacing the output easier? @floppym

I'm certainly no groff expert; if the alternate syntax works I have no objection.

[ulm]

This Portage fix broke it: gentoo/portage@3b1e073
Maybe we could use \[ti] instead of \(ti which would make replacing the output easier? @floppym

I'm certainly no groff expert; if the alternate syntax works I have no objection.

groff_char(7) lists it:

       ~        \[ti]   u007E     tilde

[swagtoy]

Maybe we could switch to app-text/mandoc for conversion, AFAICS it renders \(ti correctly. I have to check if there are any showstoppers.

Yeah, you have my support for trying to switch to anything other than man2html. In fact i suggested we do this from the start someday instead of trying to hack around man2html

Maybe poke at pandoc?

[swagtoy]

Maybe we could switch to app-text/mandoc for conversion, AFAICS it renders \(ti correctly. I have to check if there are any showstoppers.

Unfortunately mandoc's style sheet collides with ours (for example, <a class="permalink">). Plus, I'm not convinced that the generated HTML is an improvement. For example, the first @CODE block of elisp-common.eclass is rendered as

<p class="Pp">
  <br/>
</p>
<pre>emacs? ( &gt;=app-editors/emacs-25.3:* )
</pre>
<br/>

which is terrible from a semantic point of view.

You can pass style as an option to the mandoc html renderer (or just override it.

Im not sure what the issue is with what you posted, sorry

[ulm]

style just specifies the URI for <link rel="stylesheet" />. Also, it is ignored when mandoc is called with -O fragment (which we would do, because we add our own header and footer).

Anyway, I think the plan is:

• Submit a PR for Portage to replace \(ti with \[ti] in all man pages (technically, we need only ebuild.5 and make.conf.5 but better to replace it everywhere). Do you want to do that, or shall I?
• Update the sed regex to replace any occurence of [ti] with literal ~.
• Keep fingers cross and hope that there aren't legitimate strings [ti] anywhere else.

[swagtoy]

• Do you want to do that, or shall I?

Ill just woke up, so happy to tackle it in a moment. Ive never messed with manpages directly so i wanna get some hands on experience.

Plus, want to make sure that \[ti] actually converts to ti

[ulm]

Maybe poke at pandoc?

pandoc is slow. Real time to process all eclass manpages:

• man2html -r: 0.837 s
• mandoc -T html -O fragment: 0.684 s
• pandoc -f man -t html: 40.281 s

As I said above, the plan is to get rid of the conversion for the eclass manpages, so now is not a good time to change the conversion tool. Once we are left with ebuild.5 and make.conf.5 only, we can reconsider.

[swagtoy]

pandoc is slow.

Tell me something new 😅

Didnt consider the speed though, so we'll try your suggestion

[swagtoy]

@ulm It worked! Gonna send a patch to portage, apply those and then you can run it here :)

[swagtoy]

Attached is another patch. Feel free to cherry pick it if you'd like

[ulm]

Nope. a) We know that Portage installs its manpages in /usr/share/man/, and b) --path is not portable between the different providers of virtual/man.

[swagtoy]

Portage does, but meson does not unless you specify (i think?). Was useful for me to test my patch.

We could also just || echo

Anyway, you can just not cherry pick it.

[ulm]

Thank you, I've cherry picked the first commit. Closing.

It may take some time (e.g. we need a new portage release) before the changes will be visible on the site.

[swagtoy]

Awesome. Thanks 👍