[9fans] parm server: user interaction

[9fans] parm server: user interaction

[tlaronde]

As I have tried to explain concerning TeX during IWP9, TeX is only C89
and I want it to behave exactly the same whatever the hosting OS is.
Because if joe user uses TeX, if it behaves exactly the same on
whatever OS, there is no impossibility to swap the OS underneath.

While thinking about the way an interactive session with TeX works,
I'm currently thinking about the line editing feature---not a big
problem, because TeX calls a C89 routine to get the next line, and the
editing is the "spoon" before entering the "mouth" i.e. it is outside
TeX altogether.

But I was thinking about also of a way to behave more helpfully about
macros: since the macros are digested, TeX knows what is their syntax,
what is the type of arguments and so on, so could display an help
about the usage (this has to be done in TeX proper) and there could be
a better editing of incorrect arguments in an interactive session.

But this is TeX internals. The question about the usage and the
interactive editing of arguments (and the correction of partially
incorrect arguments) could be done also more generally with any
utility, including, depending on the terminal, using different
arguments handling.

There is prior partial art: limited getopt(3) on Unix; a more general
handling routine in C.E.R.L. GRASS that takes the argc and argv[],
verifying type of argument, range, setting default values and engaging,
if interactive, a dialog with the user whether to get the mandatory
arguments if not provided or to correct the incorrect ones.

In pseudo C, a utility (an equivalent can be made for a rc script)
would set an array of this:

typedef struct {
        int cat;
#define PARM_CAT_EOP    0       /* final sentry of array */
#define PARM_CAT_FLAG   0x01    /* "-h" like */
#define PARM_CAT_OPTION 0x02    /* "skip=val" like */
#define PARM_CAT_ARG    0x04    /* positional arg */    

        char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
                        /* positional is not counting flags and options */
        int flags;
#define PARM_FLAG_MANDATORY     0x01
#define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */

        int type;
#define PARM_TYPE_STRING        0
#define PARM_TYPE_INT           1
#define PARM_TYPE_FLOAT         2
#define PARM_TYPE_PATH          3

        char *range;    /* acceptable range of values for numbers */
                        /* a regex for strings and paths */
        /* for following require and forbid, index of PARM_CAT_EOP is
          end of array
         */
        int *require;   /* an array of indices of parms required with */
        int *forbid;    /* an array of indices of conflicting parms */
        char *default;
        char *description;
        /* these are filled in return */
        int nval;       /* count of values */
        char **val;
} Parm;

Depending on what server is attached for serving arguments, if none,
the syntax is verified as well as the ranges, the defaults being
set, and it exits on error sending usage on stderr without modifying
the arguments served.

A line oriented server could engage a dialog with the user to correct
arguments or to ask for missing arguments.

A 2D oriented server could do this by displaying a graphical interface
to get the arguments if not provided or incorrectly provided.

The three principal ideas being:

1) that a utility has the information about what arguments it
expects so say that an extension of the Unix like "tab-completion" after
a utility name would display the usage, because it is served from
inside the utility;

2) that such a description can provide immediately an usage without
having to write the code, and that the handling of ranges, types and so
on have not to be repeated in every utility;

3) that a graphical interface is just another way of getting arguments,
and there should be no necessity to program a special version of a
utility to change the way the arguments are provided.

Is such an idea totally orthogonal to Plan9?
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-M58c70eafe8e0a67816e6247c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[hiro]

This seems quite interesting to me but i didn't understand most of it,
i'll just concentrate on your first proposal in 1).

I think there are some obvious reasons why Plan9 people never missed
TAB completion as in BASH, ZSH, and other bloated linux programs.
1) we have less arguments, thus most can remember them.
2) we ask people to use file-globbing
3) we ask people to keep names short, and easy to type and not only meaningful.
4) there are many known ways to limit scope so that names can stay
short and still meaningful.
5) there's a file completion hack in rio (ctrl-f), though it's not
really used by many bec. it never works: it runs in the parent rio
namespace that doesnt see child mounts.

There are also non-obvious reasons.
One thing that I noticed very early on is that tab-complete seemed
like a good idea that never got implemented fully:
if some applications come with BNF style grammar in the documentation
for the arguments, why does tab completion not show these multiple
options? why does it only ever show a single option? i think because
typewriters suck.
in a graphical os like plan9 it might be much easier to graphically
document via a second rio window the possible extensions of current
text line without using horrible ncurses extensions..

example:
imagine you typed
ssh linux ip route a

program could check your last line in /dev/text against it's
cross-operating system BNF database and help you show the following
valid remaining options:

ssh linux ip route a{ add | append } ROUTE
ROUTE := NODE_SPEC [ INFO_SPEC ]

then you type on
ssh linux ip route add
and focus the other rio window again (alternative use a plumbing event
instead of focus) to get this next multi-line recommendation:

ssh linux ip route add ROUTE
ROUTE := NODE_SPEC [ INFO_SPEC ]
NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
            [ table TABLE_ID ] [ proto RTPROTO ]
            [ scope SCOPE ] [ metric METRIC ]
            [ ttl-propagate { enabled | disabled } ]
INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...

now you might realize you might want a better GUI where you can
include/exclude parts of this tree to find an easy completion-path.
seems a bit more involved but very possible since we have real GUIs.
Probably GUIs are too difficult for unix people, it's even harder in
TUI apps, and tab-completion = good enuff for them?

anyways, good man pages and low complexity are easier. we have no BNF
docs or complex multidimensional arguments like in iproute2 anyways ;)

On Thu, Aug 7, 2025 at 3:22 PM <tlaronde@kergis.com> wrote:
> 
> As I have tried to explain concerning TeX during IWP9, TeX is only C89
> and I want it to behave exactly the same whatever the hosting OS is.
> Because if joe user uses TeX, if it behaves exactly the same on
> whatever OS, there is no impossibility to swap the OS underneath.
> 
> While thinking about the way an interactive session with TeX works,
> I'm currently thinking about the line editing feature---not a big
> problem, because TeX calls a C89 routine to get the next line, and the
> editing is the "spoon" before entering the "mouth" i.e. it is outside
> TeX altogether.
> 
> But I was thinking about also of a way to behave more helpfully about
> macros: since the macros are digested, TeX knows what is their syntax,
> what is the type of arguments and so on, so could display an help
> about the usage (this has to be done in TeX proper) and there could be
> a better editing of incorrect arguments in an interactive session.
> 
> But this is TeX internals. The question about the usage and the
> interactive editing of arguments (and the correction of partially
> incorrect arguments) could be done also more generally with any
> utility, including, depending on the terminal, using different
> arguments handling.
> 
> There is prior partial art: limited getopt(3) on Unix; a more general
> handling routine in C.E.R.L. GRASS that takes the argc and argv[],
> verifying type of argument, range, setting default values and engaging,
> if interactive, a dialog with the user whether to get the mandatory
> arguments if not provided or to correct the incorrect ones.
> 
> In pseudo C, a utility (an equivalent can be made for a rc script)
> would set an array of this:
> 
> typedef struct {
>         int cat;
> #define PARM_CAT_EOP    0       /* final sentry of array */
> #define PARM_CAT_FLAG   0x01    /* "-h" like */
> #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
> #define PARM_CAT_ARG    0x04    /* positional arg */
> 
> char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
>                 /* positional is not counting flags and options */
> int flags;
> #define PARM_FLAG_MANDATORY     0x01
> #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
> 
> int type;
> #define PARM_TYPE_STRING        0
> #define PARM_TYPE_INT           1
> #define PARM_TYPE_FLOAT         2
> #define PARM_TYPE_PATH          3
> 
> char *range;    /* acceptable range of values for numbers */
>                 /* a regex for strings and paths */
> /* for following require and forbid, index of PARM_CAT_EOP is
>   end of array
>  */
> int *require;   /* an array of indices of parms required with */
> int *forbid;    /* an array of indices of conflicting parms */
> char *default;
> char *description;
> /* these are filled in return */
> int nval;       /* count of values */
> char **val;
> } Parm;
> 
> Depending on what server is attached for serving arguments, if none,
> the syntax is verified as well as the ranges, the defaults being
> set, and it exits on error sending usage on stderr without modifying
> the arguments served.
> 
> A line oriented server could engage a dialog with the user to correct
> arguments or to ask for missing arguments.
> 
> A 2D oriented server could do this by displaying a graphical interface
> to get the arguments if not provided or incorrectly provided.
> 
> The three principal ideas being:
> 
> 1) that a utility has the information about what arguments it
> expects so say that an extension of the Unix like "tab-completion" after
> a utility name would display the usage, because it is served from
> inside the utility;
> 
> 2) that such a description can provide immediately an usage without
> having to write the code, and that the handling of ranges, types and so
> on have not to be repeated in every utility;
> 
> 3) that a graphical interface is just another way of getting arguments,
> and there should be no necessity to program a special version of a
> utility to change the way the arguments are provided.
> 
> Is such an idea totally orthogonal to Plan9?
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-Me6022f75b9821bd72129a5ac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[Dworkin Muller]

tlaronde> On Thu, Aug 7, 2025 at 3:22 PM <tlaronde@kergis.com> wrote:
tlaronde> The three principal ideas being:
tlaronde> 
tlaronde> 1) that a utility has the information about what arguments it
tlaronde> expects so say that an extension of the Unix like "tab-completion" after
tlaronde> a utility name would display the usage, because it is served from
tlaronde> inside the utility;
tlaronde> 
tlaronde> 2) that such a description can provide immediately an usage without
tlaronde> having to write the code, and that the handling of ranges, types and so
tlaronde> on have not to be repeated in every utility;
tlaronde> 
tlaronde> 3) that a graphical interface is just another way of getting arguments,
tlaronde> and there should be no necessity to program a special version of a
tlaronde> utility to change the way the arguments are provided.

This would be a perfect example of history repeating itself.  The tab
completion that most people are familier with these days from the Unix
world is a really poor derivative of TOPS-20's COMND% JSYS (Jump to
SYStem, essentially system call).

<long-winded abbreviated overview of COMND%>

COMND% provided an application with the ability to interactively read
and parse an arbitrarily-complex input command.  Each field's type and
acceptable values were determined dynamically by the application,
which means that it could change depending on what had already been
entered.  The types available were quite varied, from numbers of
arbitrary base (up to 36), to dates, to filenames (optionally
restrictable to existing or non-existing, etc), to user names, to
switches (with and without associated values), etc.  This JSYS was
used by programs to gather and parse input, not their command lines.

To make it even more fun, there were various `action characters' to
trigger various forms of help as you entered a line.  Question mark
would show what you could enter in the current field (or, if you've
partly entered the field, what expected/allowed values that that input
matches); this could be nothing or hundreds of possible values,
depending on the context.  Escape would complete the current field
based on what (if anything) had been entered.  In the specific case of
entering filenames, you could use control-F to finish out the entire
filespec (filenames are more complicated on TOPS-20 than on more
modern systems).  Of course, if you didn't need to actually see what
something expanded out to, because you knew you'd given a unique
prefix of whatever was legal at that point, you could just move on to
the next field and keep going.

There were various niceties, such as when typing question mark at the
beginning of a field, the type of whatever's wanted would be printed
(`a number', `a switch, one of ...', etc) and the legal values.  And,
of course, since several different types of fields might be legal at a
given point (say, an optional switch or a filename), it would list
each of the potential field types and their values in turn.  Error
cases were handled, such as being partway into a switch (note that
switches and such usually were full words, like /width or /fullduplex)
and hitting escape or question mark; this would elicit ringing the
bell and printing something like `no legal values match current
input', then reprinting the input line and waiting for more input.
Everything described in this paragraph was handled by COMND%; the
program itself had no knowledge that this happened.

Things could be much more ornate than summarized above.

The EXEC (roughly equivalent to a shell) used COMND% to read its
input, just like any other application would.  For its built-in
commands, it parsed the various fields just like any other program
would/could (a lot of applications were inherited from TOPS-10, which
didn't do that).  For external-to-EXEC programs, it just gathered
everything up and handed it all to the program without trying to be
smart.  It was possible to provide definition tables to EXEC to allow
it to interactively parse command lines for other programs, but you
lost a lot of the dynamism if you did so.

Unfortunately, that resulted in the major fault line in the scheme -
some commands you had this nice interactive entry system guiding you
through the possibilities in their command lines, and others it was
pretty much just `arguments'.  For the built-ins, and for programs
interacting with the user via COMND%, the result was an adaptive
system that would hand-hold you just as much as you needed; newbies
could be effectively spoon-fed, and experts could breeze right along.
These are exactly equivalent commands, with action characters
indicated and user input in lowercase (@ is the prompt):

    @inf<ESC> (ABOUT) t? ONE OF THE FOLLOWING:
     TAPE-PARAMETERS
     TERMINAL-MODE
    @INFORMATION (ABOUT) Ter<ESC>
     <various settings regarding the terminal are displayed>

or

    @i ter
     <the same terminal settings>

</long-winded abbreviated overview of COMND%>

