Re: @small* commands alias in HTML are problematic

[Patrice Dumas]

On Tue, Jan 26, 2021 at 09:24:12PM +0000, Gavin Smith wrote:
> On Tue, Jan 26, 2021 at 09:37:35PM +0100, Patrice Dumas wrote:
> > Hello,
> > 
> > The $small_alias transformation of @small* command names in 
> > Texinfo/Convert/HTML.pm is problematic, as it means that the commands
> > names in the tree and used in the call of processing functions are
> > different.  Another issue is that it is not possible to do something
> > specific such as adding a class in _convert_preformatted_command if
> > the @command is @small*.
> 
> I'm happy if the handling for this can be removed from the main
> function in _convert and moved to more specific code.

Ok.

> As far as I know the current approach is from commit 96aa697748e,
> in February 2019.
> 
> > Upon looking at the code, it seems to me that the main use for the 
> > aliasing is in 'preformatted_classes' stack and the $cmdname in 
> > _convert_preformatted_command.  Am I missing sommething?  I would be in
> > favor of using the $small_alias for that stack only, maybe by filling
> > differently pre_class_commands.  And then to determine the command alias
> > in _convert_preformatted_command and use it.
> 
> Just looking at that commit (as I don't remember anything from when I
> made it), there is also _convert_quotation_command for @*quotation
> and _convert_indented_command for @*indentedblock.  

Ok, probably would be better to present the original @-command too.
 
> The aliasing would have be done in _convert_preformatted_command
> and _convert_indented_command to output the correct class for CSS
> (i.e. not prefixed with "small").

Indeed.

> I don't want special CSS to be added by default for any of the
> @small* commands, although I'm not opposed to a "small" class
> being added for them.

Even if nothing is done in the default case, which I think is the best
if we want thos @-command to disappear someday, the information should
be present such that it can be done in user defined replacement
functions for the formatting.

> I doubt I ever understood what the 'preformatted_classes' stack was
> for, although looking at the code, it seems harmless if 'small*'
> command names are put on the stack instead of their equivalents,
> as these are still in %preformatted_commands; although I find the
> handling of this stack pretty hard to understand.  As far as I
> can tell, the stack is only used in _in_preformatted_in_menu, which
> checks if some of the possible values in the stack occur in the stack
> (although not all of them - 'verbatim' seems to be excluded, as well
> as 'menu' and 'menu_comment', as well as 'menu_comment' which has
> a hash (%pre_class_types) created to contain it but nothing else).
> I'm not sure what the point of adding them to the stack is if they're
> not used for anything.  There's no pressing need to simplify this,
> however, as it's not causing any problems.

It is used in _preformatted_class too, but what this code does is
not so clear (though I most probably wrote it).  It selects the class to
use for preformatted environments appearing within @example and similar
and in menus.  It is probably complex because of the nesting
possibilities, like @example in @menu (or maybe @menu in @example...),
maybe @verbatim in @example? some of which may be dubious or even should
be forbidden.  Some comments in _preformatted_class() would be
welcome...

In any case, I think I have all the needed information to do the change.

-- 
Pat