Re: QT Console

Dear Karissa,

thank you for the feedback. Some of your complaints are a matter of
taste on which I won't comment :) Some are a matter of lacking
experience with Eclipse. I will answer those. And some are claims
that I do not understand. You find my requests for clarification
below, especially for the unexplained claim that the PDT is 'full of bugs'.

> Eclipse's comes close, but sadly is cluttered, provides too much
> information (I do  *not *want to read the complete javadocs every
> time I just want to see a description of the method),

You do not need to read it if the name is sufficient to know which
option to select. But otherwise, showing the Javadoc in-place is a
great way to help you choose among similarly named methods. It saves
you having to go to their source code just to decide which one you want.

> and isn't as context-sensitive as I'd like (when naming a variable, I
> do not need suggestions...especially not those of existing classes).

Now you confused me. What do you want: A more context-sensitive
suggestion or none at all?

The reason why it makes sense to see similar names that exist already
is to suport naming consistency across a project. There are some
intersting software engineering papers on the importance of good
and consistent naming.

>   * 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. 

In Eclipse you CAN store your files in a workspace but you do not NEED
to. You can IMPORT projects and files physically located somewhere else.
All my workspaces physically contains only their metadata. They import
all the projects from their locations. Among the projects is
one that I use for quick experiments. There is where my small one-time
tests go before they are either deleted or evolve into something real.


>   * 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....

I'd apreciate knowing in which sense you think that the PDT is 'full of
bugs'. We don't know of any. You're welcome to report whatever you think
is a bug either directly to me or to [email protected] or. We
will be happy to fix them as soon as we know about them ;)

> and runs a visible (non-iconified and non-hidden) command prompt window all the time. (Why?!)

Obviously, because you do not hide or close it ;)

In Eclipse EVERY view can be closed and reopened as needed and
can also be iconified. You can use it even in its iconified state (it
springs into life for your interaction and collapses back into its
icon when you click somewhere else). For iconifying (=minimizing) and
maximizing use the two symbols in the upper right corner of every
Eclipse view. FOr closing use the cross that appears on the
right-hand-side of the view's name. You get back closed views via the
menu item "Window > Show view...".

>   * On the opposite end ... 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.

You just criticized Eclipse because it provides the additional popup
information and now you criticize the PDT because it does not?
Sorry, you lost me. What do you want?

In addition to that, the PDT actually shows additional information
IF THERE IS some. So I guess you just didn't realize yet that you
actually love the PDT ;) because it does not even bother you with the
additional empty pop-up if there is nothing to show (for instance, no
documentation for the predicate).

>   * 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

Indeed, the completion of the console is not the same as the one of the
editor. The editor does parameter completion if it knows enough about
the parameters. This is on our to do list.

>   * 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? 

Pressing tab works in the editor for predicates that have sufficient
meta-information about parameters. Then it even provides default names
for the variables in the arguments and you can tab through the arguments
and ovwerwrite/adapt those who don't fit.
E.g. classT(Class, Parent, Name, Members).

>   * I think that right now, when
>     Carlo is doing the Great Shift, is the best time to add new features.

I much apreciate Carlos efforts. Obviously, there is demand for a
keeping PCE-Emacs alive. You witness it :)

Overall, it all depends on what you want. We use Eclipse because it is a
great environment when it comes to large scale development: many files,
many developers, many tasks, many working contexts, ... It consistently
offers everything you need for that, in a variety of choices. And
everything works smoothly with all the rest:
  - version control (GIT, SVN, CVS, ...)
  - issue tracking (tenth of system)
  - a task oriented user interface (Mylyn)
  - ...

I have put a lot of time into the meta-predicate inference that fuels
the call-graph of the PDT, mainly because missing a single broken call
affects me much more (in terms of broken code, debugging, etc.) than the
question of how many characters I can save typing with a more
intelligent completion. The one affects correctness, the other is a
convenience.

So far, we have focussed our efforts mostly on the correctness issues.
Meta-predicate analysis for reliable call graphs and their visual
presentation was a first step. The next will be refactoring support.
We will keep on offering all of this also to Jan, so that also non-PDT
users can benefit form it. Our meta-predicate analysis underlies also
the detection of uncalled code in SWIPL. The visual call graphs might
follow if somebody is willing to invest time into reimplementing that
in a QT environment...

By the way: Even if completion is not our most urgent priority now,
thank you for your valuable suggestions of how you want completion
to be.

Cheers,
Günter

> 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]
> <mailto:[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 <http://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
>         <mailto:[email protected]>
>         https://lists.iai.uni-bonn.de/__mailman/listinfo.cgi/swi-__prolog <https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog>
> 
> 
>