Unix tab completion was introduced in tcsh, which pretty much started
as csh with tab completion added.  The `t' stands for `TOPS-20' (cf
the section `THE T IN TCSH' in the tcsh man page).  It most closely
mimics the actions of the TOPS-20 escape action character.

Completion's been extended into other areas with semi-dynamic
abilities in more recent times (such as expanding the hostname as a
parameter to slogin), and similar capabilities cross-pollinated into
the various other Unix shells.  However (there's always a caveat ;-).
With the exception of filenames, hostnames, and other long-winded
values, the terseness of Unix command names and arguments makes it so
that the sort of completion mechanism described above is pretty much
totally useless.  It is, arguably, even of negative value since it
encourages someone to attempt to do completion where it makes no
sense.

So, Thierry's first principal idea as quoted above is pretty much
exactly what EXEC used COMND% to do with its built-in commands and
other applications did with their interactive commands.  Item 2
becomes really ugly to achieve outside the application pretty quickly
if you want to do anything dynamic (say, accept either a filename or a
username as the next argument, but only a filename if a particular
switch was set previously).  A long time ago, I toyed with the idea of
trying to define a description language that shells could use for
dealing with arbitrary programs' command lines (it would've been an
extra ELF segment in the binary), but couldn't come up with a good way
of handling the general case and couldn't really justify it because
most command lines just weren't worth trying to deal with completion
for.  Tcsh's generalized completion mechanism's about as close to
acceptable as any other I've seen/come up with so far in terms of
parsing things for other, totally unrelated programs.  Which is to
say, not very.

I agree whole-heartedly with item 3.  But then, I've expressed my
feelings about having to use a mouse when a keyboard would do before
;-)

As an aside, there is a C reimplementation (reimagining?) of the
COMND% JSYS, called CCMD, which was developed on Unix.  It's a
moderately-close equivalent, but handles far fewer field types.  There
are a lot of cosmetic differences, but the basic model of how you
gather and parse an input line follows pretty closely.  It *really*
helps to have the TOPS-20 documentation of COMND% at hand, though.
Most of the differences are probably because TOPS-20 applications
generally were written in MACRO-20 (assembly code) not C.  Some
programming idioms don't fully translate....

On Thu, 7 Aug 2025 20:50:47 +0200, hiro <23hiro@gmail.com> wrote:
23hiro> I think there are some obvious reasons why Plan9 people never missed
23hiro> TAB completion as in BASH, ZSH, and other bloated linux programs.
23hiro> 1) we have less arguments, thus most can remember them.
23hiro> 2) we ask people to use file-globbing
23hiro> 3) we ask people to keep names short, and easy to type and not only meaningful.
23hiro> 4) there are many known ways to limit scope so that names can stay
23hiro> short and still meaningful.
23hiro> [...]
23hiro> One thing that I noticed very early on is that tab-complete seemed
23hiro> like a good idea that never got implemented fully:
23hiro> if some applications come with BNF style grammar in the documentation
23hiro> for the arguments, why does tab completion not show these multiple
23hiro> options? why does it only ever show a single option? i think because
23hiro> typewriters suck.

It got implemented fully, just not in the Unix world.  And that's
because it just wasn't fit for purpose in that context.

I would point out that there are situations where file-globbing
doesn't really work well.  Regexps or name completion can sometimes
work much better.  It depends a lot on the context you're working in.
I suspect this falls into the general argument bucket of whether you
use Plan 9 for OS research/hacking or as a platform for non-OS work.
Short command names, especially combined with namespaces (whether in
the Plan 9 sense or as subdirectories [cf auth/, ip/, etc]) aren't
difficult.  But if you have hundreds of data files, and need to refer
to a specific one, globbing's not necessarily well-suited to the task.

Dworkin

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-M3ad4e77218cc34867d5a39c0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[tlaronde]

On Thu, Aug 07, 2025 at 08:50:47PM +0200, hiro wrote:
> This seems quite interesting to me but i didn't understand most of it,
> i'll just concentrate on your first proposal in 1).
> 
> I think there are some obvious reasons why Plan9 people never missed
> TAB completion as in BASH, ZSH, and other bloated linux programs.
> 1) we have less arguments, thus most can remember them.
> 2) we ask people to use file-globbing
> 3) we ask people to keep names short, and easy to type and not only meaningful.
> 4) there are many known ways to limit scope so that names can stay
> short and still meaningful.

That the core utilities be as "elementary" as possible, limiting the
number of options and using short meaning names, is obviously good.

But a system is not only used as-is, but with additional utilities
whose complexity grows when being more and more "high" (i.e.: derived)
user level.

So such a feature has not to be evaluated only for core utilities, but
for other higher user space programs.

This common scheme could impose consistency on arguments values, and
consistency of user interface (whether 1D: line interface, or 2D
interface: GUI---curses, contrary to common belief, is 2D so is a
limited GUI).

> 5) there's a file completion hack in rio (ctrl-f), though it's not
> really used by many bec. it never works: it runs in the parent rio
> namespace that doesnt see child mounts.

During IWP9 was presented Lola by Angelo Papenhoff. I do think that
it is right to work on the GUI and that we can do something Plan9'ish
that is simple, consistent, and have not much to do with other
windowing systems---I think getting things altogether from 8 1/2, rio
and Lola. I wouldn't like to have X11! on Plan9 and neither curses!
(God forbid!) that is a suboptimal compromise between the console and
the graphical 2D interface.

To try to sketch the "big" idea (but I'm working on pieces for now, to
gather knowledge to refine the "big" idea---may be dropping it, or
dropping some of it):

1) For every program are defined stdin, stdout and stderr. On a
"console" (not a 2D interface), echoing stdin, displaying stdout or
stderr is done at the very same place. With a 2D interface, stdin
should be taken from a window on top, stdout displayed on main middle
window, and stderr displayed on the bottom window (one can call them
"panels" of a main window). [Am I not re-inventing Acme?]

2) Every program (the same can be done for rc(1) scripts) defines the
syntax and even semantics of its arguments. So dialoguing to get the
right arguments is made from within the command (and this should be
recursive, if one of the arguments is a command, then getting the
right arguments to this subcommand would be made by the same
mechanism). But there are three distinct things:

        a) Editing the line (lexical stage): just to put, retrieve,
        modify, correct the line to input. Since I would want to be
        able to use the regex, selecting a previous line etc. in fact
        I'm simply re-inventing ed(1)... So it would be ed'iting;
        
        b) Checking the grammar (syntactical stage): from inside the
        command, using the Parm array a whatever parm Server dialogs
        with the user (dumb parm Server: checks and exits with success
        or error; or 1D dialog; or 2D graphical display to fill the
        options);

        c) Doing the stuff (semantical stage): the arguments are valid
        from b), the utility does its job.

3) There is no reason to have several versions of the same program: an
utility can be used via lines (command lines) or via graphical
interface, and its result (stdout) can be as is or "rendered". With a
graphical interface, all the "menus" to select commands or getting
arguments are generated automatically from the Parm array description
(sub-commands being whether "drop-down" or "pop-up"; the graphical
interface should allow to call itself in a subwindow) the resulting
being sent to one (at a time; could be several displaying windows,
with selection of the current one to send the result to be displayed),
the result window being whether "raw" (it just displays a succession
of bytes), "text" (it just displays chars according to utf8 in a
selected font) or  "graphical" (it draws primitives). A "rendered"
text is a special case of using "graphical".

When it comes to rendering, as I have sketched during IWP9, one has to
rasterize, and METAFONT is a rasterizer. So one of the things I'm
thinking about is how to extend DVI to allow to embed DVI in DVI, to
add the drawing primitives so that a glyph can be described (not
rasterized) in DVI, to allow to simply append supplementary drawing
instructions on some pages, or to add pages to an existing document
without touching it (the case of signed PDF, where you append
modifications without touching what has been signed, simply redefining
the xrefs to reach also the previous ones, the reading starting at the
end of the document to the first "/^%EOF/") etc. and extracting the
rasterizing routines from METAFONT.

This will very probably and for good reasons seem fuzzy, but the first
part (ed'iting and describing the syntax in main() to check or rework
arguments before processing) is easy---less when it comes to
implementing the help about arguments inside TeX proper.

This will be all for today :-)

> 
> There are also non-obvious reasons.
> One thing that I noticed very early on is that tab-complete seemed
> like a good idea that never got implemented fully:
> if some applications come with BNF style grammar in the documentation
> for the arguments, why does tab completion not show these multiple
> options? why does it only ever show a single option? i think because
> typewriters suck.
> in a graphical os like plan9 it might be much easier to graphically
> document via a second rio window the possible extensions of current
> text line without using horrible ncurses extensions..
> 
> example:
> imagine you typed
> ssh linux ip route a
> 
> program could check your last line in /dev/text against it's
> cross-operating system BNF database and help you show the following
> valid remaining options:
> 
> ssh linux ip route a{ add | append } ROUTE
> ROUTE := NODE_SPEC [ INFO_SPEC ]
> 
> then you type on
> ssh linux ip route add
> and focus the other rio window again (alternative use a plumbing event
> instead of focus) to get this next multi-line recommendation:
> 
> ssh linux ip route add ROUTE
> ROUTE := NODE_SPEC [ INFO_SPEC ]
> NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
>             [ table TABLE_ID ] [ proto RTPROTO ]
>             [ scope SCOPE ] [ metric METRIC ]
>             [ ttl-propagate { enabled | disabled } ]
> INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...
> 
> now you might realize you might want a better GUI where you can
> include/exclude parts of this tree to find an easy completion-path.
> seems a bit more involved but very possible since we have real GUIs.
> Probably GUIs are too difficult for unix people, it's even harder in
> TUI apps, and tab-completion = good enuff for them?
> 
> anyways, good man pages and low complexity are easier. we have no BNF
> docs or complex multidimensional arguments like in iproute2 anyways ;)
> 
> On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com> wrote:
> > 
> > As I have tried to explain concerning TeX during IWP9, TeX is only C89
> > and I want it to behave exactly the same whatever the hosting OS is.
> > Because if joe user uses TeX, if it behaves exactly the same on
> > whatever OS, there is no impossibility to swap the OS underneath.
> > 
> > While thinking about the way an interactive session with TeX works,
> > I'm currently thinking about the line editing feature---not a big
> > problem, because TeX calls a C89 routine to get the next line, and the
> > editing is the "spoon" before entering the "mouth" i.e. it is outside
> > TeX altogether.
> > 
> > But I was thinking about also of a way to behave more helpfully about
> > macros: since the macros are digested, TeX knows what is their syntax,
> > what is the type of arguments and so on, so could display an help
> > about the usage (this has to be done in TeX proper) and there could be
> > a better editing of incorrect arguments in an interactive session.
> > 
> > But this is TeX internals. The question about the usage and the
> > interactive editing of arguments (and the correction of partially
> > incorrect arguments) could be done also more generally with any
> > utility, including, depending on the terminal, using different
> > arguments handling.
> > 
> > There is prior partial art: limited getopt(3) on Unix; a more general
> > handling routine in C.E.R.L. GRASS that takes the argc and argv[],
> > verifying type of argument, range, setting default values and engaging,
> > if interactive, a dialog with the user whether to get the mandatory
> > arguments if not provided or to correct the incorrect ones.
> > 
> > In pseudo C, a utility (an equivalent can be made for a rc script)
> > would set an array of this:
> > 
> > typedef struct {
> >         int cat;
> > #define PARM_CAT_EOP    0       /* final sentry of array */
> > #define PARM_CAT_FLAG   0x01    /* "-h" like */
> > #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
> > #define PARM_CAT_ARG    0x04    /* positional arg */
> > 
> > char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
> >                 /* positional is not counting flags and options */
> > int flags;
> > #define PARM_FLAG_MANDATORY     0x01
> > #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
> > 
> > int type;
> > #define PARM_TYPE_STRING        0
> > #define PARM_TYPE_INT           1
> > #define PARM_TYPE_FLOAT         2
> > #define PARM_TYPE_PATH          3
> > 
> > char *range;    /* acceptable range of values for numbers */
> >                 /* a regex for strings and paths */
> > /* for following require and forbid, index of PARM_CAT_EOP is
> >   end of array
> >  */
> > int *require;   /* an array of indices of parms required with */
> > int *forbid;    /* an array of indices of conflicting parms */
> > char *default;
> > char *description;
> > /* these are filled in return */
> > int nval;       /* count of values */
> > char **val;
> > } Parm;
> > 
> > Depending on what server is attached for serving arguments, if none,
> > the syntax is verified as well as the ranges, the defaults being
> > set, and it exits on error sending usage on stderr without modifying
> > the arguments served.
> > 
> > A line oriented server could engage a dialog with the user to correct
> > arguments or to ask for missing arguments.
> > 
> > A 2D oriented server could do this by displaying a graphical interface
> > to get the arguments if not provided or incorrectly provided.
> > 
> > The three principal ideas being:
> > 
> > 1) that a utility has the information about what arguments it
> > expects so say that an extension of the Unix like "tab-completion" after
> > a utility name would display the usage, because it is served from
> > inside the utility;
> > 
> > 2) that such a description can provide immediately an usage without
> > having to write the code, and that the handling of ranges, types and so
> > on have not to be repeated in every utility;
> > 
> > 3) that a graphical interface is just another way of getting arguments,
> > and there should be no necessity to program a special version of a
> > utility to change the way the arguments are provided.
> > 
> > Is such an idea totally orthogonal to Plan9?
> > --
> > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >              http://www.kergis.com/
> >             http://kertex.kergis.com/
> > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-M914b55730413e96ca171252a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[tlaronde]

I will reply hastily on top, so please forgive me!

1) I'm fond of knowing history and historical practices. So thanks for
the TOPS-20 presentation, that I didn't know about!

2) In what I have sketched, one can easily add more types (like impose
a date to be ISO8601, but allowing too to give regex to validate an
argument) and this adds to the consistency of the whole system;

3) When it comes to just editing something (not completion, or
displaying alternatives etc.), but just amending the input line,
I'm more and more inclined to consider that this is in fact ed(1) 'iting;

4) I totally agree with you concerning the mouse: to be able to use it
when there is one, working, OK; but I want to be able too to do all the
stuff in restricted environment, with the keyboard, and I mean without
even the "extended keys"---that may or may not be present, and even
if present may not work.

The history of the 't' completion shows, once more, how much can be
lost in translation ("traduttore, traditore").

On Thu, Aug 07, 2025 at 08:03:18PM -0600, Dworkin Muller wrote:
> tlaronde> On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com> wrote:
> tlaronde> The three principal ideas being:
> tlaronde> 
> tlaronde> 1) that a utility has the information about what arguments it
> tlaronde> expects so say that an extension of the Unix like "tab-completion" after
> tlaronde> a utility name would display the usage, because it is served from
> tlaronde> inside the utility;
> tlaronde> 
> tlaronde> 2) that such a description can provide immediately an usage without
> tlaronde> having to write the code, and that the handling of ranges, types and so
> tlaronde> on have not to be repeated in every utility;
> tlaronde> 
> tlaronde> 3) that a graphical interface is just another way of getting arguments,
> tlaronde> and there should be no necessity to program a special version of a
> tlaronde> utility to change the way the arguments are provided.
> 
> This would be a perfect example of history repeating itself.  The tab
> completion that most people are familier with these days from the Unix
> world is a really poor derivative of TOPS-20's COMND% JSYS (Jump to
> SYStem, essentially system call).
> 
> <long-winded abbreviated overview of COMND%>
> 
> COMND% provided an application with the ability to interactively read
> and parse an arbitrarily-complex input command.  Each field's type and
> acceptable values were determined dynamically by the application,
> which means that it could change depending on what had already been
> entered.  The types available were quite varied, from numbers of
> arbitrary base (up to 36), to dates, to filenames (optionally
> restrictable to existing or non-existing, etc), to user names, to
> switches (with and without associated values), etc.  This JSYS was
> used by programs to gather and parse input, not their command lines.
> 
> To make it even more fun, there were various `action characters' to
> trigger various forms of help as you entered a line.  Question mark
> would show what you could enter in the current field (or, if you've
> partly entered the field, what expected/allowed values that that input
> matches); this could be nothing or hundreds of possible values,
> depending on the context.  Escape would complete the current field
> based on what (if anything) had been entered.  In the specific case of
> entering filenames, you could use control-F to finish out the entire
> filespec (filenames are more complicated on TOPS-20 than on more
> modern systems).  Of course, if you didn't need to actually see what
> something expanded out to, because you knew you'd given a unique
> prefix of whatever was legal at that point, you could just move on to
> the next field and keep going.
> 
> There were various niceties, such as when typing question mark at the
> beginning of a field, the type of whatever's wanted would be printed
> (`a number', `a switch, one of ...', etc) and the legal values.  And,
> of course, since several different types of fields might be legal at a
> given point (say, an optional switch or a filename), it would list
> each of the potential field types and their values in turn.  Error
> cases were handled, such as being partway into a switch (note that
> switches and such usually were full words, like /width or /fullduplex)
> and hitting escape or question mark; this would elicit ringing the
> bell and printing something like `no legal values match current
> input', then reprinting the input line and waiting for more input.
> Everything described in this paragraph was handled by COMND%; the
> program itself had no knowledge that this happened.
> 
> Things could be much more ornate than summarized above.
> 
> The EXEC (roughly equivalent to a shell) used COMND% to read its
> input, just like any other application would.  For its built-in
> commands, it parsed the various fields just like any other program
> would/could (a lot of applications were inherited from TOPS-10, which
> didn't do that).  For external-to-EXEC programs, it just gathered
> everything up and handed it all to the program without trying to be
> smart.  It was possible to provide definition tables to EXEC to allow
> it to interactively parse command lines for other programs, but you
> lost a lot of the dynamism if you did so.
> 
> Unfortunately, that resulted in the major fault line in the scheme -
> some commands you had this nice interactive entry system guiding you
> through the possibilities in their command lines, and others it was
> pretty much just `arguments'.  For the built-ins, and for programs
> interacting with the user via COMND%, the result was an adaptive
> system that would hand-hold you just as much as you needed; newbies
> could be effectively spoon-fed, and experts could breeze right along.
> These are exactly equivalent commands, with action characters
> indicated and user input in lowercase (@ is the prompt):
> 
>     @inf<ESC> (ABOUT) t? ONE OF THE FOLLOWING:
>      TAPE-PARAMETERS
>      TERMINAL-MODE
>     @INFORMATION (ABOUT) Ter<ESC>
>      <various settings regarding the terminal are displayed>
> 
> or
> 
>     @i ter
>      <the same terminal settings>
> 
> </long-winded abbreviated overview of COMND%>
> 
> Unix tab completion was introduced in tcsh, which pretty much started
> as csh with tab completion added.  The `t' stands for `TOPS-20' (cf
> the section `THE T IN TCSH' in the tcsh man page).  It most closely
> mimics the actions of the TOPS-20 escape action character.
> 
> Completion's been extended into other areas with semi-dynamic
> abilities in more recent times (such as expanding the hostname as a
> parameter to slogin), and similar capabilities cross-pollinated into
> the various other Unix shells.  However (there's always a caveat ;-).
> With the exception of filenames, hostnames, and other long-winded
> values, the terseness of Unix command names and arguments makes it so
> that the sort of completion mechanism described above is pretty much
> totally useless.  It is, arguably, even of negative value since it
> encourages someone to attempt to do completion where it makes no
> sense.
> 
> So, Thierry's first principal idea as quoted above is pretty much
> exactly what EXEC used COMND% to do with its built-in commands and
> other applications did with their interactive commands.  Item 2
> becomes really ugly to achieve outside the application pretty quickly
> if you want to do anything dynamic (say, accept either a filename or a
> username as the next argument, but only a filename if a particular
> switch was set previously).  A long time ago, I toyed with the idea of
> trying to define a description language that shells could use for
> dealing with arbitrary programs' command lines (it would've been an
> extra ELF segment in the binary), but couldn't come up with a good way
> of handling the general case and couldn't really justify it because
> most command lines just weren't worth trying to deal with completion
> for.  Tcsh's generalized completion mechanism's about as close to
> acceptable as any other I've seen/come up with so far in terms of
> parsing things for other, totally unrelated programs.  Which is to
> say, not very.
> 
> I agree whole-heartedly with item 3.  But then, I've expressed my
> feelings about having to use a mouse when a keyboard would do before
> ;-)
> 
> As an aside, there is a C reimplementation (reimagining?) of the
> COMND% JSYS, called CCMD, which was developed on Unix.  It's a
> moderately-close equivalent, but handles far fewer field types.  There
> are a lot of cosmetic differences, but the basic model of how you
> gather and parse an input line follows pretty closely.  It *really*
> helps to have the TOPS-20 documentation of COMND% at hand, though.
> Most of the differences are probably because TOPS-20 applications
> generally were written in MACRO-20 (assembly code) not C.  Some
> programming idioms don't fully translate....
> 
> On Thu, 7 Aug 2025 20:50:47 +0200, hiro <23hiro@gmail.com> wrote:
> 23hiro> I think there are some obvious reasons why Plan9 people never missed
> 23hiro> TAB completion as in BASH, ZSH, and other bloated linux programs.
> 23hiro> 1) we have less arguments, thus most can remember them.
> 23hiro> 2) we ask people to use file-globbing
> 23hiro> 3) we ask people to keep names short, and easy to type and not only meaningful.
> 23hiro> 4) there are many known ways to limit scope so that names can stay
> 23hiro> short and still meaningful.
> 23hiro> [...]
> 23hiro> One thing that I noticed very early on is that tab-complete seemed
> 23hiro> like a good idea that never got implemented fully:
> 23hiro> if some applications come with BNF style grammar in the documentation
> 23hiro> for the arguments, why does tab completion not show these multiple
> 23hiro> options? why does it only ever show a single option? i think because
> 23hiro> typewriters suck.
> 
> It got implemented fully, just not in the Unix world.  And that's
> because it just wasn't fit for purpose in that context.
> 
> I would point out that there are situations where file-globbing
> doesn't really work well.  Regexps or name completion can sometimes
> work much better.  It depends a lot on the context you're working in.
> I suspect this falls into the general argument bucket of whether you
> use Plan 9 for OS research/hacking or as a platform for non-OS work.
> Short command names, especially combined with namespaces (whether in
> the Plan 9 sense or as subdirectories [cf auth/, ip/, etc]) aren't
> difficult.  But if you have hundreds of data files, and need to refer
> to a specific one, globbing's not necessarily well-suited to the task.
> 
> Dworkin

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-M5d96cd3fe2419354b7cb8e8f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 13085 bytes --]

Keeping this short: Is there a place in this for a pls server for latex?
There are pls commands that work in acme.

On Fri, Aug 8, 2025 at 8:28 AM <tlaronde@kergis.com> wrote:

> On Thu, Aug 07, 2025 at 08:50:47PM +0200, hiro wrote:
> > This seems quite interesting to me but i didn't understand most of it,
> > i'll just concentrate on your first proposal in 1).
> >
> > I think there are some obvious reasons why Plan9 people never missed
> > TAB completion as in BASH, ZSH, and other bloated linux programs.
> > 1) we have less arguments, thus most can remember them.
> > 2) we ask people to use file-globbing
> > 3) we ask people to keep names short, and easy to type and not only
> meaningful.
> > 4) there are many known ways to limit scope so that names can stay
> > short and still meaningful.
>
> That the core utilities be as "elementary" as possible, limiting the
> number of options and using short meaning names, is obviously good.
>
> But a system is not only used as-is, but with additional utilities
> whose complexity grows when being more and more "high" (i.e.: derived)
> user level.
>
> So such a feature has not to be evaluated only for core utilities, but
> for other higher user space programs.
>
> This common scheme could impose consistency on arguments values, and
> consistency of user interface (whether 1D: line interface, or 2D
> interface: GUI---curses, contrary to common belief, is 2D so is a
> limited GUI).
>
> > 5) there's a file completion hack in rio (ctrl-f), though it's not
> > really used by many bec. it never works: it runs in the parent rio
> > namespace that doesnt see child mounts.
>
> During IWP9 was presented Lola by Angelo Papenhoff. I do think that
> it is right to work on the GUI and that we can do something Plan9'ish
> that is simple, consistent, and have not much to do with other
> windowing systems---I think getting things altogether from 8 1/2, rio
> and Lola. I wouldn't like to have X11! on Plan9 and neither curses!
> (God forbid!) that is a suboptimal compromise between the console and
> the graphical 2D interface.
>
> To try to sketch the "big" idea (but I'm working on pieces for now, to
> gather knowledge to refine the "big" idea---may be dropping it, or
> dropping some of it):
>
> 1) For every program are defined stdin, stdout and stderr. On a
> "console" (not a 2D interface), echoing stdin, displaying stdout or
> stderr is done at the very same place. With a 2D interface, stdin
> should be taken from a window on top, stdout displayed on main middle
> window, and stderr displayed on the bottom window (one can call them
> "panels" of a main window). [Am I not re-inventing Acme?]
>
> 2) Every program (the same can be done for rc(1) scripts) defines the
> syntax and even semantics of its arguments. So dialoguing to get the
> right arguments is made from within the command (and this should be
> recursive, if one of the arguments is a command, then getting the
> right arguments to this subcommand would be made by the same
> mechanism). But there are three distinct things:
>
>         a) Editing the line (lexical stage): just to put, retrieve,
>         modify, correct the line to input. Since I would want to be
>         able to use the regex, selecting a previous line etc. in fact
>         I'm simply re-inventing ed(1)... So it would be ed'iting;
>
>         b) Checking the grammar (syntactical stage): from inside the
>         command, using the Parm array a whatever parm Server dialogs
>         with the user (dumb parm Server: checks and exits with success
>         or error; or 1D dialog; or 2D graphical display to fill the
>         options);
>
>         c) Doing the stuff (semantical stage): the arguments are valid
>         from b), the utility does its job.
>
> 3) There is no reason to have several versions of the same program: an
> utility can be used via lines (command lines) or via graphical
> interface, and its result (stdout) can be as is or "rendered". With a
> graphical interface, all the "menus" to select commands or getting
> arguments are generated automatically from the Parm array description
> (sub-commands being whether "drop-down" or "pop-up"; the graphical
> interface should allow to call itself in a subwindow) the resulting
> being sent to one (at a time; could be several displaying windows,
> with selection of the current one to send the result to be displayed),
> the result window being whether "raw" (it just displays a succession
> of bytes), "text" (it just displays chars according to utf8 in a
> selected font) or  "graphical" (it draws primitives). A "rendered"
> text is a special case of using "graphical".
>
> When it comes to rendering, as I have sketched during IWP9, one has to
> rasterize, and METAFONT is a rasterizer. So one of the things I'm
> thinking about is how to extend DVI to allow to embed DVI in DVI, to
> add the drawing primitives so that a glyph can be described (not
> rasterized) in DVI, to allow to simply append supplementary drawing
> instructions on some pages, or to add pages to an existing document
> without touching it (the case of signed PDF, where you append
> modifications without touching what has been signed, simply redefining
> the xrefs to reach also the previous ones, the reading starting at the
> end of the document to the first "/^%EOF/") etc. and extracting the
> rasterizing routines from METAFONT.
>
> This will very probably and for good reasons seem fuzzy, but the first
> part (ed'iting and describing the syntax in main() to check or rework
> arguments before processing) is easy---less when it comes to
> implementing the help about arguments inside TeX proper.
>
> This will be all for today :-)
>
> >
> > There are also non-obvious reasons.
> > One thing that I noticed very early on is that tab-complete seemed
> > like a good idea that never got implemented fully:
> > if some applications come with BNF style grammar in the documentation
> > for the arguments, why does tab completion not show these multiple
> > options? why does it only ever show a single option? i think because
> > typewriters suck.
> > in a graphical os like plan9 it might be much easier to graphically
> > document via a second rio window the possible extensions of current
> > text line without using horrible ncurses extensions..
> >
> > example:
> > imagine you typed
> > ssh linux ip route a
> >
> > program could check your last line in /dev/text against it's
> > cross-operating system BNF database and help you show the following
> > valid remaining options:
> >
> > ssh linux ip route a{ add | append } ROUTE
> > ROUTE := NODE_SPEC [ INFO_SPEC ]
> >
> > then you type on
> > ssh linux ip route add
> > and focus the other rio window again (alternative use a plumbing event
> > instead of focus) to get this next multi-line recommendation:
> >
> > ssh linux ip route add ROUTE
> > ROUTE := NODE_SPEC [ INFO_SPEC ]
> > NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
> >             [ table TABLE_ID ] [ proto RTPROTO ]
> >             [ scope SCOPE ] [ metric METRIC ]
> >             [ ttl-propagate { enabled | disabled } ]
> > INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...
> >
> > now you might realize you might want a better GUI where you can
> > include/exclude parts of this tree to find an easy completion-path.
> > seems a bit more involved but very possible since we have real GUIs.
> > Probably GUIs are too difficult for unix people, it's even harder in
> > TUI apps, and tab-completion = good enuff for them?
> >
> > anyways, good man pages and low complexity are easier. we have no BNF
> > docs or complex multidimensional arguments like in iproute2 anyways ;)
> >
> > On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com> wrote:
> > >
> > > As I have tried to explain concerning TeX during IWP9, TeX is only C89
> > > and I want it to behave exactly the same whatever the hosting OS is.
> > > Because if joe user uses TeX, if it behaves exactly the same on
> > > whatever OS, there is no impossibility to swap the OS underneath.
> > >
> > > While thinking about the way an interactive session with TeX works,
> > > I'm currently thinking about the line editing feature---not a big
> > > problem, because TeX calls a C89 routine to get the next line, and the
> > > editing is the "spoon" before entering the "mouth" i.e. it is outside
> > > TeX altogether.
> > >
> > > But I was thinking about also of a way to behave more helpfully about
> > > macros: since the macros are digested, TeX knows what is their syntax,
> > > what is the type of arguments and so on, so could display an help
> > > about the usage (this has to be done in TeX proper) and there could be
> > > a better editing of incorrect arguments in an interactive session.
> > >
> > > But this is TeX internals. The question about the usage and the
> > > interactive editing of arguments (and the correction of partially
> > > incorrect arguments) could be done also more generally with any
> > > utility, including, depending on the terminal, using different
> > > arguments handling.
> > >
> > > There is prior partial art: limited getopt(3) on Unix; a more general
> > > handling routine in C.E.R.L. GRASS that takes the argc and argv[],
> > > verifying type of argument, range, setting default values and engaging,
> > > if interactive, a dialog with the user whether to get the mandatory
> > > arguments if not provided or to correct the incorrect ones.
> > >
> > > In pseudo C, a utility (an equivalent can be made for a rc script)
> > > would set an array of this:
> > >
> > > typedef struct {
> > >         int cat;
> > > #define PARM_CAT_EOP    0       /* final sentry of array */
> > > #define PARM_CAT_FLAG   0x01    /* "-h" like */
> > > #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
> > > #define PARM_CAT_ARG    0x04    /* positional arg */
> > >
> > > char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
> > >                 /* positional is not counting flags and options */
> > > int flags;
> > > #define PARM_FLAG_MANDATORY     0x01
> > > #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
> > >
> > > int type;
> > > #define PARM_TYPE_STRING        0
> > > #define PARM_TYPE_INT           1
> > > #define PARM_TYPE_FLOAT         2
> > > #define PARM_TYPE_PATH          3
> > >
> > > char *range;    /* acceptable range of values for numbers */
> > >                 /* a regex for strings and paths */
> > > /* for following require and forbid, index of PARM_CAT_EOP is
> > >   end of array
> > >  */
> > > int *require;   /* an array of indices of parms required with */
> > > int *forbid;    /* an array of indices of conflicting parms */
> > > char *default;
> > > char *description;
> > > /* these are filled in return */
> > > int nval;       /* count of values */
> > > char **val;
> > > } Parm;
> > >
> > > Depending on what server is attached for serving arguments, if none,
> > > the syntax is verified as well as the ranges, the defaults being
> > > set, and it exits on error sending usage on stderr without modifying
> > > the arguments served.
> > >
> > > A line oriented server could engage a dialog with the user to correct
> > > arguments or to ask for missing arguments.
> > >
> > > A 2D oriented server could do this by displaying a graphical interface
> > > to get the arguments if not provided or incorrectly provided.
> > >
> > > The three principal ideas being:
> > >
> > > 1) that a utility has the information about what arguments it
> > > expects so say that an extension of the Unix like "tab-completion"
> after
> > > a utility name would display the usage, because it is served from
> > > inside the utility;
> > >
> > > 2) that such a description can provide immediately an usage without
> > > having to write the code, and that the handling of ranges, types and so
> > > on have not to be repeated in every utility;
> > >
> > > 3) that a graphical interface is just another way of getting arguments,
> > > and there should be no necessity to program a special version of a
> > > utility to change the way the arguments are provided.
> > >
> > > Is such an idea totally orthogonal to Plan9?
> > > --
> > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > >              http://www.kergis.com/
> > >             http://kertex.kergis.com/
> > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-Meabd424a93dfaa4ea45255e0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 17765 bytes --]

Re: [9fans] parm server: user interaction

[tlaronde]

On Fri, Aug 08, 2025 at 08:35:55AM -0700, ron minnich wrote:
> Keeping this short: Is there a place in this for a pls server for latex?
> There are pls commands that work in acme.

What does "pls" mean in this context? In TeX, this can be Property
Lists, dealing with virtual fonts, but I'm almost sure this is not
it. So what is "pls" relating to latex?

> 
> On Fri, Aug 8, 2025 at 8:28?AM <tlaronde@kergis.com> wrote:
> 
> > On Thu, Aug 07, 2025 at 08:50:47PM +0200, hiro wrote:
> > > This seems quite interesting to me but i didn't understand most of it,
> > > i'll just concentrate on your first proposal in 1).
> > >
> > > I think there are some obvious reasons why Plan9 people never missed
> > > TAB completion as in BASH, ZSH, and other bloated linux programs.
> > > 1) we have less arguments, thus most can remember them.
> > > 2) we ask people to use file-globbing
> > > 3) we ask people to keep names short, and easy to type and not only
> > meaningful.
> > > 4) there are many known ways to limit scope so that names can stay
> > > short and still meaningful.
> >
> > That the core utilities be as "elementary" as possible, limiting the
> > number of options and using short meaning names, is obviously good.
> >
> > But a system is not only used as-is, but with additional utilities
> > whose complexity grows when being more and more "high" (i.e.: derived)
> > user level.
> >
> > So such a feature has not to be evaluated only for core utilities, but
> > for other higher user space programs.
> >
> > This common scheme could impose consistency on arguments values, and
> > consistency of user interface (whether 1D: line interface, or 2D
> > interface: GUI---curses, contrary to common belief, is 2D so is a
> > limited GUI).
> >
> > > 5) there's a file completion hack in rio (ctrl-f), though it's not
> > > really used by many bec. it never works: it runs in the parent rio
> > > namespace that doesnt see child mounts.
> >
> > During IWP9 was presented Lola by Angelo Papenhoff. I do think that
> > it is right to work on the GUI and that we can do something Plan9'ish
> > that is simple, consistent, and have not much to do with other
> > windowing systems---I think getting things altogether from 8 1/2, rio
> > and Lola. I wouldn't like to have X11! on Plan9 and neither curses!
> > (God forbid!) that is a suboptimal compromise between the console and
> > the graphical 2D interface.
> >
> > To try to sketch the "big" idea (but I'm working on pieces for now, to
> > gather knowledge to refine the "big" idea---may be dropping it, or
> > dropping some of it):
> >
> > 1) For every program are defined stdin, stdout and stderr. On a
> > "console" (not a 2D interface), echoing stdin, displaying stdout or
> > stderr is done at the very same place. With a 2D interface, stdin
> > should be taken from a window on top, stdout displayed on main middle
> > window, and stderr displayed on the bottom window (one can call them
> > "panels" of a main window). [Am I not re-inventing Acme?]
> >
> > 2) Every program (the same can be done for rc(1) scripts) defines the
> > syntax and even semantics of its arguments. So dialoguing to get the
> > right arguments is made from within the command (and this should be
> > recursive, if one of the arguments is a command, then getting the
> > right arguments to this subcommand would be made by the same
> > mechanism). But there are three distinct things:
> >
> >         a) Editing the line (lexical stage): just to put, retrieve,
> >         modify, correct the line to input. Since I would want to be
> >         able to use the regex, selecting a previous line etc. in fact
> >         I'm simply re-inventing ed(1)... So it would be ed'iting;
> >
> >         b) Checking the grammar (syntactical stage): from inside the
> >         command, using the Parm array a whatever parm Server dialogs
> >         with the user (dumb parm Server: checks and exits with success
> >         or error; or 1D dialog; or 2D graphical display to fill the
> >         options);
> >
> >         c) Doing the stuff (semantical stage): the arguments are valid
> >         from b), the utility does its job.
> >
> > 3) There is no reason to have several versions of the same program: an
> > utility can be used via lines (command lines) or via graphical
> > interface, and its result (stdout) can be as is or "rendered". With a
> > graphical interface, all the "menus" to select commands or getting
> > arguments are generated automatically from the Parm array description
> > (sub-commands being whether "drop-down" or "pop-up"; the graphical
> > interface should allow to call itself in a subwindow) the resulting
> > being sent to one (at a time; could be several displaying windows,
> > with selection of the current one to send the result to be displayed),
> > the result window being whether "raw" (it just displays a succession
> > of bytes), "text" (it just displays chars according to utf8 in a
> > selected font) or  "graphical" (it draws primitives). A "rendered"
> > text is a special case of using "graphical".
> >
> > When it comes to rendering, as I have sketched during IWP9, one has to
> > rasterize, and METAFONT is a rasterizer. So one of the things I'm
> > thinking about is how to extend DVI to allow to embed DVI in DVI, to
> > add the drawing primitives so that a glyph can be described (not
> > rasterized) in DVI, to allow to simply append supplementary drawing
> > instructions on some pages, or to add pages to an existing document
> > without touching it (the case of signed PDF, where you append
> > modifications without touching what has been signed, simply redefining
> > the xrefs to reach also the previous ones, the reading starting at the
> > end of the document to the first "/^%EOF/") etc. and extracting the
> > rasterizing routines from METAFONT.
> >
> > This will very probably and for good reasons seem fuzzy, but the first
> > part (ed'iting and describing the syntax in main() to check or rework
> > arguments before processing) is easy---less when it comes to
> > implementing the help about arguments inside TeX proper.
> >
> > This will be all for today :-)
> >
> > >
> > > There are also non-obvious reasons.
> > > One thing that I noticed very early on is that tab-complete seemed
> > > like a good idea that never got implemented fully:
> > > if some applications come with BNF style grammar in the documentation
> > > for the arguments, why does tab completion not show these multiple
> > > options? why does it only ever show a single option? i think because
> > > typewriters suck.
> > > in a graphical os like plan9 it might be much easier to graphically
> > > document via a second rio window the possible extensions of current
> > > text line without using horrible ncurses extensions..
> > >
> > > example:
> > > imagine you typed
> > > ssh linux ip route a
> > >
> > > program could check your last line in /dev/text against it's
> > > cross-operating system BNF database and help you show the following
> > > valid remaining options:
> > >
> > > ssh linux ip route a{ add | append } ROUTE
> > > ROUTE := NODE_SPEC [ INFO_SPEC ]
> > >
> > > then you type on
> > > ssh linux ip route add
> > > and focus the other rio window again (alternative use a plumbing event
> > > instead of focus) to get this next multi-line recommendation:
> > >
> > > ssh linux ip route add ROUTE
> > > ROUTE := NODE_SPEC [ INFO_SPEC ]
> > > NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
> > >             [ table TABLE_ID ] [ proto RTPROTO ]
> > >             [ scope SCOPE ] [ metric METRIC ]
> > >             [ ttl-propagate { enabled | disabled } ]
> > > INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...
> > >
> > > now you might realize you might want a better GUI where you can
> > > include/exclude parts of this tree to find an easy completion-path.
> > > seems a bit more involved but very possible since we have real GUIs.
> > > Probably GUIs are too difficult for unix people, it's even harder in
> > > TUI apps, and tab-completion = good enuff for them?
> > >
> > > anyways, good man pages and low complexity are easier. we have no BNF
> > > docs or complex multidimensional arguments like in iproute2 anyways ;)
> > >
> > > On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com> wrote:
> > > >
> > > > As I have tried to explain concerning TeX during IWP9, TeX is only C89
> > > > and I want it to behave exactly the same whatever the hosting OS is.
> > > > Because if joe user uses TeX, if it behaves exactly the same on
> > > > whatever OS, there is no impossibility to swap the OS underneath.
> > > >
> > > > While thinking about the way an interactive session with TeX works,
> > > > I'm currently thinking about the line editing feature---not a big
> > > > problem, because TeX calls a C89 routine to get the next line, and the
> > > > editing is the "spoon" before entering the "mouth" i.e. it is outside
> > > > TeX altogether.
> > > >
> > > > But I was thinking about also of a way to behave more helpfully about
> > > > macros: since the macros are digested, TeX knows what is their syntax,
> > > > what is the type of arguments and so on, so could display an help
> > > > about the usage (this has to be done in TeX proper) and there could be
> > > > a better editing of incorrect arguments in an interactive session.
> > > >
> > > > But this is TeX internals. The question about the usage and the
> > > > interactive editing of arguments (and the correction of partially
> > > > incorrect arguments) could be done also more generally with any
> > > > utility, including, depending on the terminal, using different
> > > > arguments handling.
> > > >
> > > > There is prior partial art: limited getopt(3) on Unix; a more general
> > > > handling routine in C.E.R.L. GRASS that takes the argc and argv[],
> > > > verifying type of argument, range, setting default values and engaging,
> > > > if interactive, a dialog with the user whether to get the mandatory
> > > > arguments if not provided or to correct the incorrect ones.
> > > >
> > > > In pseudo C, a utility (an equivalent can be made for a rc script)
> > > > would set an array of this:
> > > >
> > > > typedef struct {
> > > >         int cat;
> > > > #define PARM_CAT_EOP    0       /* final sentry of array */
> > > > #define PARM_CAT_FLAG   0x01    /* "-h" like */
> > > > #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
> > > > #define PARM_CAT_ARG    0x04    /* positional arg */
> > > >
> > > > char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
> > > >                 /* positional is not counting flags and options */
> > > > int flags;
> > > > #define PARM_FLAG_MANDATORY     0x01
> > > > #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
> > > >
> > > > int type;
> > > > #define PARM_TYPE_STRING        0
> > > > #define PARM_TYPE_INT           1
> > > > #define PARM_TYPE_FLOAT         2
> > > > #define PARM_TYPE_PATH          3
> > > >
> > > > char *range;    /* acceptable range of values for numbers */
> > > >                 /* a regex for strings and paths */
> > > > /* for following require and forbid, index of PARM_CAT_EOP is
> > > >   end of array
> > > >  */
> > > > int *require;   /* an array of indices of parms required with */
> > > > int *forbid;    /* an array of indices of conflicting parms */
> > > > char *default;
> > > > char *description;
> > > > /* these are filled in return */
> > > > int nval;       /* count of values */
> > > > char **val;
> > > > } Parm;
> > > >
> > > > Depending on what server is attached for serving arguments, if none,
> > > > the syntax is verified as well as the ranges, the defaults being
> > > > set, and it exits on error sending usage on stderr without modifying
> > > > the arguments served.
> > > >
> > > > A line oriented server could engage a dialog with the user to correct
> > > > arguments or to ask for missing arguments.
> > > >
> > > > A 2D oriented server could do this by displaying a graphical interface
> > > > to get the arguments if not provided or incorrectly provided.
> > > >
> > > > The three principal ideas being:
> > > >
> > > > 1) that a utility has the information about what arguments it
> > > > expects so say that an extension of the Unix like "tab-completion"
> > after
> > > > a utility name would display the usage, because it is served from
> > > > inside the utility;
> > > >
> > > > 2) that such a description can provide immediately an usage without
> > > > having to write the code, and that the handling of ranges, types and so
> > > > on have not to be repeated in every utility;
> > > >
> > > > 3) that a graphical interface is just another way of getting arguments,
> > > > and there should be no necessity to program a special version of a
> > > > utility to change the way the arguments are provided.
> > > >
> > > > Is such an idea totally orthogonal to Plan9?
> > > > --
> > > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > > >              http://www.kergis.com/
> > > >             http://kertex.kergis.com/
> > > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> > 
> > --
> > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >              http://www.kergis.com/
> >             http://kertex.kergis.com/
> > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-Mc7cf89cc9fc6e2118a01aa73
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[Steve Simon]

[-- Attachment #1: Type: text/html, Size: 18336 bytes --]

Re: [9fans] parm server: user interaction

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 14156 bytes --]

its a language parser api that IDEs use to analyse incomplete code files.

e.g. i use https://pkg.go.dev/golang.org/x/tools/gopls in zed.


the same pls syntax can be used to validate (and extract errors from) many languages


-Steve


> On 8 Aug 2025, at 8:52 pm, tlaronde@kergis.com wrote:
> 
> On Fri, Aug 08, 2025 at 08:35:55AM -0700, ron minnich wrote:
>> Keeping this short: Is there a place in this for a pls server for latex?
>> There are pls commands that work in acme.
> 
> What does "pls" mean in this context? In TeX, this can be Property
> Lists, dealing with virtual fonts, but I'm almost sure this is not
> it. So what is "pls" relating to latex?
> 
>>> On Fri, Aug 8, 2025 at 8:28?AM <tlaronde@kergis.com> wrote:
>>> 
>>> On Thu, Aug 07, 2025 at 08:50:47PM +0200, hiro wrote:
>>>> This seems quite interesting to me but i didn't understand most of it,
>>>> i'll just concentrate on your first proposal in 1).
>>>> 
>>>> I think there are some obvious reasons why Plan9 people never missed
>>>> TAB completion as in BASH, ZSH, and other bloated linux programs.
>>>> 1) we have less arguments, thus most can remember them.
>>>> 2) we ask people to use file-globbing
>>>> 3) we ask people to keep names short, and easy to type and not only
>>> meaningful.
>>>> 4) there are many known ways to limit scope so that names can stay
>>>> short and still meaningful.
>>> 
>>> That the core utilities be as "elementary" as possible, limiting the
>>> number of options and using short meaning names, is obviously good.
>>> 
>>> But a system is not only used as-is, but with additional utilities
>>> whose complexity grows when being more and more "high" (i.e.: derived)
>>> user level.
>>> 
>>> So such a feature has not to be evaluated only for core utilities, but
>>> for other higher user space programs.
>>> 
>>> This common scheme could impose consistency on arguments values, and
>>> consistency of user interface (whether 1D: line interface, or 2D
>>> interface: GUI---curses, contrary to common belief, is 2D so is a
>>> limited GUI).
>>> 
>>>> 5) there's a file completion hack in rio (ctrl-f), though it's not
>>>> really used by many bec. it never works: it runs in the parent rio
>>>> namespace that doesnt see child mounts.
>>> 
>>> During IWP9 was presented Lola by Angelo Papenhoff. I do think that
>>> it is right to work on the GUI and that we can do something Plan9'ish
>>> that is simple, consistent, and have not much to do with other
>>> windowing systems---I think getting things altogether from 8 1/2, rio
>>> and Lola. I wouldn't like to have X11! on Plan9 and neither curses!
>>> (God forbid!) that is a suboptimal compromise between the console and
>>> the graphical 2D interface.
>>> 
>>> To try to sketch the "big" idea (but I'm working on pieces for now, to
>>> gather knowledge to refine the "big" idea---may be dropping it, or
>>> dropping some of it):
>>> 
>>> 1) For every program are defined stdin, stdout and stderr. On a
>>> "console" (not a 2D interface), echoing stdin, displaying stdout or
>>> stderr is done at the very same place. With a 2D interface, stdin
>>> should be taken from a window on top, stdout displayed on main middle
>>> window, and stderr displayed on the bottom window (one can call them
>>> "panels" of a main window). [Am I not re-inventing Acme?]
>>> 
>>> 2) Every program (the same can be done for rc(1) scripts) defines the
>>> syntax and even semantics of its arguments. So dialoguing to get the
>>> right arguments is made from within the command (and this should be
>>> recursive, if one of the arguments is a command, then getting the
>>> right arguments to this subcommand would be made by the same
>>> mechanism). But there are three distinct things:
>>> 
>>>        a) Editing the line (lexical stage): just to put, retrieve,
>>>        modify, correct the line to input. Since I would want to be
>>>        able to use the regex, selecting a previous line etc. in fact
>>>        I'm simply re-inventing ed(1)... So it would be ed'iting;
>>> 
>>>        b) Checking the grammar (syntactical stage): from inside the
>>>        command, using the Parm array a whatever parm Server dialogs
>>>        with the user (dumb parm Server: checks and exits with success
>>>        or error; or 1D dialog; or 2D graphical display to fill the
>>>        options);
>>> 
>>>        c) Doing the stuff (semantical stage): the arguments are valid
>>>        from b), the utility does its job.
>>> 
>>> 3) There is no reason to have several versions of the same program: an
>>> utility can be used via lines (command lines) or via graphical
>>> interface, and its result (stdout) can be as is or "rendered". With a
>>> graphical interface, all the "menus" to select commands or getting
>>> arguments are generated automatically from the Parm array description
>>> (sub-commands being whether "drop-down" or "pop-up"; the graphical
>>> interface should allow to call itself in a subwindow) the resulting
>>> being sent to one (at a time; could be several displaying windows,
>>> with selection of the current one to send the result to be displayed),
>>> the result window being whether "raw" (it just displays a succession
>>> of bytes), "text" (it just displays chars according to utf8 in a
>>> selected font) or  "graphical" (it draws primitives). A "rendered"
>>> text is a special case of using "graphical".
>>> 
>>> When it comes to rendering, as I have sketched during IWP9, one has to
>>> rasterize, and METAFONT is a rasterizer. So one of the things I'm
>>> thinking about is how to extend DVI to allow to embed DVI in DVI, to
>>> add the drawing primitives so that a glyph can be described (not
>>> rasterized) in DVI, to allow to simply append supplementary drawing
>>> instructions on some pages, or to add pages to an existing document
>>> without touching it (the case of signed PDF, where you append
>>> modifications without touching what has been signed, simply redefining
>>> the xrefs to reach also the previous ones, the reading starting at the
>>> end of the document to the first "/^%EOF/") etc. and extracting the
>>> rasterizing routines from METAFONT.
>>> 
>>> This will very probably and for good reasons seem fuzzy, but the first
>>> part (ed'iting and describing the syntax in main() to check or rework
>>> arguments before processing) is easy---less when it comes to
>>> implementing the help about arguments inside TeX proper.
>>> 
>>> This will be all for today :-)
>>> 
>>>> 
>>>> There are also non-obvious reasons.
>>>> One thing that I noticed very early on is that tab-complete seemed
>>>> like a good idea that never got implemented fully:
>>>> if some applications come with BNF style grammar in the documentation
>>>> for the arguments, why does tab completion not show these multiple
>>>> options? why does it only ever show a single option? i think because
>>>> typewriters suck.
>>>> in a graphical os like plan9 it might be much easier to graphically
>>>> document via a second rio window the possible extensions of current
>>>> text line without using horrible ncurses extensions..
>>>> 
>>>> example:
>>>> imagine you typed
>>>> ssh linux ip route a
>>>> 
>>>> program could check your last line in /dev/text against it's
>>>> cross-operating system BNF database and help you show the following
>>>> valid remaining options:
>>>> 
>>>> ssh linux ip route a{ add | append } ROUTE
>>>> ROUTE := NODE_SPEC [ INFO_SPEC ]
>>>> 
>>>> then you type on
>>>> ssh linux ip route add
>>>> and focus the other rio window again (alternative use a plumbing event
>>>> instead of focus) to get this next multi-line recommendation:
>>>> 
>>>> ssh linux ip route add ROUTE
>>>> ROUTE := NODE_SPEC [ INFO_SPEC ]
>>>> NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
>>>>            [ table TABLE_ID ] [ proto RTPROTO ]
>>>>            [ scope SCOPE ] [ metric METRIC ]
>>>>            [ ttl-propagate { enabled | disabled } ]
>>>> INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...
>>>> 
>>>> now you might realize you might want a better GUI where you can
>>>> include/exclude parts of this tree to find an easy completion-path.
>>>> seems a bit more involved but very possible since we have real GUIs.
>>>> Probably GUIs are too difficult for unix people, it's even harder in
>>>> TUI apps, and tab-completion = good enuff for them?
>>>> 
>>>> anyways, good man pages and low complexity are easier. we have no BNF
>>>> docs or complex multidimensional arguments like in iproute2 anyways ;)
>>>> 
>>>> On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com> wrote:
>>>>> 
>>>>> As I have tried to explain concerning TeX during IWP9, TeX is only C89
>>>>> and I want it to behave exactly the same whatever the hosting OS is.
>>>>> Because if joe user uses TeX, if it behaves exactly the same on
>>>>> whatever OS, there is no impossibility to swap the OS underneath.
>>>>> 
>>>>> While thinking about the way an interactive session with TeX works,
>>>>> I'm currently thinking about the line editing feature---not a big
>>>>> problem, because TeX calls a C89 routine to get the next line, and the
>>>>> editing is the "spoon" before entering the "mouth" i.e. it is outside
>>>>> TeX altogether.
>>>>> 
>>>>> But I was thinking about also of a way to behave more helpfully about
>>>>> macros: since the macros are digested, TeX knows what is their syntax,
>>>>> what is the type of arguments and so on, so could display an help
>>>>> about the usage (this has to be done in TeX proper) and there could be
>>>>> a better editing of incorrect arguments in an interactive session.
>>>>> 
>>>>> But this is TeX internals. The question about the usage and the
>>>>> interactive editing of arguments (and the correction of partially
>>>>> incorrect arguments) could be done also more generally with any
>>>>> utility, including, depending on the terminal, using different
>>>>> arguments handling.
>>>>> 
>>>>> There is prior partial art: limited getopt(3) on Unix; a more general
>>>>> handling routine in C.E.R.L. GRASS that takes the argc and argv[],
>>>>> verifying type of argument, range, setting default values and engaging,
>>>>> if interactive, a dialog with the user whether to get the mandatory
>>>>> arguments if not provided or to correct the incorrect ones.
>>>>> 
>>>>> In pseudo C, a utility (an equivalent can be made for a rc script)
>>>>> would set an array of this:
>>>>> 
>>>>> typedef struct {
>>>>>        int cat;
>>>>> #define PARM_CAT_EOP    0       /* final sentry of array */
>>>>> #define PARM_CAT_FLAG   0x01    /* "-h" like */
>>>>> #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
>>>>> #define PARM_CAT_ARG    0x04    /* positional arg */
>>>>> 
>>>>> char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
>>>>>                /* positional is not counting flags and options */
>>>>> int flags;
>>>>> #define PARM_FLAG_MANDATORY     0x01
>>>>> #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
>>>>> 
>>>>> int type;
>>>>> #define PARM_TYPE_STRING        0
>>>>> #define PARM_TYPE_INT           1
>>>>> #define PARM_TYPE_FLOAT         2
>>>>> #define PARM_TYPE_PATH          3
>>>>> 
>>>>> char *range;    /* acceptable range of values for numbers */
>>>>>                /* a regex for strings and paths */
>>>>> /* for following require and forbid, index of PARM_CAT_EOP is
>>>>>  end of array
>>>>> */
>>>>> int *require;   /* an array of indices of parms required with */
>>>>> int *forbid;    /* an array of indices of conflicting parms */
>>>>> char *default;
>>>>> char *description;
>>>>> /* these are filled in return */
>>>>> int nval;       /* count of values */
>>>>> char **val;
>>>>> } Parm;
>>>>> 
>>>>> Depending on what server is attached for serving arguments, if none,
>>>>> the syntax is verified as well as the ranges, the defaults being
>>>>> set, and it exits on error sending usage on stderr without modifying
>>>>> the arguments served.
>>>>> 
>>>>> A line oriented server could engage a dialog with the user to correct
>>>>> arguments or to ask for missing arguments.
>>>>> 
>>>>> A 2D oriented server could do this by displaying a graphical interface
>>>>> to get the arguments if not provided or incorrectly provided.
>>>>> 
>>>>> The three principal ideas being:
>>>>> 
>>>>> 1) that a utility has the information about what arguments it
>>>>> expects so say that an extension of the Unix like "tab-completion"
>>> after
>>>>> a utility name would display the usage, because it is served from
>>>>> inside the utility;
>>>>> 
>>>>> 2) that such a description can provide immediately an usage without
>>>>> having to write the code, and that the handling of ranges, types and so
>>>>> on have not to be repeated in every utility;
>>>>> 
>>>>> 3) that a graphical interface is just another way of getting arguments,
>>>>> and there should be no necessity to program a special version of a
>>>>> utility to change the way the arguments are provided.
>>>>> 
>>>>> Is such an idea totally orthogonal to Plan9?
>>>>> --
>>>>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>>>>>             http://www.kergis.com/
>>>>>            http://kertex.kergis.com/
>>>>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>>> 
>>> --
>>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>>>             http://www.kergis.com/
>>>            http://kertex.kergis.com/
>>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-M070fec62ea998fc072f4abc4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 49414 bytes --]

Re: [9fans] parm server: user interaction

[tlaronde]

On Fri, Aug 08, 2025 at 09:03:56PM +0200, Steve Simon wrote:
> its a language parser api that IDEs use to analyse incomplete code files.
> 
> e.g. i use https://pkg.go.dev/golang.org/x/tools/gopls in zed.
> 
> 
> the same pls syntax can be used to validate (and extract errors from) many languages
> 

OK. I will have to look at this but the only thing I'm sure about, is
that, in the TeX case, TeX has to be involved in the process (to be
called to validate) because TeX has the property to allow to change
the category of characters: there are no fixed terminals; they can vary.

So if it is really a "protocol", i.e.  a convention about exchanges,
why not. If it implies first to definitively describe the syntax,
I'm almost sure that it will never work completely with TeX, but only
for some fixed and defined subsets of macros...

> 
> 
> > On 8 Aug 2025, at 8:52?pm, tlaronde@kergis.com wrote:
> > 
> > ?On Fri, Aug 08, 2025 at 08:35:55AM -0700, ron minnich wrote:
> >> Keeping this short: Is there a place in this for a pls server for latex?
> >> There are pls commands that work in acme.
> > 
> > What does "pls" mean in this context? In TeX, this can be Property
> > Lists, dealing with virtual fonts, but I'm almost sure this is not
> > it. So what is "pls" relating to latex?
> > 
> >>> On Fri, Aug 8, 2025 at 8:28?AM <tlaronde@kergis.com> wrote:
> >>> 
> >>> On Thu, Aug 07, 2025 at 08:50:47PM +0200, hiro wrote:
> >>>> This seems quite interesting to me but i didn't understand most of it,
> >>>> i'll just concentrate on your first proposal in 1).
> >>>> 
> >>>> I think there are some obvious reasons why Plan9 people never missed
> >>>> TAB completion as in BASH, ZSH, and other bloated linux programs.
> >>>> 1) we have less arguments, thus most can remember them.
> >>>> 2) we ask people to use file-globbing
> >>>> 3) we ask people to keep names short, and easy to type and not only
> >>> meaningful.
> >>>> 4) there are many known ways to limit scope so that names can stay
> >>>> short and still meaningful.
> >>> 
> >>> That the core utilities be as "elementary" as possible, limiting the
> >>> number of options and using short meaning names, is obviously good.
> >>> 
> >>> But a system is not only used as-is, but with additional utilities
> >>> whose complexity grows when being more and more "high" (i.e.: derived)
> >>> user level.
> >>> 
> >>> So such a feature has not to be evaluated only for core utilities, but
> >>> for other higher user space programs.
> >>> 
> >>> This common scheme could impose consistency on arguments values, and
> >>> consistency of user interface (whether 1D: line interface, or 2D
> >>> interface: GUI---curses, contrary to common belief, is 2D so is a
> >>> limited GUI).
> >>> 
> >>>> 5) there's a file completion hack in rio (ctrl-f), though it's not
> >>>> really used by many bec. it never works: it runs in the parent rio
> >>>> namespace that doesnt see child mounts.
> >>> 
> >>> During IWP9 was presented Lola by Angelo Papenhoff. I do think that
> >>> it is right to work on the GUI and that we can do something Plan9'ish
> >>> that is simple, consistent, and have not much to do with other
> >>> windowing systems---I think getting things altogether from 8 1/2, rio
> >>> and Lola. I wouldn't like to have X11! on Plan9 and neither curses!
> >>> (God forbid!) that is a suboptimal compromise between the console and
> >>> the graphical 2D interface.
> >>> 
> >>> To try to sketch the "big" idea (but I'm working on pieces for now, to
> >>> gather knowledge to refine the "big" idea---may be dropping it, or
> >>> dropping some of it):
> >>> 
> >>> 1) For every program are defined stdin, stdout and stderr. On a
> >>> "console" (not a 2D interface), echoing stdin, displaying stdout or
> >>> stderr is done at the very same place. With a 2D interface, stdin
> >>> should be taken from a window on top, stdout displayed on main middle
> >>> window, and stderr displayed on the bottom window (one can call them
> >>> "panels" of a main window). [Am I not re-inventing Acme?]
> >>> 
> >>> 2) Every program (the same can be done for rc(1) scripts) defines the
> >>> syntax and even semantics of its arguments. So dialoguing to get the
> >>> right arguments is made from within the command (and this should be
> >>> recursive, if one of the arguments is a command, then getting the
> >>> right arguments to this subcommand would be made by the same
> >>> mechanism). But there are three distinct things:
> >>> 
> >>>        a) Editing the line (lexical stage): just to put, retrieve,
> >>>        modify, correct the line to input. Since I would want to be
> >>>        able to use the regex, selecting a previous line etc. in fact
> >>>        I'm simply re-inventing ed(1)... So it would be ed'iting;
> >>> 
> >>>        b) Checking the grammar (syntactical stage): from inside the
> >>>        command, using the Parm array a whatever parm Server dialogs
> >>>        with the user (dumb parm Server: checks and exits with success
> >>>        or error; or 1D dialog; or 2D graphical display to fill the
> >>>        options);
> >>> 
> >>>        c) Doing the stuff (semantical stage): the arguments are valid
> >>>        from b), the utility does its job.
> >>> 
> >>> 3) There is no reason to have several versions of the same program: an
> >>> utility can be used via lines (command lines) or via graphical
> >>> interface, and its result (stdout) can be as is or "rendered". With a
> >>> graphical interface, all the "menus" to select commands or getting
> >>> arguments are generated automatically from the Parm array description
> >>> (sub-commands being whether "drop-down" or "pop-up"; the graphical
> >>> interface should allow to call itself in a subwindow) the resulting
> >>> being sent to one (at a time; could be several displaying windows,
> >>> with selection of the current one to send the result to be displayed),
> >>> the result window being whether "raw" (it just displays a succession
> >>> of bytes), "text" (it just displays chars according to utf8 in a
> >>> selected font) or  "graphical" (it draws primitives). A "rendered"
> >>> text is a special case of using "graphical".
> >>> 
> >>> When it comes to rendering, as I have sketched during IWP9, one has to
> >>> rasterize, and METAFONT is a rasterizer. So one of the things I'm
> >>> thinking about is how to extend DVI to allow to embed DVI in DVI, to
> >>> add the drawing primitives so that a glyph can be described (not
> >>> rasterized) in DVI, to allow to simply append supplementary drawing
> >>> instructions on some pages, or to add pages to an existing document
> >>> without touching it (the case of signed PDF, where you append
> >>> modifications without touching what has been signed, simply redefining
> >>> the xrefs to reach also the previous ones, the reading starting at the
> >>> end of the document to the first "/^%EOF/") etc. and extracting the
> >>> rasterizing routines from METAFONT.
> >>> 
> >>> This will very probably and for good reasons seem fuzzy, but the first
> >>> part (ed'iting and describing the syntax in main() to check or rework
> >>> arguments before processing) is easy---less when it comes to
> >>> implementing the help about arguments inside TeX proper.
> >>> 
> >>> This will be all for today :-)
> >>> 
> >>>> 
> >>>> There are also non-obvious reasons.
> >>>> One thing that I noticed very early on is that tab-complete seemed
> >>>> like a good idea that never got implemented fully:
> >>>> if some applications come with BNF style grammar in the documentation
> >>>> for the arguments, why does tab completion not show these multiple
> >>>> options? why does it only ever show a single option? i think because
> >>>> typewriters suck.
> >>>> in a graphical os like plan9 it might be much easier to graphically
> >>>> document via a second rio window the possible extensions of current
> >>>> text line without using horrible ncurses extensions..
> >>>> 
> >>>> example:
> >>>> imagine you typed
> >>>> ssh linux ip route a
> >>>> 
> >>>> program could check your last line in /dev/text against it's
> >>>> cross-operating system BNF database and help you show the following
> >>>> valid remaining options:
> >>>> 
> >>>> ssh linux ip route a{ add | append } ROUTE
> >>>> ROUTE := NODE_SPEC [ INFO_SPEC ]
> >>>> 
> >>>> then you type on
> >>>> ssh linux ip route add
> >>>> and focus the other rio window again (alternative use a plumbing event
> >>>> instead of focus) to get this next multi-line recommendation:
> >>>> 
> >>>> ssh linux ip route add ROUTE
> >>>> ROUTE := NODE_SPEC [ INFO_SPEC ]
> >>>> NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
> >>>>            [ table TABLE_ID ] [ proto RTPROTO ]
> >>>>            [ scope SCOPE ] [ metric METRIC ]
> >>>>            [ ttl-propagate { enabled | disabled } ]
> >>>> INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...
> >>>> 
> >>>> now you might realize you might want a better GUI where you can
> >>>> include/exclude parts of this tree to find an easy completion-path.
> >>>> seems a bit more involved but very possible since we have real GUIs.
> >>>> Probably GUIs are too difficult for unix people, it's even harder in
> >>>> TUI apps, and tab-completion = good enuff for them?
> >>>> 
> >>>> anyways, good man pages and low complexity are easier. we have no BNF
> >>>> docs or complex multidimensional arguments like in iproute2 anyways ;)
> >>>> 
> >>>> On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com> wrote:
> >>>>> 
> >>>>> As I have tried to explain concerning TeX during IWP9, TeX is only C89
> >>>>> and I want it to behave exactly the same whatever the hosting OS is.
> >>>>> Because if joe user uses TeX, if it behaves exactly the same on
> >>>>> whatever OS, there is no impossibility to swap the OS underneath.
> >>>>> 
> >>>>> While thinking about the way an interactive session with TeX works,
> >>>>> I'm currently thinking about the line editing feature---not a big
> >>>>> problem, because TeX calls a C89 routine to get the next line, and the
> >>>>> editing is the "spoon" before entering the "mouth" i.e. it is outside
> >>>>> TeX altogether.
> >>>>> 
> >>>>> But I was thinking about also of a way to behave more helpfully about
> >>>>> macros: since the macros are digested, TeX knows what is their syntax,
> >>>>> what is the type of arguments and so on, so could display an help
> >>>>> about the usage (this has to be done in TeX proper) and there could be
> >>>>> a better editing of incorrect arguments in an interactive session.
> >>>>> 
> >>>>> But this is TeX internals. The question about the usage and the
> >>>>> interactive editing of arguments (and the correction of partially
> >>>>> incorrect arguments) could be done also more generally with any
> >>>>> utility, including, depending on the terminal, using different
> >>>>> arguments handling.
> >>>>> 
> >>>>> There is prior partial art: limited getopt(3) on Unix; a more general
> >>>>> handling routine in C.E.R.L. GRASS that takes the argc and argv[],
> >>>>> verifying type of argument, range, setting default values and engaging,
> >>>>> if interactive, a dialog with the user whether to get the mandatory
> >>>>> arguments if not provided or to correct the incorrect ones.
> >>>>> 
> >>>>> In pseudo C, a utility (an equivalent can be made for a rc script)
> >>>>> would set an array of this:
> >>>>> 
> >>>>> typedef struct {
> >>>>>        int cat;
> >>>>> #define PARM_CAT_EOP    0       /* final sentry of array */
> >>>>> #define PARM_CAT_FLAG   0x01    /* "-h" like */
> >>>>> #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
> >>>>> #define PARM_CAT_ARG    0x04    /* positional arg */
> >>>>> 
> >>>>> char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
> >>>>>                /* positional is not counting flags and options */
> >>>>> int flags;
> >>>>> #define PARM_FLAG_MANDATORY     0x01
> >>>>> #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
> >>>>> 
> >>>>> int type;
> >>>>> #define PARM_TYPE_STRING        0
> >>>>> #define PARM_TYPE_INT           1
> >>>>> #define PARM_TYPE_FLOAT         2
> >>>>> #define PARM_TYPE_PATH          3
> >>>>> 
> >>>>> char *range;    /* acceptable range of values for numbers */
> >>>>>                /* a regex for strings and paths */
> >>>>> /* for following require and forbid, index of PARM_CAT_EOP is
> >>>>>  end of array
> >>>>> */
> >>>>> int *require;   /* an array of indices of parms required with */
> >>>>> int *forbid;    /* an array of indices of conflicting parms */
> >>>>> char *default;
> >>>>> char *description;
> >>>>> /* these are filled in return */
> >>>>> int nval;       /* count of values */
> >>>>> char **val;
> >>>>> } Parm;
> >>>>> 
> >>>>> Depending on what server is attached for serving arguments, if none,
> >>>>> the syntax is verified as well as the ranges, the defaults being
> >>>>> set, and it exits on error sending usage on stderr without modifying
> >>>>> the arguments served.
> >>>>> 
> >>>>> A line oriented server could engage a dialog with the user to correct
> >>>>> arguments or to ask for missing arguments.
> >>>>> 
> >>>>> A 2D oriented server could do this by displaying a graphical interface
> >>>>> to get the arguments if not provided or incorrectly provided.
> >>>>> 
> >>>>> The three principal ideas being:
> >>>>> 
> >>>>> 1) that a utility has the information about what arguments it
> >>>>> expects so say that an extension of the Unix like "tab-completion"
> >>> after
> >>>>> a utility name would display the usage, because it is served from
> >>>>> inside the utility;
> >>>>> 
> >>>>> 2) that such a description can provide immediately an usage without
> >>>>> having to write the code, and that the handling of ranges, types and so
> >>>>> on have not to be repeated in every utility;
> >>>>> 
> >>>>> 3) that a graphical interface is just another way of getting arguments,
> >>>>> and there should be no necessity to program a special version of a
> >>>>> utility to change the way the arguments are provided.
> >>>>> 
> >>>>> Is such an idea totally orthogonal to Plan9?
> >>>>> --
> >>>>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >>>>>             http://www.kergis.com/
> >>>>>            http://kertex.kergis.com/
> >>>>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> >>> 
> >>> --
> >>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >>>             http://www.kergis.com/
> >>>            http://kertex.kergis.com/
> >>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> > 
> > --
> > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> >              http://www.kergis.com/
> >             http://kertex.kergis.com/
> > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-Ma6b31f3b021f8d66cee70d36
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[Dworkin Muller]

On Fri, 8 Aug 2025 15:29:54 +0200, <tlaronde@kergis.com> wrote:
tlaronde> I will reply hastily on top, so please forgive me!
tlaronde> 
tlaronde> 1) I'm fond of knowing history and historical practices. So thanks for
tlaronde> the TOPS-20 presentation, that I didn't know about!

For a lot more detail of what it provides and how to use it from a
programmer's POV, see

    https://bitsavers.org/pdf/dec/pdp10/TOPS20/V7/JSYS_REFERENCE.MEM.txt

If nothing else, I think it'll help in organizing your thoughts on
ways to organize the relevant data structures for what you're
proposing.  Adapting CCMD (which is pretty similarly structured) might
be a reasonable place to start as well.

Note that the main issue I have, as far as doing a static
description as you're describing, is that it doesn't allow for
dynamically adjusting available options/values/etc at runtime.  It can
adapt for different directory contents or whatever easily enough, but
applying logic to determine what options to allow/disallow, or legal
numeric values depending on previous settings, etc, gets very
difficult.

Of course, this can be resolved by simply saying that such flexibility
isn't supported.  I'm just used to expecting it because COMND%
provides it.  Yes, most of my programming these days is on TOPS-20.
The joys of being retired ;-)

Dworkin

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-M58b4a01dac821b53f3a969b4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

philosophy of complexity, was Re: [9fans] parm server: user interaction

[Dworkin Muller]

On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com> wrote:
tlaronde> "panels" of a main window). [Am I not re-inventing Acme?]

Which brings to mind something that's been niggling at me for a while.
There seems to be a bit of a bias against all-singing, all-dancing
editors (cf emacs(1) and the lack of any variant of emacs in the
various Plan 9 distributions).  On the other hand, acme's an editor,
and it's used to read mail.  In other words, from the user's
perspective, the exact same functionality is present in acme as in
emacs - I can write macros, I can read mail, and I can edit files.  I
can even run a process under either of them interactively or simply
for the output, with the results in an editing buffer.  I can visit a
directory in either, etc (these are, in fact, exactly what I use emacs
for in my usual environments).

So, the ability to do lots of things via the editor per se does not
appear to be the problem.  Even having a fair amount of built-in
capability seems acceptable.  Rather, the objection appears to be that
emacs does everything itself, instead of providing some degree of
internal abilities plus an interface to let other programs use it
simply as a user-interaction medium (essentially, the textual
equivalent of rio).  Have I got that right?  We'll ignore GNU emacs'
client/server feature for the moment, of course.

I'm just trying to figure out where the boundaries are for what's
considered reasonable for base Plan 9 programs, as opposed to things
that compose new abilities on top of that base.

Thanks.

Dworkin

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M03fa740bb1723198f2335e47
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] parm server: user interaction

[Bakul Shah via 9fans]

[-- Attachment #1: Type: text/plain, Size: 14519 bytes --]

Something like this?

https://github.com/latex-lsp/texlab
latex-lsp/texlab: An implementation of the Language Server Protocol for LaTeX
github.com


> On Aug 8, 2025, at 11:44 AM, Steve Simon <steve@quintile.net> wrote:
> 
> plas on plan9 would be a game changer imho (to use plan9 in, dare i say, modern development environment).
> 
> plsciuld be implemented vi vmx 
> 
>> On 8 Aug 2025, at 6:45 pm, ron minnich <rminnich@gmail.com> wrote:
>> 
>> 
>> Keeping this short: Is there a place in this for a pls server for latex? There are pls commands that work in acme.
>> 
>> On Fri, Aug 8, 2025 at 8:28 AM <tlaronde@kergis.com <mailto:tlaronde@kergis.com>> wrote:
>>> On Thu, Aug 07, 2025 at 08:50:47PM +0200, hiro wrote:
>>> > This seems quite interesting to me but i didn't understand most of it,
>>> > i'll just concentrate on your first proposal in 1).
>>> > 
>>> > I think there are some obvious reasons why Plan9 people never missed
>>> > TAB completion as in BASH, ZSH, and other bloated linux programs.
>>> > 1) we have less arguments, thus most can remember them.
>>> > 2) we ask people to use file-globbing
>>> > 3) we ask people to keep names short, and easy to type and not only meaningful.
>>> > 4) there are many known ways to limit scope so that names can stay
>>> > short and still meaningful.
>>> 
>>> That the core utilities be as "elementary" as possible, limiting the
>>> number of options and using short meaning names, is obviously good.
>>> 
>>> But a system is not only used as-is, but with additional utilities
>>> whose complexity grows when being more and more "high" (i.e.: derived)
>>> user level.
>>> 
>>> So such a feature has not to be evaluated only for core utilities, but
>>> for other higher user space programs.
>>> 
>>> This common scheme could impose consistency on arguments values, and
>>> consistency of user interface (whether 1D: line interface, or 2D
>>> interface: GUI---curses, contrary to common belief, is 2D so is a
>>> limited GUI).
>>> 
>>> > 5) there's a file completion hack in rio (ctrl-f), though it's not
>>> > really used by many bec. it never works: it runs in the parent rio
>>> > namespace that doesnt see child mounts.
>>> 
>>> During IWP9 was presented Lola by Angelo Papenhoff. I do think that
>>> it is right to work on the GUI and that we can do something Plan9'ish
>>> that is simple, consistent, and have not much to do with other
>>> windowing systems---I think getting things altogether from 8 1/2, rio
>>> and Lola. I wouldn't like to have X11! on Plan9 and neither curses!
>>> (God forbid!) that is a suboptimal compromise between the console and
>>> the graphical 2D interface.
>>> 
>>> To try to sketch the "big" idea (but I'm working on pieces for now, to
>>> gather knowledge to refine the "big" idea---may be dropping it, or
>>> dropping some of it):
>>> 
>>> 1) For every program are defined stdin, stdout and stderr. On a
>>> "console" (not a 2D interface), echoing stdin, displaying stdout or
>>> stderr is done at the very same place. With a 2D interface, stdin
>>> should be taken from a window on top, stdout displayed on main middle
>>> window, and stderr displayed on the bottom window (one can call them
>>> "panels" of a main window). [Am I not re-inventing Acme?]
>>> 
>>> 2) Every program (the same can be done for rc(1) scripts) defines the
>>> syntax and even semantics of its arguments. So dialoguing to get the
>>> right arguments is made from within the command (and this should be
>>> recursive, if one of the arguments is a command, then getting the
>>> right arguments to this subcommand would be made by the same
>>> mechanism). But there are three distinct things:
>>> 
>>>         a) Editing the line (lexical stage): just to put, retrieve,
>>>         modify, correct the line to input. Since I would want to be
>>>         able to use the regex, selecting a previous line etc. in fact
>>>         I'm simply re-inventing ed(1)... So it would be ed'iting;
>>> 
>>>         b) Checking the grammar (syntactical stage): from inside the
>>>         command, using the Parm array a whatever parm Server dialogs
>>>         with the user (dumb parm Server: checks and exits with success
>>>         or error; or 1D dialog; or 2D graphical display to fill the
>>>         options);
>>> 
>>>         c) Doing the stuff (semantical stage): the arguments are valid
>>>         from b), the utility does its job.
>>> 
>>> 3) There is no reason to have several versions of the same program: an
>>> utility can be used via lines (command lines) or via graphical
>>> interface, and its result (stdout) can be as is or "rendered". With a
>>> graphical interface, all the "menus" to select commands or getting
>>> arguments are generated automatically from the Parm array description
>>> (sub-commands being whether "drop-down" or "pop-up"; the graphical
>>> interface should allow to call itself in a subwindow) the resulting
>>> being sent to one (at a time; could be several displaying windows,
>>> with selection of the current one to send the result to be displayed),
>>> the result window being whether "raw" (it just displays a succession
>>> of bytes), "text" (it just displays chars according to utf8 in a
>>> selected font) or  "graphical" (it draws primitives). A "rendered"
>>> text is a special case of using "graphical".
>>> 
>>> When it comes to rendering, as I have sketched during IWP9, one has to
>>> rasterize, and METAFONT is a rasterizer. So one of the things I'm
>>> thinking about is how to extend DVI to allow to embed DVI in DVI, to
>>> add the drawing primitives so that a glyph can be described (not
>>> rasterized) in DVI, to allow to simply append supplementary drawing
>>> instructions on some pages, or to add pages to an existing document
>>> without touching it (the case of signed PDF, where you append
>>> modifications without touching what has been signed, simply redefining
>>> the xrefs to reach also the previous ones, the reading starting at the
>>> end of the document to the first "/^%EOF/") etc. and extracting the
>>> rasterizing routines from METAFONT.
>>> 
>>> This will very probably and for good reasons seem fuzzy, but the first
>>> part (ed'iting and describing the syntax in main() to check or rework
>>> arguments before processing) is easy---less when it comes to
>>> implementing the help about arguments inside TeX proper.
>>> 
>>> This will be all for today :-)
>>> 
>>> > 
>>> > There are also non-obvious reasons.
>>> > One thing that I noticed very early on is that tab-complete seemed
>>> > like a good idea that never got implemented fully:
>>> > if some applications come with BNF style grammar in the documentation
>>> > for the arguments, why does tab completion not show these multiple
>>> > options? why does it only ever show a single option? i think because
>>> > typewriters suck.
>>> > in a graphical os like plan9 it might be much easier to graphically
>>> > document via a second rio window the possible extensions of current
>>> > text line without using horrible ncurses extensions..
>>> > 
>>> > example:
>>> > imagine you typed
>>> > ssh linux ip route a
>>> > 
>>> > program could check your last line in /dev/text against it's
>>> > cross-operating system BNF database and help you show the following
>>> > valid remaining options:
>>> > 
>>> > ssh linux ip route a{ add | append } ROUTE
>>> > ROUTE := NODE_SPEC [ INFO_SPEC ]
>>> > 
>>> > then you type on
>>> > ssh linux ip route add
>>> > and focus the other rio window again (alternative use a plumbing event
>>> > instead of focus) to get this next multi-line recommendation:
>>> > 
>>> > ssh linux ip route add ROUTE
>>> > ROUTE := NODE_SPEC [ INFO_SPEC ]
>>> > NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
>>> >             [ table TABLE_ID ] [ proto RTPROTO ]
>>> >             [ scope SCOPE ] [ metric METRIC ]
>>> >             [ ttl-propagate { enabled | disabled } ]
>>> > INFO_SPEC := { NH | nhid ID } OPTIONS FLAGS [ nexthop NH ]...
>>> > 
>>> > now you might realize you might want a better GUI where you can
>>> > include/exclude parts of this tree to find an easy completion-path.
>>> > seems a bit more involved but very possible since we have real GUIs.
>>> > Probably GUIs are too difficult for unix people, it's even harder in
>>> > TUI apps, and tab-completion = good enuff for them?
>>> > 
>>> > anyways, good man pages and low complexity are easier. we have no BNF
>>> > docs or complex multidimensional arguments like in iproute2 anyways ;)
>>> > 
>>> > On Thu, Aug 7, 2025 at 3:22?PM <tlaronde@kergis.com <mailto:tlaronde@kergis.com>> wrote:
>>> > > 
>>> > > As I have tried to explain concerning TeX during IWP9, TeX is only C89
>>> > > and I want it to behave exactly the same whatever the hosting OS is.
>>> > > Because if joe user uses TeX, if it behaves exactly the same on
>>> > > whatever OS, there is no impossibility to swap the OS underneath.
>>> > > 
>>> > > While thinking about the way an interactive session with TeX works,
>>> > > I'm currently thinking about the line editing feature---not a big
>>> > > problem, because TeX calls a C89 routine to get the next line, and the
>>> > > editing is the "spoon" before entering the "mouth" i.e. it is outside
>>> > > TeX altogether.
>>> > > 
>>> > > But I was thinking about also of a way to behave more helpfully about
>>> > > macros: since the macros are digested, TeX knows what is their syntax,
>>> > > what is the type of arguments and so on, so could display an help
>>> > > about the usage (this has to be done in TeX proper) and there could be
>>> > > a better editing of incorrect arguments in an interactive session.
>>> > > 
>>> > > But this is TeX internals. The question about the usage and the
>>> > > interactive editing of arguments (and the correction of partially
>>> > > incorrect arguments) could be done also more generally with any
>>> > > utility, including, depending on the terminal, using different
>>> > > arguments handling.
>>> > > 
>>> > > There is prior partial art: limited getopt(3) on Unix; a more general
>>> > > handling routine in C.E.R.L. GRASS that takes the argc and argv[],
>>> > > verifying type of argument, range, setting default values and engaging,
>>> > > if interactive, a dialog with the user whether to get the mandatory
>>> > > arguments if not provided or to correct the incorrect ones.
>>> > > 
>>> > > In pseudo C, a utility (an equivalent can be made for a rc script)
>>> > > would set an array of this:
>>> > > 
>>> > > typedef struct {
>>> > >         int cat;
>>> > > #define PARM_CAT_EOP    0       /* final sentry of array */
>>> > > #define PARM_CAT_FLAG   0x01    /* "-h" like */
>>> > > #define PARM_CAT_OPTION 0x02    /* "skip=val" like */
>>> > > #define PARM_CAT_ARG    0x04    /* positional arg */
>>> > > 
>>> > > char *name;     /* positional is "[1-9][0-9]*" or "*" for "wherever" */
>>> > >                 /* positional is not counting flags and options */
>>> > > int flags;
>>> > > #define PARM_FLAG_MANDATORY     0x01
>>> > > #define PARM_FLAG_MULTIPLE      0x02    /* a list of values of type */
>>> > > 
>>> > > int type;
>>> > > #define PARM_TYPE_STRING        0
>>> > > #define PARM_TYPE_INT           1
>>> > > #define PARM_TYPE_FLOAT         2
>>> > > #define PARM_TYPE_PATH          3
>>> > > 
>>> > > char *range;    /* acceptable range of values for numbers */
>>> > >                 /* a regex for strings and paths */
>>> > > /* for following require and forbid, index of PARM_CAT_EOP is
>>> > >   end of array
>>> > >  */
>>> > > int *require;   /* an array of indices of parms required with */
>>> > > int *forbid;    /* an array of indices of conflicting parms */
>>> > > char *default;
>>> > > char *description;
>>> > > /* these are filled in return */
>>> > > int nval;       /* count of values */
>>> > > char **val;
>>> > > } Parm;
>>> > > 
>>> > > Depending on what server is attached for serving arguments, if none,
>>> > > the syntax is verified as well as the ranges, the defaults being
>>> > > set, and it exits on error sending usage on stderr without modifying
>>> > > the arguments served.
>>> > > 
>>> > > A line oriented server could engage a dialog with the user to correct
>>> > > arguments or to ask for missing arguments.
>>> > > 
>>> > > A 2D oriented server could do this by displaying a graphical interface
>>> > > to get the arguments if not provided or incorrectly provided.
>>> > > 
>>> > > The three principal ideas being:
>>> > > 
>>> > > 1) that a utility has the information about what arguments it
>>> > > expects so say that an extension of the Unix like "tab-completion" after
>>> > > a utility name would display the usage, because it is served from
>>> > > inside the utility;
>>> > > 
>>> > > 2) that such a description can provide immediately an usage without
>>> > > having to write the code, and that the handling of ranges, types and so
>>> > > on have not to be repeated in every utility;
>>> > > 
>>> > > 3) that a graphical interface is just another way of getting arguments,
>>> > > and there should be no necessity to program a special version of a
>>> > > utility to change the way the arguments are provided.
>>> > > 
>>> > > Is such an idea totally orthogonal to Plan9?
>>> > > --
>>> > > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>>> > >              http://www.kergis.com/
>>> > >             http://kertex.kergis.com/
>>> > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>>> 
>>> --
>>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>>>              http://www.kergis.com/
>>>             http://kertex.kergis.com/
>>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-Mf3d1622de9c75c283b8ad32a>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc934d74ee389ad6a-Mf5d09f344111957ebf632820
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2.1: Type: text/html, Size: 21303 bytes --]

[-- Attachment #2.2: texlab.png --]
[-- Type: image/png, Size: 20129 bytes --]

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[tlaronde]

On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
> On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com> wrote:
> tlaronde> "panels" of a main window). [Am I not re-inventing Acme?]
> 
> Which brings to mind something that's been niggling at me for a while.
> There seems to be a bit of a bias against all-singing, all-dancing
> editors (cf emacs(1) and the lack of any variant of emacs in the
> various Plan 9 distributions).  On the other hand, acme's an editor,
> and it's used to read mail.  In other words, from the user's
> perspective, the exact same functionality is present in acme as in
> emacs - I can write macros, I can read mail, and I can edit files.  I
> can even run a process under either of them interactively or simply
> for the output, with the results in an editing buffer.  I can visit a
> directory in either, etc (these are, in fact, exactly what I use emacs
> for in my usual environments).
> 
> So, the ability to do lots of things via the editor per se does not
> appear to be the problem.  Even having a fair amount of built-in
> capability seems acceptable.  Rather, the objection appears to be that
> emacs does everything itself, instead of providing some degree of
> internal abilities plus an interface to let other programs use it
> simply as a user-interaction medium (essentially, the textual
> equivalent of rio).  Have I got that right?  We'll ignore GNU emacs'
> client/server feature for the moment, of course.
> 
> I'm just trying to figure out where the boundaries are for what's
> considered reasonable for base Plan 9 programs, as opposed to things
> that compose new abilities on top of that base.
> 

Concerning the "frame of mind", I'm exactly in the same one: when it
comes to software and a system, I want a mathematical partition: code
that does not overlap and that covers the whole need but keeping it a
whole i.e. a unit because the pieces can be combined to work together.

Indeed, when there is an interface that is not line limited, why try
to put pieces of editing capabilities in the window from which one
tries to send commands, and not an editor running in a panel dedicated
for commands (this gives the immediate possibility too to have the
equivalent of the Unix script(1): simply save your editing session),
with the output sent in another read-only panel, while "comments"
(stderr) appear in another one?

This way of organizing the interface being, contrary to emacs, simply
a way of letting external utilities use some panel and being able to
combine their results.

Emacs makes sense as the way to have full editing capabilities to also
edit commands. But I think also that it duplicates too much, and that
such an interface could be just a graphical 2D way of combining other
utilities and organizing their output.

I do think that this is totally in the Plan9 spirit and that when it comes
to the GUI, things can be reworked and in fact simplified.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M016e350dd527c8da4693f685
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 5014 bytes --]

Just a reminder, if you get too stuck in an emacs frame of mind, you're
really going to miss the full power of acme specifically, and plan 9 in
general.

Back in my LANL days, I had a need to edit around 30 assembly files all at
once, to change a common thing. It was not going to be fun with sed.

So I:
acme *.s
and in the top bar, do something like this:
Edit X/*.s/,s/blah bla/blue lue/g # memory is almost certainly wrong here.

But it let me do a sequence of commands, across all those assembly files,
and see the results on them instantly, as well as undo anything wrong.

If I needed, part of that could include piping all the files through a
command line and replacing what was there.

And it was fast. And it was visual. I could see it all happen with no
apparent delay.

It's not that acme does less. It does things on an orthogonal axis to
emacs. In emacs, to get more capabilities, people tend to resort to lisp.
In acme, to get more capabilities, people resort to building tool pipelines
that *they can also use outside acme*. To me, that's very important. Emacs
solutions typically only work in emacs (true for vim and zed and on and on
...) whereas acme can be a way to prototype things that can be used outside
acme.

That's kind of plan 9 (to me) in a nutshell: not special purpose solutions
for single tools, but solutions that work across a wide range of tools.

On Sat, Aug 9, 2025 at 12:53 AM <tlaronde@kergis.com> wrote:

> On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
> > On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com> wrote:
> > tlaronde> "panels" of a main window). [Am I not re-inventing Acme?]
> >
> > Which brings to mind something that's been niggling at me for a while.
> > There seems to be a bit of a bias against all-singing, all-dancing
> > editors (cf emacs(1) and the lack of any variant of emacs in the
> > various Plan 9 distributions).  On the other hand, acme's an editor,
> > and it's used to read mail.  In other words, from the user's
> > perspective, the exact same functionality is present in acme as in
> > emacs - I can write macros, I can read mail, and I can edit files.  I
> > can even run a process under either of them interactively or simply
> > for the output, with the results in an editing buffer.  I can visit a
> > directory in either, etc (these are, in fact, exactly what I use emacs
> > for in my usual environments).
> >
> > So, the ability to do lots of things via the editor per se does not
> > appear to be the problem.  Even having a fair amount of built-in
> > capability seems acceptable.  Rather, the objection appears to be that
> > emacs does everything itself, instead of providing some degree of
> > internal abilities plus an interface to let other programs use it
> > simply as a user-interaction medium (essentially, the textual
> > equivalent of rio).  Have I got that right?  We'll ignore GNU emacs'
> > client/server feature for the moment, of course.
> >
> > I'm just trying to figure out where the boundaries are for what's
> > considered reasonable for base Plan 9 programs, as opposed to things
> > that compose new abilities on top of that base.
> >
> 
> Concerning the "frame of mind", I'm exactly in the same one: when it
> comes to software and a system, I want a mathematical partition: code
> that does not overlap and that covers the whole need but keeping it a
> whole i.e. a unit because the pieces can be combined to work together.
> 
> Indeed, when there is an interface that is not line limited, why try
> to put pieces of editing capabilities in the window from which one
> tries to send commands, and not an editor running in a panel dedicated
> for commands (this gives the immediate possibility too to have the
> equivalent of the Unix script(1): simply save your editing session),
> with the output sent in another read-only panel, while "comments"
> (stderr) appear in another one?
> 
> This way of organizing the interface being, contrary to emacs, simply
> a way of letting external utilities use some panel and being able to
> combine their results.
> 
> Emacs makes sense as the way to have full editing capabilities to also
> edit commands. But I think also that it duplicates too much, and that
> such an interface could be just a graphical 2D way of combining other
> utilities and organizing their output.
> 
> I do think that this is totally in the Plan9 spirit and that when it comes
> to the GUI, things can be reworked and in fact simplified.
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-Mcda51d76b8c34828dc32856b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7312 bytes --]

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[Dworkin Muller]

On Sat, 9 Aug 2025 15:08:21 -0700, ron minnich <rminnich@gmail.com> wrote:
rminnich> Just a reminder, if you get too stuck in an emacs frame of mind, you're
rminnich> really going to miss the full power of acme specifically, and plan 9 in
rminnich> general.

For the record, I'm not advocating one or the other, just trying to
work out where the dividing line is for `do it in a bunch of other
processes' versus `do it in a single process'.  I have a fair idea of
where that line is for TOPS-20, RT-11, early Unix, and current
Unices.  My belief is that for Plan 9, it's about the same as for
early Unix - processes are cheap, so it's better to throw lots of
existing ones at a problem than to try to do more in a single one.

In the early Unix case, this was at least partly driven by hardware
considerations.  You didn't have a lot of memory, so no single process
really *could* do a lot.  So make it cheap to create them, and then to
chain them (as opposed to using temporary files).  Plan 9 appears to
have the same basic philosophy, even if the original hardware
constraints no longer apply.

rminnich> It's not that acme does less. It does things on an orthogonal axis to
rminnich> emacs. In emacs, to get more capabilities, people tend to resort to lisp.
rminnich> In acme, to get more capabilities, people resort to building tool pipelines
rminnich> that *they can also use outside acme*. To me, that's very important. Emacs
rminnich> solutions typically only work in emacs (true for vim and zed and on and on
rminnich> ...) whereas acme can be a way to prototype things that can be used outside
rminnich> acme.
rminnich>
rminnich> That's kind of plan 9 (to me) in a nutshell: not special purpose solutions
rminnich> for single tools, but solutions that work across a wide range of tools.

That's kind of separate from my original question (using it as a
display engine), but equally relevant.

