Autocompletion in REPL

[galex-713]

The REPL is editable (you can use arrow keys and backspace) and I saw somewhere “readline” as a dependency: afaik readline has autocompletion facilities, if curv use it, it could use them so that to offer autocompletion depending on current scope and namespace, as do most (lisp) REPL I knew until then. May be a first step to an eventual project of adding autocompletion to editor modes as I suggested and then to a future three-pane IDE as suggested in https://github.com/doug-moen/curv/blob/master/docs/Future_Work.rst#gui

[doug-moen]

Yes, the Curv program uses GNU Readline, which has an autocompletion API. There is already autocompletion for filenames, which can occur in a context like:

include file "lib/experimental.curv";

I think it would not be difficult to support autocompletion for identifiers that were already defined before you started typing the current command line. There is a dictionary of already-defined identifiers available the variable curv::Namespace names. This project requires C++ knowledge, but is self contained and not too complicated.

Autocompletion that can see local variable definitions in let clauses within the command that you are currently typing -- well, that is more complicated, as it requires parsing the command line.

[galex-713]

I never saw any repl completing based on its current line being read, only predefined stuff (same for in-buffer evaluation inside emacs: not completing anything not evaluated yet, especially that it could be syntaxically or semantically wrong). So it wouldn’t be an expected change. Though it would be an interesting experiment, but I guess it would be preferable to first try on a simpler-syntax language like with lisp sexps.

[Lenbok]

Also related to #24 and the IDE concept, perhaps implement support for Language Server Protocol so that any existing editors/IDEs that are LSP clients can magically get the autocompletion? (Perhaps this should be a separate Issue, or just a TODO entry?).

[doug-moen]

If anybody wants to work on an IDE for Curv, that would be great. A Language Server Protocol implementation is something that might happen in this context, depending on your goals for the IDE.

The biggest improvement that I want right now is the ability to tweak numeric parameters using graphical sliders. This should produce immediate animated feedback in the graphics window, and the source code also needs to be updated as the sliders are moved. But, there is nothing in Language Server Protocol that supports this, AFAIK. Check out https://thebookofshaders.com/ for an example of what this looks like.

[galex-713]

The biggest improvement that I want right now is the ability to tweak numeric parameters using graphical sliders. This should produce immediate animated feedback in the graphics window, and the source code also needs to be updated as the sliders are moved.

You mean just as libfive’s Studio is already doing?

[mkeeter]

Studio lets you define free variables then manipulate them by dragging the model's surface. This is powerful but sometimes unpredictable, because it's running a solver to figure out how to put the model's surface at your new cursor position.

I suspect that Doug is looking for something closer to an immediate mode GUI that shows up in the rendering viewport and lets you set variables directly. Like he said, the tricky part is that you should update the source code to reflect the new values. I do this in Studio at parse time, but it's harder when the script is owned by a separate editor – does the LSP have a "reload-from-file" command?

A third path is something like this, but that's back into building-an-IDE territory.

[doug-moen]

Like @mkeeter said, I'm not talking about libfive Studio. I want to be able to point at any literal constant in a program, and have a slider pop up for tweaking the value. This mechanic is demonstrated in the Brett Victor video, but it is actually implemented by this project: https://github.com/patriciogonzalezvivo/glslEditor. By tweaking parameters, you can affect not just geometry, but also colour and animation.

I've thought about embedding Curv in a conventional IDE. But the features that will turn Curv into a reactive visual programming environment, like the glslEditor slider mechanic and other Brett Victor-inspired features, are not found in IDEs.

That kind of points to writing a GUI in C++, probably using Qt, just like OpenSCAD and libfive Studio.

[doug-moen]

Curv now uses replxx, instead of the GNU readline library, for reading command lines in the REPL.

Replxx has an API for implementing autocompletion. The Curv REPL has a symbol table containing globally defined identifiers that are suitable for autocompletion. At this point, it would not be difficult for a contributor with C++ skills to add autocompletion to the REPL.

(Replxx also supports syntax colouring and hints, and is portable to Windows, and has portable support for keyboard interrupt/Ctrl-C handling, all of which make it better than readline.)

[s-ol]

@doug-moen I will take a look into the curv source code and try to complete this in the next couple of days.

as for the IDE debate - as a vim user I really enjoy curv's current editor-independent live-reloading and general application paradigm. Building 'yet another IDE' sounds a bit "silly" to me - LSP sounds like a better choice for "standard level support". For scrubbing values etc. maybe the LSP protocol can be extended - after a quick look at the specification it seems the protocol would easily support something like that:

the rename/prepareRename mechanism seems similar for example; the client sends a prepareRename to find out whether a location in the text is rename-able, if so, it can preset renaming-UI, and when the user enters a name the rename request can go through. In this second phase the language server generates the project-wide change-sets and the editor only commits them.

Mapping this to scrubbing, there could be a prepareScrub request that yields information about the UI to be displayed (value type, value range etc.). When this request succeeds a corresponding UI is activated that sends previewScrub requests that allow the preview (doubling as the language server) to preview the value changes in real time and finally a finishScrub request to finalize and write back the changes. (previewScrub and finishScrub might also be the same).

This extension sounds general enough to propose to LSPs at large and simple enough to fork and maintain in one 'officially-curv-supported' IDEs LSP implementation even if the proposal doesn't become part of the specification.

[doug-moen]

The discussion of "value scrubbing" continues here: https://github.com/doug-moen/curv/issues/45