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, [email protected] 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 <[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 > > -- > 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