Thanks for the perspective.

Dworkin

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-Mb2a2bcc6c51f3681891f0104
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[sirjofri via 9fans]

10.08.2025 00:20:45 ron minnich <rminnich@gmail.com>:
> It's not that acme does less. It does things on an orthogonal axis to emacs. In emacs, to get more capabilities, people tend to resort to lisp. In acme, to get more capabilities, people resort to building tool pipelines that *they can also use outside acme*. To me, that's very important. Emacs solutions typically only work in emacs (true for vim and zed and on and on ...) whereas acme can be a way to prototype things that can be used outside acme. 
>
> That's kind of plan 9 (to me) in a nutshell: not special purpose solutions for single tools, but solutions that work across a wide range of tools. 

I can give you another acme example. Some time ago I ported part of the writer's workbench (wwb) to plan 9, just because I was curious. Because I'm mainly using acme, I wrote some very small helper scripts that can call the wwb tools from within acme, and transform the output to something that suits plan 9 world (plumbable text).

The thing is, wwb knows nothing about plan 9, or acme. It was built for Unix and has probably never seen a plan 9 system before. Making it work in acme is just a standard rc script (and rc doesn't care about acme), and is only a matter of calling the program and piping it's output through sed for some processing.

Looking at the code of wwb, I assume it was written in a time where everything on Unix was written with ed. I guess they'd print out the issues wwb found, then run ed to fix them. They probably had no other editor, or at least no visual one.

Btw, I occasionally use those tools when writing. Since I'm not a native English speaker, they sometimes help a lot. There are more modern tools out there, but they probably won't work on plan 9.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M917c97458209424cf48036ea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[tlaronde]

On Sat, Aug 09, 2025 at 03:08:21PM -0700, ron minnich wrote:
> Just a reminder, if you get too stuck in an emacs frame of mind, you're
> really going to miss the full power of acme specifically, and plan 9 in
> general.
> 
>[...] 
> It's not that acme does less. It does things on an orthogonal axis to
> emacs. In emacs, to get more capabilities, people tend to resort to lisp.
> In acme, to get more capabilities, people resort to building tool pipelines
> that *they can also use outside acme*. To me, that's very important. Emacs
> solutions typically only work in emacs (true for vim and zed and on and on
> ...) whereas acme can be a way to prototype things that can be used outside
> acme.
> 
> That's kind of plan 9 (to me) in a nutshell: not special purpose solutions
> for single tools, but solutions that work across a wide range of tools.

This is exactly my inclination (mathematical "partition") [Note: I'm
not an emacs user.]

But I made an interesting exercise this week-end. I was on the train,
again, and brought with me Vita Nuova printed volume of "Plan9 3rd
Edition, Programmer's Manual [Documents]" to re-read "Plan 9 from Bell
Labs" by Rob Pike and al.

And I asked myself: if I was to "edit" or "update" the document,
considering Nix primilarily but not only:

        a) Would Nix mandates so huge modifications that it would be
