Re: Suggestion (was Re: [Texmacs-dev] Interactive feedback)

[Joris van der Hoeven]

On Wed, 25 Feb 2004, David Allouche wrote:
> On Wed, Feb 25, 2004 at 01:42:07PM +0100, Álvaro Tejero Cantero wrote:
> > I believe I don't fully understand your proposal, since e.g. I don't
> > know what continuations are. But as I had a precooked suggestion on
> > aiding user input without resorting to new widgets (i.e. inside the
> > document), I'll post it in this thread for the record.
>
> It would indeed make sense to define the inactive presentation of tags
> using macros.

This is indeed one of the ideas I had for the upcoming changes for
editing style files. Another idea is stripping "active" and "inactive"
tags from style files when *used* as style files, so that editing style
files can be done using a fine-grained view (much later such fine-grained
views should become available for all documents and not only style files).

> Maybe something like
> (drd-props "reference" "inactive-macro"
>   (macro "x" (inactive* "reference"
>                (inactive-arg (concat "label name? " (arg "x"))))))
>
> (caveat: I have not yet examined how the drd-props primitive actually
> should be used, so this snippet is just creative bullshit)

Yes, the knowledge may be stored in the DRD. Alternatively,
when typesetting the inactive version of a macro "x", one might check
whether the macro "inactive-x" is defined and fall back to the standard
behaviour if not. I am not completely fixed yet, because I also would
like to have *multiple* ways of rendering inactive markup (<|>-notation,
scheme notation, tree notation, etc.). So if someone has more ideas...

> > that is: we get something from the source code definition of the
> > reference tag and use it to better inform the user. That would also
> > render semi-useless a "tag manual", since every tag is self-documenting,
> > as should be in a really good good system (i.e. no need to read
> > manuals).
> >
> > The <reference|> is really a dummy example, but think of the
> > <postscript|||||||>. Everybody complais they don't understand the
> > expected options.... well that should be like:
> >
> > <postscript|filename?...|scale?...|crop?...|your-option-here?...>
>
> Some hints there would indeed be a good thing. But the "postscript"
> primitive is so overloaded that I do not think you can understand the
> use of its arguments w/o reading the documentation.

Probably a good place to specify hints would be the DRD.
But this does not seem urgent right now.

> > [whether it's better that all the "hints" (attribute names) appear
> > simultaneously or not could be discussed]
>
> Making it possible to only display hints for the argument the caret is
> in would also be a whole different affair, and I do not know how it
> should be implemented. Joris?

One might store such information in the DRD ^^^ (i.e. associate
short purpose-string and/or a longer help-string to each argument
and/or the macro itself). Alternatively, one might create
a context sensitive GUI-primitive (footer-help "left" "right")
for displaying help information in the footer. The second solution
has the advantage of not putting too much information in the DRD.
The first one has the advantage that this explanatory information
is present at the place where the tag is defined.

> > The proposal can also be coupled with the use of a part of the
> > minibuffer to print the help texts while in inactive elements or while
> > being asked inside the minibuffer for input.
>
> I vaguely gather what you want to do with minibuffer hints but, again, I
> do not know how that should be done... Using tag-info, dynamic editing,
> or something new...

I think that Alvaro means that we should optionally provide the user
with more information than a few-words message like "Page width:"
when entering values in the footer. This might again be part of
the "interactive" command (together with types and default values).