bug-texinfo
[Top][All Lists]
Advanced

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

Re: extensible text styles


From: Gavin Smith
Subject: Re: extensible text styles
Date: Mon, 7 Mar 2016 17:57:09 +0000

On 7 March 2016 at 17:13, Per Bothner <address@hidden> wrote:
> Has anyone considered some mechanism for extensible text styles?
> I'm especially interested in being to control the 'class' attribute
> in HTML output, but setting other attributes is also useful.
>
> One application is syntax-colorizing programs.
> Another is using different styles for terminal prompts,
> inputs, and output (though one can use @kdb for the input).
>
> One possible syntax is:
>   @span{keyword, contents}
> which could be translated to:
>   <span class="keyword">contents</span>

I don't really understand what the question is here. This works for
the HTML output but Texinfo is for more than that: it's supposed to be
independent of what it's converted into to.

Syntax-colouring: there is a program
(http://www.gnu.org/software/src-highlite/) that can output Texinfo to
mark up source code (although I've never tried using it). It could be
a good idea to add Texinfo commands for syntax highlighting to mark
what is a keyword etc.

What you appear to want is a way for a user to add new Texinfo
commands for marking regions of text. Well, it does seem true that
users will want to mark regions of text for purposes that can't be
preconceived. (Maybe a book about birds marks the name of bird species
with the @bird command.) It seems a good idea to be able to escape the
predefined categories like @code, @env or @command.

I'm not sure how defining the output for all of the output formats
would work. Hard-coding new commands for syntax-highlighting or for
distinguishing input from output would be simpler and might be all
that's needed.

> This could be a possible Google Summer of Code project, assuming
> we can get consensus on the feature and its syntax.

I'd much rather have the HTML reader program. As well as the HTML
reader being potentially very useful, a feature for adding commands
would be quite disruptive to the rest of the code if it was
implemented, whereas a JavaScript program to run in a browser could be
implemented independently.



reply via email to

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