regarding Plan9 as a big departure that Plan9 is regarding Unix?

        b) Would a policy of allocation of resources, taking into
account building a special environment and tying some programs to some
kernel-cores fit in the plan 9 namespace scheme?

        c) Is there specific points that I would date to judge having
not hit on the nail?

The answer for a) is No: Nix fits quite well in the whole scheme, it
is a mandatory refinement, it imposes only to add something to the
scheme, not to modify things---The key point being that a "system" has
to be regarded as whatever processors tightly tied and sharing memory
with a MMU, and that inside such a system one will have to refine more
the species, because, for example, "riscv" doesn't mean a lot by
itself: the ISA is modular so not every riscv processor can interprete
every instruction.

The answer for b) is Yes: the way Plan9 builds namespace can be
extended, in this case once more by adding possibilities, not by
modifying the scheme. The questions that arise (expressed in another
thread) concerning setuid and setting an environment have all to do
with "what has to be definitively attached to a file?": the rwx
permissions? Is is a way of modifying the namespace, so it is not
"definitively attached". The user having authority (to modify it and
to propose it)? This one yes. The true nature of the file? This one
yes, it should: in plan9 this nature is given by the file hierarchy
(compatible binary under amd64/; scripts under rc/ etc.); should it be
explicitely set on the file level? Are the binaries so encoded that
the ISA (including for riscv the optional) can be retrieved from some
defined place in the file?
        => ACS and variants are, for me, a nightmare. And they are
