Re: Which string capabilities need script interpreation?

[Thomas Dickey]

On Sun, Aug 23, 2020 at 09:33:59PM +0200, Florian Weimer wrote:
> * 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.

there's simple expressions (arithmetic, logic, formatting),
but no loops.  Long ago, I heard the saying that any interesting
program has one I/O statement, one loop and one bug.  So terminfo
is missing the second requirement...

man 5 terminfo has this section summarizing the operations:

   Parameterized Strings
 
> > 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.

tic's checking tries to determine if the capability uses parameters,
and if they're the proper types.  That works well for the predefined
capabilities (though as usual, there may be some expression that the
analyzer doesn't get right).

For user-defined capabilities (other than the ones that ncurses defines
in its database as extensions -- I added a table of those "recently"),
that won't work :-)
 
> 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 %.

I'd use "tic -cv" on the terminal description (from text),
as well as using "infocmp -1f" to format the expressions in
a more-readable form (by splitting up expressions that use
the if/then/else operators).
 
> > 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.

well... hardware terminals wouldn't do that instaneously,
but there's no data being buffered or blocked -- so it wouldn't
have been a big problem.

for terminal emulators, flash is usually done by misusing
the escapes that change the screen to/from reverse-video.
Since that combination isn't a single predefined operation
(that the terminal "should" do), ncurses gets the job of
making it slow enough to see.

(even with that, a few terminal emulators have problems handling
that in a timely manner, so flash just doesn't work :-)
 
> 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.

$<...> are padding (time-delays)

and yes, since strings are fed into tparm as data, those could
be a nuisance.  Since tputs/putp are supposed to accept either
the result from tparm/tiparm _or_ a string from the terminal
database, it would be in-scope to improve the %s part by escaping
the dollar-signs (and backslash-characters, of course).
 
> 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.)

The "hpterm" description has this:

pfkey=\E&f%p1%dk%p2%l%dL%p2%s,

which is (tersely) documented like this:

       pkey_key                      pfkey      pk        program function key
                                                          #1 to type string #2
pfkey=\E&f%p1%dk%p2%l%dL%p2%s,
          ^#1   ^#2     ^#2

That \E is ASCII escape, which I've changed in a sample output to "\e"

\e&f5k5Lhello

otherwise generated using

        tput -T hpterm pfkey 5 hello

tput uses tparm and tputs, which uses the first parameter in the "5"
that appears first (using %p1 and %d), and the second parameter twice
(%p2 and %ld and %d, for a length, and %p2 and %s for a string).

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature