Sweep: SWI-Prolog Embedded in Emacs

[oskardrums]

@swi

To view the documentation you put the cursor on the predicate, right click on it and the popup menu has an entry called “Documentation”.

But really the most useful things I find are the automatic update of :- use_module(.., ..)/autoload entries, and the easing of cursor movement when writing docs for a predicate. You can see these in action by loading some piece of code you have (which uses imports), delete all the use_module entries (leave the cursor there) and choose from the menu: Prolog>Update dependencies. You will see it nicely populating all the imports. For writing predicate docs type %% at the beginning of a line.

I sometimes also use the Prolog>Make module menu.

What I would find really useful is to have a write-pldoc-header command that would automatically write:

%! closest_predicate_below_cursor(Arg1,Arg2,Arg3).
%
%  <cursor_left_here>

for the closest predicate below the cursor. I normally use vim or neovim with @jamesvnc lspserver to write the code, and I switch to the builtin editor to update the imports (use_module...) and to write the predicate documentation. Often when I am debugging I stay with the builtin editor and press C-X C-s C-X C-m to save and run make.

Thanks, a right-click menu with a Documentation option shouldn’t be too hard to provide in sweep, I’ll keep it in mind when working on providing documentation.

Regarding Update dependencies and other commands that would modify specific parts of the buffer (like exporting the current predicate), I’d like to include these in sweep as well, ideally in a way that’ll make it easy to implement more such commands that require finding and modifying a certain part of a Prolog file in sweep in the future.

As a first step, I’ve added integration with Emacs’ auto-insert command which can be used to fill in Prolog module templates in new and existing sweeprolog-mode buffers. This is intended to solve the use case of the built-in editor’s Make module command. See Using templates for creating new modules in the manual for more details.

[jamesnvc]

@oskardrums

maybe that wasn’t updated to sweeprolog-swipl-path?

No, I did update the path…further experimentation has also revealed that simpler queries do work via the sweeprolog interface, e.g. I can successfully run (sweeprolog-open-query "user" "system" "=" "hello") and get the expected solution.

[jamesnvc]

@jan

So, my suspicion is that when loading into Emacs you load an old version of libswipl.[so/dylib/dll].

That seems promising…when does libswipl get loaded though? I can see that sweep-module-path in sweeprolog--ensure-module is the correct path.

[oskardrums]

@jamesnvc

when does libswipl get loaded though? I can see that sweep-module-path in sweeprolog--ensure-module is the correct path.

libswipl is dynamically linked to sweep-module, so if you have an older libswipl laying around in the dynamic libraries search path maybe that gets loaded instead of the newly built version. I normally use cmake -DSWIPL_INSTALL_IN_LIB=ON ... when building swipl from source to make sure I get libswipl in the standard dynamic libraries search path.

[jan]

If we are talking Linux, start emacs with Prolog, get the PID, go to /proc/<pid> and do cat maps to find the memory maps. That should tell which shared objects are loaded into the process.

[jamesnvc]

I’m unfortunately running macOS right now, but it looks like vmmap gives similar information there; looking at that, I indeed see the wrong version is being linked in. I’ll try fiddling with that, but I think that is the answer to this mystery!

[jamesnvc]

Got it working by changing the @rpath of the shared library with install_name_tool! I think there are some CMake flags that could potentially make that unnecessary when installing with a particular prefix (I had built swipl with PREFIX=$HOME); I’ll have a look & hopefully submit a PR for that.

[nobrowser]

Hi, here’s someone with a different balance of Emacs vs. Prolog experience.

• First, the very specific point (which pushed me to do the unusual: stop lurking and post). Inserting templates should probably not be done with auto-insert ; this Emacs library is better suited for inserting constant text. OTOH, many languages use the skeleton library for “filling templates”.

• More generally though, I have the uneasy perception of what I privately call the “XY workstation syndrome” in Emacs. I mean the always well-meant and impressive projects which try to bend Emacs to make it the most featureful interface possible for a language, compiler or another tool XY, while neglecting the overall Emacs conventions that make Emacs so awesome. Prominent existing examples of this phenomenon are aucTeX and Proof General.

• Thus, I think trying to match Sweep’s interface too closely to the one built into SWI is a mistake. Instead, please try to provide the same features in an Emacs-idiomatic way, looking at other language interfaces already in Emacs; best those actually shipped with Emacs, and not in external packages. Best of all are those written largely by someone closely associated with Emacs development (such as Eli Zaretskii or Stefan Monnier).

Thanks - I hope you receive this in the friendly spirit in which I have written it.

–
Ian

[oskardrums]

Hi Ian,

@nobrowser

First, the very specific point (which pushed me to do the unusual: stop lurking and post). Inserting templates should probably not be done with auto-insert ; this Emacs library is better suited for inserting constant text. OTOH, many languages use the skeleton library for “filling templates”.

Actually auto-insert builds on top of skeleton, making it perfectly suitable for this purpose AFAICT, no?

@nobrowser

• More generally though, I have the uneasy perception of what I privately call the “XY workstation syndrome” in Emacs. I mean the always well-meant and impressive projects which try to bend Emacs to make it the most featureful interface possible for a language, compiler or another tool XY, while neglecting the overall Emacs conventions that make Emacs so awesome. Prominent existing examples of this phenomenon are aucTeX and Proof General.

I agree with the approach that you present, but I don’t think that is issue applies to this case. sweep intentionally integrates with many built-in Emacs facilities as mentioned throughout the manual. Is there any area in which you think we can improve on that?

@nobrowser

Thus, I think trying to match Sweep’s interface too closely to the one built into SWI is a mistake. Instead, please try to provide the same features in an Emacs-idiomatic way, looking at other language interfaces already in Emacs; best those actually shipped with Emacs, and not in external packages.

I believe I’ve mostly been doing just that, again I’d be happy to improve any part of the implementation with that regard if you have further specific concerns.

P.S.

@nobrowser

Thanks - I hope you receive this in the friendly spirit in which I have written it.

Of course, I appreciate it

[oskardrums]

@swi

What I would find really useful is to have a write-pldoc-header command that would automatically write:

%! closest_predicate_below_cursor(Arg1,Arg2,Arg3).
%
%  <cursor_left_here>

for the closest predicate below the cursor.

Implemented this nice feature suggestion in ADDED: new command sweeprolog-document-predicate-at-point · SWI-Prolog/packages-sweep@ef3fdc3 · GitHub. The new command is called sweeprolog-document-predicate-at-point and it can be invoked through the menu and with C-c C-d.

demo

I’ve also added a section about PlDoc comments to the sweep manual, which describes this new command and refers to the standard Emacs commands for working with doc comments.

[swi]

@oskardrums

Implemented this nice feature suggestion in ADDED: new command sweeprolog-document-predicate-at-point · SWI-Prolog/packages-sweep@ef3fdc3 · GitHub.

That is great! Thanks for adding this feature so promptly!

[nobrowser]

Yes, thanks

Btw @oskardrums , is your nickname a reference to “The Tin Drum”? I really enjoyed reading it.

–
Ian

[oskardrums]

@nobrowser

Btw @oskardrums , is your nickname a reference to “The Tin Drum”? I really enjoyed reading it.

Indeed it is