generally attached to file systems. Tying some programs to some cores
in the namespace seems more simple, because "The file system model is
well-understood, both by system builders and general users, so
services that present file-like interfaces are easy to build, easy to
understand, and easy to use." I would not change one word to this...

The answer for c) is Yes: the part that I would alter the most are
"The Command-Level View". The so-called GUI and the "windows" are
red-herrings. The difference is that you have whether a 1D interface
(you can interact and see only a line) or a 2D interface (you can see
simultaneously several different rows).

With 1D, you have no choice: you are echoing what you enters at the
very same place where what the program generates is displayed
intermixed with what the program spits about errors.

If you have the opportunity to display simultaneously different rows,
you will echo your input in one place, the output in another one, and
the errors still elsewhere.

The "window" is not key: it is an implementation detail (a subset of
rows). The important thing is 2D versus 1D.

Once this is understood, you realize that even with 1D, you could use
ed(1) to write and edit your commands before sending them (w!rc), giving
you edition, history and scripting! Trying, at least, to use the one
line of display you have at disposal to at least separate in a timely
manner when it is used for stdin, when it is used for stdout, and when
it is used for stderr (I personnally think there should be a stdstat
to send messages about progression of processing or help messages,
that are not errors).

To come back to the beginning: I do suggest to you guys to take "Plan
9 from Bell Labs" and to "edit" it, to think about what to change,
what to add, what to remove. The main structure holds; this doesn't
mean that everything has to stay the same. It can be even more Plan9ish ;-)
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M4a6f727e8245add071eca1d7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[Steve Simon]

