Re: QT Console

Whatever IDE is smoothest to use, there I shall go.  I expect the best course is 
to take a popular programmable IDE with an embedded console, enable SWI 
as a shell, and program things like syntax highlighting and indenting to 
call-out to the embedded SWI process for its decisions.

At present I use PCE emacs because it integrates well, but it has limitations 
for which I go over to other tools.
 
Alan Baljeu


----- Original Message -----
From: Jan Wielemaker <[email protected]>
To: Karissa Soo <[email protected]>
Cc: SWIPL Mailing List <[email protected]>; Carlo Capelli <[email protected]>; Günter Kniesel <[email protected]>
Sent: Thursday, July 11, 2013 10:54:27 AM
Subject: Re: [SWIPL] QT Console

Hi all,

I guess there is no such thing as a `one size fits all'.  Some like vi,
others Emacs, TextMate, Eclipse, notepad or whatever.

Günter and his students wrote PDT, which probably makes a lot of sense
for them because their primary language environment is Java and Prolog
is merely an important secondary one (right, Günter?). Surely compared
to various other attempts with Eclipse, PDT is a good shot. Besides, the
group is comitted to keep up the good work, so they might fix some of
the issues you raise. Of course, some are inheritly connected to
Eclipse.

Similar, there is also the GNU-Emacs mode by Markus Triska, and various
related packages for GNU-Emacs for other Prolog systems.

PceEmacs was the result of a simple editor that was written for XPCE for
reasons you'd probably laugh about now. They made sense on the late
eighties. The main reason to start it was the realization that you
cannot give good (highlighting) feedback using tokenization and other
surface text analysis for Prolog because the structure of the program
cannot be derived from syntactical properties. The tight integration
between Prolog and the XPCE editor allowed to get Prolog into the
picture for doing a much deeper analysis.

But, there are enough editors around and PceEmacs is unlikely to find a
big enough developer community to become a widely used general purpose
editor that is really good at Prolog. Surely, technically you can give
it vi bindings and make it look modern.

I'm at the moment also looking into CodeMirror, which is an impressive
in-browser (JavaScript) code editor. The current aim is more remote and
collaborative developent of small snippets, but this might well turn out
to be the basis of a browser based IDE for Prolog. Quite likely we will
see IDE like features emerging around CodeMirror. The other nice thing
is that we can run these tools in a browser, using XUL runner or inside
the Qt/WebKit environment that Carlo is working on. The current
challenge is to get semantically enriched highlighting to work. I worked
out a promising route for that with help from Marijn, the CodeMirror
lead developer.

We will see how all this will fit together.  Ideally, all this should be
based on reusable Prolog interfaces and components.  This is also where
PDT contributed: many of the hacky interfaces and components created to
make the XPCE tools work have been generalised and documented.

    Cheers --- Jan


On 07/11/2013 03:43 PM, Karissa Soo wrote:
> I did at one time; when I read your e-mail I couldn't remember why I had
> rejected it. Tried it out again today and remembered:
>
>     - I don't like having to create a project every time I program.
>     Especially not when I'm messing with a single file on one single occasion.
>     Not worth it. Plus...making every directory where one of these projects is
>     located an official workspace clutters my filesystem.
>     - I dislike Eclipse in general. Not only because it's the largest memory
>     hog in recorded history, but also because of all the things I complained
>     about annoyingly in my last e-mail.
>     - While some of the features you mentioned are useful (and I seriously
>     thing these should be included in SWIPL eventually, albeit in a less
>     outdated-looking manner), they do not outweigh the fact that the PDT is
>     extremely buggy....and runs a visible (non-iconified and non-hidden)
>     command prompt window all the time. (Why?!)
>     - On the opposite end of the code completion/parameter hinting spectrum
>     from Eclipse's normally hypercluttered,
>     hey-let's-trudge-through-the-full-docs approach, the PDT has no helpful
>     popup describing anything. I suppose I could add/suggest this feature, but
>     I don't like the rest of the thing to do it.
>     - There is tab completion in the console, but I don't think it cycles.
>     Also, when a user requests tab completion without supplying any characters
>     for the current word, I think the completer should just cycle through all
>     predicates. There is also no parameter hinting in said console.
>     - The completion itself doesn't work properly when it comes to
>     parentheses --if you type a predicate name plus a paren and then accept
>     completion (or press <tab> in the in-IDE console [a feature I think it'd be
>     cool for us to have, btw], it will basically tack another paren onto the
>     end?
>     - If you think that rather than improving PCE-Emacs and the SWIPL
>     console, we should hail the PDT as the superior editor/IDE, then shouldn't
>     we say something like, "Hey we have this editor that ships with
>     SWIPL....but it's not as good as this other one. Use that one instead" on
>     the SWIPL site? I mean, if we're going to let PCE-Emacs get behind/not be
>     improved, then technically isn't it not being actively developed anymore?
>     Eventually, it's going to get so deprecated we won't include it anymore. I
>     think that right now, when Carlo is doing the Great Shift, is the best time
>     to add new features.
>
> Thank you for your suggestion though! Some of those PDT features were
> really cool.
>
> Thanks again,
> Karissa
>
>
> On Tue, Jul 9, 2013 at 5:37 AM, G�nter Kniesel <[email protected]> wrote:
>
>> Dear Karissa,
>>
>> have you ever considered using SWI-Prolog via the PDT,
>> which offers everything you discussed (completion, etc)
>> http://sewiki.iai.uni-bonn.de/**research/pdt/docs/v2.1/editor#**
>> code_completion<http://sewiki.iai.uni-bonn.de/research/pdt/docs/v2.1/editor#code_completion>
>> plus a few things that QT, Emacs and friends are unlikely to
>> support anytime soon: the ContexView, GlobalView
>> http://sewiki.iai.uni-bonn.de/**research/pdt/docs/v2.1/**contextview<http://sewiki.iai.uni-bonn.de/research/pdt/docs/v2.1/contextview>
>> http://sewiki.iai.uni-bonn.de/**research/pdt/docs/v2.1/**globalview<http://sewiki.iai.uni-bonn.de/research/pdt/docs/v2.1/globalview>
>> visual representation of dead code, ...
>>
>> Cheers,
>> G�nter
>>
>>
>> On 08.07.2013 04:18, Karissa Soo wrote:
>>
>>>       Hey everyone! Earlier I was explaining to Anne Ogborn about how I was
>>> working on writing smart tab completion for the swipl-win window
>>> (specifically the swipl-win window...for some reason many people tend to
>>> overlook the fact that I am only writing completion for the graphical
>>> console) and she informed me that Carlo was leading the switch over to
>>> using QT.
>>>       I am concerned and would like to know if someone can supply me with
>>> the
>>> name of the SWIPL library or whatever that is being used to interface to
>>> the QT libraries. (I had really wanted the tab completion to be a module
>>> (contained in tabber.pl) that users could just load whenever, rather than
>>> something that required a lot of configuration...and I don't want to write
>>> everything based off XPCE, and finish just in time to watch the Big
>>> Switch.
>>> :)
>>>       Thanks!
>>> -------------- next part --------------
>>> HTML attachment scrubbed and removed
>>> ______________________________**_________________
>>> SWI-Prolog mailing list
>>> [email protected].**de <[email protected]>
>>> https://lists.iai.uni-bonn.de/**mailman/listinfo.cgi/swi-**prolog<https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog>
>>>
>>>
>>
> -------------- next part --------------
> HTML attachment scrubbed and removed
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>

_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog