Intellisense when typing code

[tc]

I was looking at the blog at http://joachimtuchel.wordpress.com/ and noticed the item mentioned in the subject.

The GUI side of it would require a simple pop up menu at the text cursor location as the user is typing. However, the issue I see, on Windows at least, is the text box only returns the index of the cursor into the string. In other words, if the text box has an 80 character string, the text cursor might be 20 characters in, or 40, or 60, etc. but there is no method nor a Windows call which will return the coordinates (x@y) of the text cursor. At least none that I've found.

Any thoughts on how one would determine where to pop up a simple menu?

Thanks.

--tc

NOTE: This is purely research for proposing road map items.

[TriSebastian]

Hi tc,

I already started a solution like this. But like most good ideas there are more important things to go on with.

I once implemented a workbench which enabled users to directly edit texts in a drawingarea-based widget.
I think I used the "AbtDirectEditWidget" to accomplish that.

One might need to lay some kind of tweaked drawingarea or form under the multiline edit text view of the codeing browsers, to be able to connect callbacks like positioning on top and handle all the inputs.

It would be really fine if you might get this extension into your roadmap!

Sebastian

[tc]

Hello,

One might need to lay some kind of tweaked drawingarea or form under the multiline edit text view of the codeing browsers

I could develop a custom text edit widget that would give me the information needed but the current widget is used by VA Assist to color text and a custom widget would no longer be a Windows text widget.

The idea of having a drawing area under the text widget sounds easier and that is what I'll experiment with.

--tc

[jtuchel]

Taylor,

just as Marten mentions on his blog, there are possibly alternatives to implementing a text editor widget, like using Scintilla on platforms where it is available. Have a look at the post: http://schrievkrom.wordpress.com/2011/01/13/vasmalltalk-intellisense/

---
A quote from Wikipedia:
Scintilla supports many features to make code editing easier in addition to syntax highlighting. The highlighting method allows the use of different fonts, colors, styles and background colors, and is not limited to fixed-width fonts. The control supports error indicators, line numbering in the margin, as well as line markers such as code breakpoints. Other features such as code folding and autocompletion can be added. Currently, Scintilla does not support Right-To-Left languages (e.g. Hebrew, Arabic, etc.).
---
Sounds like exactly what I mentioned in another post on this forum a few hours ago.

Scintilla uses GTK, so it might fit quite well into your plans with GTK on Linux...

Joachim

[jtuchel]

Hi again,

