Re: Which string capabilities need script interpreation?

[Florian Weimer]

* Thomas Dickey:

> On Sun, Aug 23, 2020 at 04:40:18PM +0200, Florian Weimer wrote:
>> I'm trying to figure which string capabilities in terminfo files need
>> to run through the script interpreter during output.  Is this
>> information available somewhere?  Type information for the script
>> parameters would also be nice.
>
> When you say "script", I'm thinking of the command-line program
> by that name.  It's not an interpreter -- it simply records the
> characters sent to the terminal.

I mean the string capabilities with printf-style % directives in them,
sorry.  In my world, these things look like small scripting languages.

> In terminfo, you have literal strings with some features
> added (parameter-substitution, simple expressions and padding).
> The tparm function takes those strings along with the actual parameters,
> and generates a string that (still containing padding)
> can be sent to the terminal using tputs.

And I'm wondering if it is possible, based on the capability as such,
to tell whether it takes parameters, and what their types are.  It
helps with adding consistency checks.

At present, if something doesn't quite parse as a sequence of
%-directives, I don't know if that's because of a typo in the terminal
definition, or because the string is expected to be passed through
unchanged, and % is just a verbatim %.

> If the capability string has no padding (e.g., TERM=xterm),
> then tputs has not much to do except copy the string to the terminal.
>  
>> What about the string capabilities that need to be processed for $<…>
>> delays?  Are those marked with P in the terminfo manual page?
>
> yes - the manual page says this:
>
>        (P)    indicates that padding may be specified
>
>        (P*)   indicates that padding may vary in proportion to the  number  of
>               lines affected
>
> and in summarizing the capabilities, those markers are used.
> That's only noting an assumption -- different terminals may have
> padding (generally the hardware terminals -- but even emulators
> may use padding for the "flash" capability).

Curiously, “flash” does not have the P marker.

I suspect that for some capabilities that contain user-supplied
strings (such as “pfkey”), interpreting $<…> directives would be
problematic.  If I read the ncurses sources correctly, $<…> directives
are interpreted even if they emerge after running the %-script,
without originally being present in it.

This would be a problem for a “set title” capability, if such a thing
existed.  (It looks like for hpterm, “pfkey” is used in this sense.)