plas on plan9 would be a game changer imho (to use plan9 in, dare i say, modern development environment).
plsciuld be implemented vi vmx Keeping this short: Is there a place in this for a pls server for latex? There are pls commands that work in acme. 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 <[email protected]> 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
|