using existing controls would probably also help a lot in supporting alternaitve syntaxes like JavaScript, HTML, XML, SOAP, etc., which are very likely to become quite important (if they aren't already) in Smalltalk projects - without spending many man-years on reinventing the wheel....

Joachim

[TriSebastian]

Hi tc,

you mentioned there might be no Windwos API call to get the current cursor position.
Maybe you will find some inspirations here:

http://www.codeproject.com/KB/cs/diy-intellisense.aspx

Regards,
Sebastian

[tc]

Hello,

Cool site! I'll be studying that code.

Do you have an account there or did you find the site while searching?

--tc

[TriSebastian]

Hi tc,

I have an account there. Used it quite a while back at university.
It's always a good source to find some win32 gdi solutions which can easily be ported to the VAST osWidget layer.

It even helps a lot if the msdn information isn't that helpful, or detailed.

But you have to take care. Some things provided are quite "hackish". and not really suitable for a production system.

I guess you will find a good solution for this. More important and difficult will be the logic filling your popup with proposals.

I once started to migrate e-completion from Squeak to VAST.
Maybe you would like to have that non-runnable codebase for further investigtion? Just as a source for ideas?
Drop me a mail and I try to send you a loadable version.

Sebastian

[jtuchel]

Hi

this is a bit off-topic, but somehow related to editing code in VAST.

A small and helpful improvement for VAST would be if the RB and QA Code Formatter do not reformat each other all the time. I have no real preference here as to whether I like the formatting of RB or of QA more, so I wouldn't personally care if out of the box they both do the same thing one way or the other. It's just annoying that they format differently, and you cannot escape the RB formatting in an EASY way.

I know that I can tweak them both. But I shouldn't have to just to avoid the two contradicting each other in almost every single aspect of code formatting...

Just another idea

Joachim

[koschate]

A small and helpful improvement for VAST would be if the RB and QA Code Formatter do not reformat each other all the time.

Only this afternoon I was thinking the same thing. I have our environment set up to automatically format using the QA Code Formatter on method save, but methods created using the RB method extract and such are formatted using the RB style.

Somewhat related to that, it would be great if the differences browser could be set to ignore non-semantic differences such as formatting. Ideally, the tolerance could be dialed from ignoring formatting differences up to and including ignoring changes that are due to things such as variable renaming. This shouldn't be too hard to implement using the same comparison techniques that the RB uses to decide if a method already exists.

Personally, I'd give less weight to merge tools. If one is writing short methods, I can't see it taking a lot of effort to merge two competing versions of a method. If one is routinely running into situations where competing versions of long methods need to be merged, this should be a loud, clear signal that the method is screaming to be refactored, not a cry for a better merging tool.

[jtuchel]

Tom,

I agree. If we all wrote short methods and were good in OO design and programming techniques, the quality of our tools wouldn't matter all that much.

I just had the same discussion with a Smalltalk friend yesterday. We old bones Smalltalkers often don't realize how much tool support we are missing:
* no need for code completion/intellisense if I know the Collection Protocol by heart
* no need for a code formatter because it would only start religious wars in the prject team and we as as a Smalltalk community would be extinct within weeks
* no need for good merge support because Smalltalk is so easy to read
* no need for line numbers or cod folding because our methods are no longer than 6 lines (gives me a good laugh every weekday when I work with legacy code)
* no need for any tools that help me keep track of my browsing history, because you get used to 38 open windows very soon
* no need for a "new class" dialog because everybody knows I can just type over an existing class definition expression to create a new class
* no need for an online "API" documentation because I can always fire up a Class Browser on SortedCollection to see how I can use it
* The list continues

But still, when I'm in Xcode and enjoy code completion, online help, good merge tools and a nice-looking environment, I feel some excitement about that. I would say that Objective-C methods are also short, if you program in good OO style. Being able to fold/unfold code can help a lot. Finding the opening bracket for a closing one helps me find missing ones. Code completion which also helps me find the online documentation for what parameters to hand in etc. helps me.
Maybe that's because I am a relative Objective-C newby and need that, whereas I don't need it in Smalltalk all that often. But maybe I am also not the kind of user that brings in fresh blood into the community.

[koschate]

If we all wrote short methods and were good in OO design and programming techniques, the quality of our tools wouldn't matter all that much.

While I'm happy to have inspired a blog post for you, I just want to to be clear that all I said was that I'd place less weight on the merge tools at this point. Instantiations has limited development resources, and there are other things I'd rather see first.

We can encourage desired behavior (e.g. creating short methods) in a number of ways. One of these ways is by making undesirable behavior more difficult, like making it harder to lock one's keys in the keys in the car by requiring one to use the key to lock the door. If we make it easy to manage long methods, I'm concerned that we're just facilitating behavior that we really want to discourage.

Way back, during my days at Footprint, a tool for VA was introduced named Viceroy, if I recall correctly. It ran a number of code metrics and quality tests on a method, and displayed one of three bitmaps at the top of the method code window to indicate whether the method was acceptable, had problems, or really needed work. I'd love to see that come back.

I also want to be sure that all development effort doesn't go into tools that will only work in the Windows environment. In our team, we deliver primarily in Unix, and many of us find it valuable to develop in Unix as a result (there can be some really nasty differences in window behavior). However, we lose many of the nice enhancements as a result (for instance, the indicator that a method is calling a non-existent method). Intellisense can be a wonderful thing, but it does nothing for me if I can't use it in Unix.

I appreciate that it's important to attract new users to Smalltalk by making the environment sexier and more familiar to them. On the other hand, down here in the trenches, I'm looking for tools that will help me manage and improve the code and coders I've already got.

[jtuchel]

While I'm happy to have inspired a blog post for you, I just want to to be clear that all I said was that I'd place less weight on the merge tools at this point. Instantiations has limited development resources, and there are other things I'd rather see first.

Sorry if my blog post sounded offenisve or something. I just had expected the "Smalltalk has short methods, so what?" argument and think it is just nonsense in the real world. I try to write short methods and I do refactor often to sghorten methods, but tha's not what all people do. And I do wrore long methods when I start implementing functionality. I hack it into the browser and see how far I get, modifying it to my needs. In this phase Envy is a great help in taking a step or two backwards, and making progress means throwing away changes from time to time. So even as a Smalltalk developer with some basic knowledge, I break the rules and am happy with it.

I didn't read your post as "I don't want a better changes browser", but I understood exactly what you're saying: you see other things as more pressing (I hope you'll come up with a list).

We can encourage desired behavior (e.g. creating short methods) in a number of ways. One of these ways is by making undesirable behavior more difficult,

I doubt it will help in a code base where the authors of long methods have long moved on to other projects.
The best thing to do is educate people and find consensus by convincing them of the benefits of good behaviour.
On the other hand, if you have developers who come to Smalltalk from verbose languages like COBOL or Java, there will probably not be much understanding for a "no more than 6 lines per method" rule. In their other life, 6 lines were barely enough to reach the first curly brace or start with the data division.

I also want to be sure that all development effort doesn't go into tools that will only work in the Windows environment. In our team, we deliver primarily in Unix, and many of us find it valuable to develop in Unix as a result (there can be some really nasty differences in window behavior).
However, we lose many of the nice enhancements as a result (for instance, the indicator that a method is calling a non-existent method). Intellisense can be a wonderful thing, but it does nothing for me if I can't use it in Unix.

Being one of the loudest whiner for a Mac OS X port of VAST, I have no chance than to agree here. A windows-only feature is a non-feature, not only for the AIX and Solaris users, but also the Linuxers. If VAST should get into the hands of new Smalltalkers, Linux is THE platform to target. And if we get nice tools, they need to be in the hands of all VAST users.

I appreciate that it's important to attract new users to Smalltalk by making the environment sexier and more familiar to them. On the other hand, down here in the trenches, I'm looking for tools that will help me manage and improve the code and coders I've already got.

Amen. And I think a good tool for identifying and handling changes would enourmously help in maintaining existing code. Along with a code editor that offers features people are used to in other environments and many more features.

Joachim