Fwd: QT Console

    Reusing some of the XPCE stuff is fine with me; what I meant when I
said "and I don't want to write everything based off XPCE" was that I don't
want to write everything based off of what is available now, just before
the huge changes are applied. Does this make sense?
    I'm a bit of a newbie when it comes to SWIPL; I am just starting to
grasp the concept of the ^ operator....but I love reading the SWIPL docs
whenever I get the chance! So hopefully you guys aren't making me out to be
some kind of expert. (Really, I'm not!)
    Just so we're kind of on the same page (or at least similar ones :)  ),
*here's a basic outline of what I envision* in terms of the tab completion
stuff:

   - *Intelligent interface design* is obviously a must; one of my pet
   peeves is recently-released applications that look like they'd be right at
   home running on Windows 95. The appearance of the completion interface is
   equally important to its functionality. My original idea definitely
   involved some kind of *color *--at the very least, a lighter gray for
   suggested completion text. Since the whole thing is apparently going to be
   written on a much lower level than I had originally thought possible,
   syntax highlighting will probably be implemented somehow.
   - Depending on how many new possibilities that Qt opens up,* *space- and
   time-efficient *popup completion* would be excellent. This project
   originally started as popup completion for PCE-Emacs, which sadly seems
   impossible with XPCE (which imho should be expanded greatly or replaced
   [just sayin'; whoever wrote it did an excellent job])...downgraded my
   expectations and moved on to tab completion for the interpreter. An
   excellent model for what is, in my opinion, optimal in any context is
   Visual Studio's Intellisense. (Here
   <https://www.dropbox.com/s/lr0nytntwga2lhw/sample.avi>is a sample
   demonstration video I just made specifically for this e-mail.) 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), 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). [Hands down, VS is my all-time favorite IDE...and
   it's free (well, the Express version is)!] I think that something like that
   is definitely worth looking into. Other advantages (of many!) that popup
   completion has over tab completion are:
      - The ability to see a lot of important stuff at a glance. Good,
         well-designed content assist popups should have icons for
different types
         and access modifiers. In SWIPL, this would probably go with
module-specific
         vs global, variables, different predicate properties....and obviously
         variables vs classes vs get-methods vs send-methods in XPCE.
         - The ability to select with arrow keys.
         - Having stuff pop up as you type is my idea of convenience; not
         having to press tab all the time and cycle through the list of stuff
         *just to remember *whether it's (for example) setof or set_of is
         nice.
         - *Parameter hinting*, a sure sign of civilization (bad joke) in
         this rookie's opinion, is a perk that simply isn't possible in
         tab-completion. Rather than having to open up the docs just to see
         parameter types and/or descriptions of parameters (or even just the
         order!), all persons on earth should have the convenience of having a
         *small *(emphasis on small!) little popup thingy that autoadvances
         to the next parameter as they navigate the caret past each
comma in a list
         of parameters. (Again, look at VS [not Eclipse!] for a great
example of how
         this should be done.
      - That being said, *context-sensitivity* is a *huge *part of the end
   goal for me. In addition to knowing which modules are loaded and which are
   not, the completer should take into account things like predicate overloads
   (C# term; sorry!), argument #s, types, and caret/text cursor position. Here
   are some examples:
      - In a context where the user can obviously only supply an
         instantiated variable or atom (basically those args that have
a + in front
         of them in the docs), the user should not be offered names of
variables
         that have obviously not been assigned a value at that point
in execution
         (this would involve some kind of parsing on the completer's part, or a
         fancy regular expression thingy).
         - In a context where the user is supplying a variable with a ? in
         front of its name in the docs, the completer should look at
which parameter
         values have already been supplied and determine whether the
possibility of
         the currently-being-typed parameter being a variable is ruled out yet.
         - In a context where the arg type obviously must be a string (for
         example!), the completer's suggestions should not include atoms, etc.
         - What did the user use last? Are we instantiating something? Are
         we in the middle of a string? Am I in the middle of a word,
or does what
         comes after the text caret not matter because the user is
trying to insert
         something? What's most common? (Half of these will influence
sorting of
         possible completions.)
      - *As-you-go** completion* (meaning the popup would suggest something
   as the user types...so basically, the completion context is reevaluated
   each keypress). The user should have the option of turning this on or off
   (see last bullet point).
   - While avoiding berserk aggression levels, *correction** *of small
   errors should also be implemented. You typed "string_to_atm" or
   "stringto_atom" or "strng_to_aotm" when you meant "string_to_atom"? It's
   okay, the completer will correct that (a keyboard shortcut for "undo
   correction" would be nice)...as well as understand that you're accepting
   the completion currently selected in the popup when you press "tab" or
   "space" (this should also be configurable!).
   - I think that some *configurability** *ought to be added once
   everything else has been (mostly) sorted out. Some users want parameter
   hinting, some don't. Some want tab completion, some want popup completion,
   others don't. Some people think syntax highlighting is the greatest thing
   since sliced bread, other people find it distracting. Some programmers like
   completion, others don't!

Thanks again,
Karissa


P.S.: Progress will likely be very slow, considering that summer is almost
over....and I hear that junior year is pretty hard (and then there is also
the issue of college applications....) so I probably won't have time to
work on this stuff as much as I'd like to.
P.P.S.: Some other suggestions I have:

   - Project creation interface in PCE-Emacs
   - Basic examples added to documentation for each predicate
   - String concatenation operator (+=)?



On Mon, Jul 8, 2013 at 1:06 AM, Carlo Capelli <[email protected]>wrote:

>
> 2013/7/8 Karissa Soo <[email protected]>
>
>>     Hey everyone!
>
>
> Hi Karissa
>
>
>> 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
>
>
> I'm using the C interface ( or better, C++, just #include <SWI-cpp.h> ) to
> host the runtime, i.e. swipl.so on Unix or swipl.dll on Windows, in a Qt
> text editor.
>
> The tricky part, that I had some hard time to get working, is about
> leaving IO unchanged and getting threads attached to Qt from Prolog side (
> it's working now, kind of ).
> Now I'm working on the swipl-win interface, controlled from a Prolog
> script.
> The editor, debugger, etc keep running on XPCE.
>
>
>> 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...
>
>
> About completion, I think Jan will publish a PL_... C interface that will
> give more sensible hints, by means of inner access to REPL context.
> To be true, also the already available (but I don't know how to properly
> access it) tab completion is far smarter than my code, that simply caches
> the result of this:
>
> ?- setof(P,M^A^(current_predicate(M:P/A), \+sub_atom(P,0,1,_,$)), L).
>
>
>> and I don't want to write
>> everything based off XPCE,
>
>
> Working on XPCE seem reasonable to me. I'd like to try to reuse XPCE
> interfaces in Qt. Could we meet in between ?
>
>
>> and finish just in time to watch the Big Switch.
>>
>
> This week ( I hope :) I'll upload to github the alpha release of swipl-win
> interface, to evaluate deployment feasibility.
> Since Qt is evolving, it's kind of experimental work.
>
>
>> :)
>>     Thanks!
>>
>
> bye -- Carlo
>
> -------------- next part --------------
>> HTML attachment scrubbed and removed
>> _______________________________________________
>> SWI-Prolog mailing list
>> [email protected]
>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>>
>
>
-------------- next part --------------
HTML attachment scrubbed and removed