bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: @small* commands alias in HTML are problematic


From: Gavin Smith
Subject: Re: @small* commands alias in HTML are problematic
Date: Tue, 26 Jan 2021 21:24:12 +0000
User-agent: Mutt/1.9.4 (2018-02-28)

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.

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.  

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").

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.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]