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 <[email protected]> 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 <[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-Meabd424a93dfaa4ea45255e0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