i wrote suggest(1) a spelling suggestion tool.
spell is good for finding mistakes but i am dyslectic which means i can see the spelling is wrong but i cannot work out how to correct it.

this works on the command line or could be wrapped to work in acme.

-Steve
  

> On 10 Aug 2025, at 2:11 pm, sirjofri via 9fans <9fans@9fans.net> wrote:
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tef913feab2540fb4-M7e62e60bb93d04a621037231
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[sirjofri via 9fans]

10.08.2025 18:25:04 Steve Simon <steve@quintile.net>:

> i wrote suggest(1) a spelling suggestion tool.
> spell is good for finding mistakes but i am dyslectic which means i can see the spelling is wrong but i cannot work out how to correct it.
>
> this works on the command line or could be wrapped to work in acme.

Nice!

In general, I like to refer to editors like acme as an IDE, but not an "integrated development environment". I refer to it as an "integrating development environment" instead, as it doesn't provide a fully integrated solution to certain problems, but is constructed in a way that makes it easy to integrate other tools of the environment (like the active version of "integrate") and be integrated (passive) into an existing environment.

Like, instead of using the IDE to never touch any other tool, it provides enough surface for the developer to actually use the other tools directly in an integrated way.

What would still be nice is a better integration between acid and acme. Like, setting breakpoints on the editor line, printing the value of the selected variable and stuff like that. I want to work on it, but I have a few other projects before that.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tef913feab2540fb4-Mc4a3cb6fde02e52a8b2e636e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[Willow Liquorice]

