I’m using SWI-Prolog. I use the graphical debugger for debugging and tracing and I really like it. But I miss having a typical IDE for code editing. Currently I use Notepad++. The one feature I’m really looking for is an editor that would provide a drop-down box or navigator for all the predicates in my code when I am working on a particular source file. Currently I have to do a text search to find them.
Has anybody seen a Prolog specific editor for SWI-Prolog that provides that feature? Even better would be able to have nameable bookmarks like the JetBrain’s WebStorm IDE for Javascript/Node.JS work.
I tend to edit from within SWIPL shell. You can use edit(predicate). to open the location of the chosen predicate within your editor. It looks like notepad++ allows you to specify the linenumber to begin at by passing the -n flag to the editor. So you could add a line to your .swiplrc similar to the untested:
And if you do not “live” in a particular editor, try not specifying one and use the default built-in Emacs clone. It surely has disadvantages, but also quite a few goodies such as a lot of analysis on the fly on your code and context menus on predicate and calls to jump there, get info, etc.
You can even make it do what you want by extending a mode using Prolog code
Jan, I personally like the built-in editor. But isn’t the XPCE-subsystem being faded away and the editor is based on XPCE? Or just the help system was detached from XPCE? I am thinking of learning a new editor, just because I am in thinking that XPCE is being faded away?
Well if XPCE and editor will be around, I would like see an simple example of extending the XPCE-editor.
For looking at large fact files (thousands to millions of lines) I use Notepad++ (64-bit)
For looking at larger fact files (Gigabytes) I use grep on Ubuntu which is runs side by side on Windows 10 via WSL. With this I can Copy-N-Paste from one OS to the other and can access Window files and Windows USB drives on Windows as normal and on Ubuntu when they are mounted.
It is not very likely that XPCE will be removed anytime soon (if ever). I do not really recommend it for new projects, especially if you want to send the message you are doing something modern If at some point there is an alternative editor that gets the highlighting integrated as smoothly as XPCE, it might get time to drop XPCE.
For programming examples, simply look at xpce/prolog/lib/emacs, in particular the *_mode.pl files. You can create a directory ~/lib/xpce/emacs and put files <mode>_mode.pl there. These are loaded after the mode is loaded. I pushed my own (rather random) selection to https://github.com/JanWielemaker/pce_emacs_extensions
If you have extensions, in particular implement stuff that appears in e.g., GNU emacs or improve the usability on notably Windows or the Mac, please share.
In this day of modern multi-language actively developed text editors, I think the best use of resources is to develop SWI closer integration to one or more of these.
Good point. Problem remains that there a are many editors these days and they all need to be handled differently. I understand some language independent infrastructure is evolving. That is good. Still, we are faced with a relatively small community, many editors and a language that can hugely profit from good editor support but is so different from the main stream languages that one typically get rather poor support. The big downside is that Prolog has no keywords and needs more sophisticated support than pattern matching to arrive at proper syntax highlighting or even indentation.
I think the recent popularity of the Language Server Protocol idea could help here; I wrote an LSP implementation for Prolog for use with Emacs, but it should work equally well in VS Code, Vim, or any other editor that knows how to act as a language-server client.
That indeed seems a promising route. Is there some overview on what facilities are provided by LSP and which clients support which facilities? I had a brief look at some sites. Most talk about finding symbols (definitions) and refactoring. That is great. What about auto indentation? completion? Syntax highlighting? I see some hints about the latter, but didn’t yet figure out whether this extension is mature and which editors implement it.
If we can hook up library(prolog_colour) and show syntax highlighting on a few or even one editor I’m convinced
My experience here is that auto-indentation, completion, and syntax highlighting is usually handled outside the LSP server. A consequence is that using the same LSP in different editors will result in different user experiences for those three features, whose quality and coverage may depend on the text editor itself (e.g. lack of support for regular expressions or limited support without look-ahead results in brittle syntax highlight for Prolog) rather than on the language support bundles.
In the particular case of syntax highlighting, that support includes, besides Logtalk constructs, Prolog ISO standard and de facto constructs (both core and modules). For other services (e.g. code completion, auto-indentation, code navigation, snippets, …), the support varies by text editor.
Several text editors support CTAGS, which provides a limited support for code navigation. But this is a bit of a last resort solution. SWI-Prolog bundled editor is much better at code navigation. Third-party tools such as PDT also provide good code navigation.
The protocol does allow for formatting/indentation (textDocument/formatting event) and completion (textDocument/completion), but the protocol currently doesn’t support syntax highlighting by design. However, there is an open PR to add “semantic highlighting” capabilities to the protocol, so when that lands I can try hooking up prolog_colour.
Since Qt11, the build system wasn’t working anymore… I had no time to dig deeper… some time ago I installed Qt12, but didn’t attempted again. Today I’ve pushed a simplified build, to my surprise it smoothly run the latest SWIPL. Now I’m sure I can provide the context sensitive autocompletion @prodog required, since the whole architecture of loqt is oriented to maximize SWIPL IDE facilities. Alas, it requires a bit of work to be ready for Windows10… @prodog: if you have patience
Another possibility, not a lot of work, I could make available the editor in QtConsole, but I feel there is a better plan: maybe we could revive battle tested XPCE in a lightweight client based on X11 NodeJS. This would allow to drop the Windows dependency. I would port the bits now in Qt to XPCE. Of course there is a dependency on WASM port of SWIPL core - I think it comprises most of the xref facilities…
It come to me as a surprise that X11 on node is so light:
mkdir x11-min; cd x11-min/; npm init -y;npm i x11
...
+ x11@2.3.0
added 2 packages from 2 contributors and audited 2 packages in 1.009s
Now we can
var x11 = require('x11');
var Exposure = x11.eventMask.Exposure;
var PointerMotion = x11.eventMask.PointerMotion;
x11.createClient(function(err, display) {
if (!err) {
...
X.CreateWindow(
wid,
root, // new window id, parent
...
I wonder where is all the heavy stuff ? VSC installation on my Ubuntu was more than 1Gb !
Well, enough noise… now, my wishes for the immediate XPCE future:
a CUA mode
Ctrl+TAB e Shift+Ctrl+TAB to iterate tabs
ESC close the search box (generally, search/replace should be rethinked)
a DCG cursor controllable from Prolog (stratified - from chars, tokens up to Herbrand bases)
Sounds interesting, but I’m not sure what you mean here. XPCE is basically an OO system written in C that can be accessed from and extended in Prolog. The graphical classes bind to a set of about 150 C functions that are implemented both for X11 and MS-Windows. What kind of architecture do you have in mind?
CUA mode is there. It is even the default on Windows. Use
Open Edit/Editor preferences
Uncomment key_binding.style: cua
Safe, quit and restart Prolog
You can also switch on the fly in PceEmacs using M-x key-binding-style RET cua RET (you can use TAB in most places to complete)
(2) you mean between PceEmacs tabs. That should be fairly easy (although multi-key handling is a bit awkward)
(3) Which one are we talking about? F4? Yes, it isn’t great. That too shouldn’t be to hard to improve though.
(4) I like a “DCG cursor”, but have little cue what it means
X11 on NodeJS, and swipl-win console emulation ported to XPCE.
From C, call into node-x11.
This should give us extended portability (I think).
From XPCE we have all we need to pursue improving SWIPL+XPCE, a really lighweight and capable platform.
This would require the SWIPL core running in WASM.
It’s a lot of time since I have (re)tried this path, since I have a question: Raivo’ repo has a link to a clone of swipl-devel on github. Should be changed to official swipl-devel instead ?
I know Has been a lot of time I bothered you on this … here I am again
What make me whining (mainly) it’s the difficulty to action menus, dialogs, windows and the like without mouse. I’m not sure these topics are covered by CUA, since also Java based applications (like Tuxguitar) don’t expose the Alt+Char ‘standard’ - where Char is simply the underlined one command identifier.
There are few rough corners, and surely can be fixed, but porting the whole to X11 is the main prerequisite fix… we could also gain a nice Window Manager, X11 seems to be alive and kicking
Points 3,4 go together, in a sense. What I’d like:
recall on search a dialog where the pattern is just a DCG goal, that can assume lexical values seen by the search procedure are stratified.
Just to say, we could select from a dropdown, maybe like
codes/chars
Prolog tokens
Clauses (optionally with semantically sound layout info)
After rewrite clauses
Executed clauses - we have plenty of RAM, I’m dreaming of a more declarative/visual debugger
Speaking of a shell language, we break out of a source seen as a file, but the cursor metaphora could still be useful. Then
Modules
FileSystem/URI namespace
These are hierarchical in the sense that going down to level a token if composed (somewhat) of a sequence the immediate upper lexicalized stream.
swipl-win UX apart, a phrase_from_source(+Goal, +Source, +Level) and the ‘replace enabling’ phrase_from_source/4 could be an interface…
I’m not yet with you. What exactly do you mean with X11? X11 as such is the low-level networked display infrastructure. It doesn’t do anything fancy. It is what is used by XPCE already, so what does NodeJS add to this picture? XPCE is lightweight and capable but rather old fashioned, both how it looks and in its internal design. X11 is IMO not very alive and kicking. Linux distros are (very slowly) phasing it out, The MacOS version isn’t any good and it isn’t ideal on Windows either. I have the impression you are referring to more high level features than plain X11?
I once did try to write a console in XPCE, but failed. That was really long ago though at times Prolog did not support threads (and certainly not well). It might be feasible now. XPCE doesn’t do much good with HTML though. I think that is the attractive part of your Qt console and SWISH.
I also do not really see the point for WASM. The WASM version is 32-bits (that is WASM), single threaded, no signal handling and slow (a couple of times slower than native). It can be a nice asset, notably for a web based IDE, but it is not the Prolog you want to run in general. For local development, SWI-Prolog is very much capable to run a user program and provide services for an IDE from the same executable. See main distro and CMAKE.md for building the WASM version.
I must be missing something I’ll handle the rest i separate replies as we get too many topics in one post.
