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