Chiming in to say Ron hits the nail on the head here: Plan 9 can take a 
very pure approach to the Unix design philosophy, of composable, 
reusable, programs that do one thing well, because it gets a lot of 
fundamentals right (looking at namespaces).

Emacs has its own lisp because its original host OSes got those 
fundamentals wrong. Processes have much less control over their own 
environments on other Unix-likes. It's much harder to throw up a file 
server and have it Just Work™.

On Plan 9, emacs could expose its editor state as a 9P server, and let 
other programs, written in *whatever*, do the heavy lifting. The program 
and the overall system both shrink, reducing complexity and the 
cognitive burden of the system as a whole.

And hey, that's exactly what Acme does.

/begin tangential rant, on getting fundamentals wrong

I'm of the belief that the widget-oriented GUIs most people use comprise 
a severe misfeature. They encourage immutable and compiled-in 
functionality which, in turn, beget bespoke scripting and plugins to get 
around the resulting limitations. Code and system complexity then 
increase, weighing the mind down and fragmenting development ecosystems.

I reckon the volume of characters made available by Unicode is vast 
enough, and Plan 9's plumbing and namespacing are versatile enough, that 
complex graphical shells can be based purely upon text buffers. Users 
could then write their own interfaces, suited to their needs.

One piece of Plan 9 orthodoxy holds this back: centralisation of the 
plumber. There is no trivial way of determining the optimal ordering of 
context-specific rules in a single plumbing file, nor a way of 
communicating that context without introducing additional conventions 
that *all* programs that plumb must obey.

A centralised plumber is, as a result, a fragile plumber. Different 
contexts should have different plumbers.

/end tangential rant

     - Willow

On 09/08/2025 23:08, ron minnich wrote:
> Just a reminder, if you get too stuck in an emacs frame of mind, you're 
> really going to miss the full power of acme specifically, and plan 9 in 
> general.
> 
> Back in my LANL days, I had a need to edit around 30 assembly files all 
> at once, to change a common thing. It was not going to be fun with sed.
> 
> So I:
> acme *.s
> and in the top bar, do something like this:
> Edit X/*.s/,s/blah bla/blue lue/g # memory is almost certainly wrong here.
> 
> But it let me do a sequence of commands, across all those assembly 
> files, and see the results on them instantly, as well as undo anything 
> wrong.
> 
> If I needed, part of that could include piping all the files through a 
> command line and replacing what was there.
> 
> And it was fast. And it was visual. I could see it all happen with no 
> apparent delay.
> 
> It's not that acme does less. It does things on an orthogonal axis to 
> emacs. In emacs, to get more capabilities, people tend to resort to 
> lisp. In acme, to get more capabilities, people resort to building tool 
> pipelines that *they can also use outside acme*. To me, that's very 
> important. Emacs solutions typically only work in emacs (true for vim 
> and zed and on and on ...) whereas acme can be a way to prototype things 
> that can be used outside acme.
> 
> That's kind of plan 9 (to me) in a nutshell: not special purpose 
> solutions for single tools, but solutions that work across a wide range 
> of tools.
> 
> On Sat, Aug 9, 2025 at 12:53 AM <tlaronde@kergis.com 
> <mailto:tlaronde@kergis.com>> wrote:
> 
>     On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
>      > On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com
>     <mailto:tlaronde@kergis.com>> wrote:
>      > tlaronde> "panels" of a main window). [Am I not re-inventing Acme?]
>      >
>      > Which brings to mind something that's been niggling at me for a
>     while.
>      > There seems to be a bit of a bias against all-singing, all-dancing
>      > editors (cf emacs(1) and the lack of any variant of emacs in the
>      > various Plan 9 distributions).  On the other hand, acme's an editor,
>      > and it's used to read mail.  In other words, from the user's
>      > perspective, the exact same functionality is present in acme as in
>      > emacs - I can write macros, I can read mail, and I can edit files.  I
>      > can even run a process under either of them interactively or simply
>      > for the output, with the results in an editing buffer.  I can visit a
>      > directory in either, etc (these are, in fact, exactly what I use
>     emacs
>      > for in my usual environments).
>      >
>      > So, the ability to do lots of things via the editor per se does not
>      > appear to be the problem.  Even having a fair amount of built-in
>      > capability seems acceptable.  Rather, the objection appears to be
>     that
>      > emacs does everything itself, instead of providing some degree of
>      > internal abilities plus an interface to let other programs use it
>      > simply as a user-interaction medium (essentially, the textual
>      > equivalent of rio).  Have I got that right?  We'll ignore GNU emacs'
>      > client/server feature for the moment, of course.
>      >
>      > I'm just trying to figure out where the boundaries are for what's
>      > considered reasonable for base Plan 9 programs, as opposed to things
>      > that compose new abilities on top of that base.
>      >
> 
>     Concerning the "frame of mind", I'm exactly in the same one: when it
>     comes to software and a system, I want a mathematical partition: code
>     that does not overlap and that covers the whole need but keeping it a
>     whole i.e. a unit because the pieces can be combined to work together.
> 
>     Indeed, when there is an interface that is not line limited, why try
>     to put pieces of editing capabilities in the window from which one
>     tries to send commands, and not an editor running in a panel dedicated
>     for commands (this gives the immediate possibility too to have the
>     equivalent of the Unix script(1): simply save your editing session),
>     with the output sent in another read-only panel, while "comments"
>     (stderr) appear in another one?
> 
>     This way of organizing the interface being, contrary to emacs, simply
>     a way of letting external utilities use some panel and being able to
>     combine their results.
> 
>     Emacs makes sense as the way to have full editing capabilities to also
>     edit commands. But I think also that it duplicates too much, and that
>     such an interface could be just a graphical 2D way of combining other
>     utilities and organizing their output.
> 
>     I do think that this is totally in the Plan9 spirit and that when it
>     comes
>     to the GUI, things can be reworked and in fact simplified.
>     -- 
>              Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>     http://www.kergis.com/ <http://www.kergis.com/>
>     http://kertex.kergis.com/ <http://kertex.kergis.com/>
>     Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 
>     ------------------------------------------
>     9fans: 9fans
>     Permalink: https://9fans.topicbox.com/groups/9fans/
>     T9209adeaba1b3a8a-M016e350dd527c8da4693f685
>     <https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-
>     Delivery options: https://9fans.topicbox.com/groups/9fans/
>     subscription <https://9fans.topicbox.com/groups/9fans/subscription>
> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions 
> <https://9fans.topicbox.com/groups/9fans> + participants 
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options 
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink 
> <https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a- 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-Mff7b8ff811c591ee129b6f06
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription