Editing class method sources in single place

tim Rowledge <[hidden email]> writes:

> On 31-Jan-08, at 10:00 AM, Friedrich Dominicus wrote:
>> Smalltalks Editors could gain much by
>> just beeing a bit more Emacsish ....
> NNnnnnooooooooooooooooooooooooooooooooo
> <runs away, very fast>
Yeah I should have expected, that ;-) It's ok, just you can not deny
it it's much more decent Editor. And it's "environment you live in for
handling text" I for my part would appreciate such an "environment"
where you live in for Squeak also. I know one can but I ask you to be
honest. How useful is Celeste? Or any other tool handling some text,
wouldn't you agree that this relativly bad. I know another bad example
is the integration of Windows programs via COM. Yes you can say,
"heaven help Windows" but you can program everything and it handled
text (among others quite well) Please tell me what would Smalltalks
loose while making handling of text easier? What would you loose? You
still can use your browsers, you still can inspect whatever you like,
but you also would be able to handle Text, and would not have to leave
Smalltalk just to write a letter, an email or whatever. I certainly
can not understand why one can not see the shortcomings in this
area...

Regards
Friedrich


--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

From: Friedrich Dominicus <[hidden email]>
 >>I don't want to change your way of doing things. But I'm not willing
to just adopt to this way. I conceil I'm corrupted by (X)Emacs (it's
among other a decent editor) Smalltalks Editors could gain much by just
beeing a bit more Emacsish ....


I, too, have no desire to change anybody else's successful solution.  
But I dearly miss Emacs when working inside Squeak.  (Not so much Dired,
or Gnus, or any of the other Emacs-as-OS applications.  Just Emacs, the
excellent text editor.)  I miss consistent keymappings (SVI/Emin held
promise until it started spewing DNUs one evening... not sure what I did
there), I really miss keyboard-only navigation; however, most of all I
miss "dead" code: plain, flat, abstract text that only denotes code
through some abstract evaluation.

For interacting with a live environment, the Browser is great.  Squeak
is full of wicked livecoding tools.  But there's a mode when I don't
want to livecode, when I do want to work against a flat, dead, textual
representation of some subset of the program.  Text is a marvelously
malleable medium that I can feed to a host of other programs for pre-
and post-processing.  I can impose on plain text as much or as little
structure as /I/ want, and change that structure at /my/ whim.  Text is
cheap to push around the screen, even on the slow devices that I favor,
since its content has been computed statically.  And a block of text
doesn't need to be coherent again at all - neither syntactically nor
semantically - until I return it to the livecode Squeak world with a fileIn.

As long as I have fileIn and fileOut, I have recourse to a familiar text
editor.  Now if only those methods were invokable from outside of the
Squeak image ....

Hi Sophie,

on Thu, 31 Jan 2008 19:28:06 +0100, you wrote:
You may perhaps want to try the attached. It contains a simple example of  
a flat view on methods of both instance+class side and also a more complex  
example on "what just *my* methods need from Stream+Array".

With the attached .st you can formulate more/other queries for your  
"working context" in a simple query language (1-from, 2-where, 3-select)  
which works with tuples (v.s. plain collections). Because I'm lazy the  
examples open in a stock browser view ;-) see the screen shots.

Have fun and let me know if sort of this can improve the "current task"  
experience (perhaps when redoing the related query as part of alt-s).

/Klaus

"tim Rowledge" <[hidden email]> wrote
>> Smalltalks Editors could gain much by
>> just beeing a bit more Emacsish ....
> NNnnnnooooooooooooooooooooooooooooooooo
> <runs away, very fast>

Most "emacs|vi|...ish" requests are really about:

"I would like to
- move around my code structures
  - package, class, method, sub-expressions, hierarchy, senders..
- finding or selecting elements, grouping elements, etc.
- operating on my found, grouped, or selected elements
- with keyboard fluidity and minimal distraction
- (preferably) using familiar keyboard shortcuts".

Few want literally single text-file editing of a class (or package, or image
:-)

My customary 2 c :) Sophie

itsme213 wrote:
Hear, hear! Especially the bit about not having to touch the damned rodent.

Tony

tim Rowledge wrote

On 31-Jan-08, at 4:14 PM, Blake wrote:

> On Thu, 31 Jan 2008 14:25:47 -0800, tim Rowledge <tim@rowledge.org> 
> wrote:
>
>>
>> On 31-Jan-08, at 10:00 AM, Friedrich Dominicus wrote:
>>> Smalltalks Editors could gain much by
>>> just beeing a bit more Emacsish ....
>> NNnnnnooooooooooooooooooooooooooooooooo
>> <runs away, very fast>
>>
>
> Oh, a vi fan, eh?
Aaaaaarrrrrgggghhhh!

No. No way. No how. I like my ParagraphEditor thank you very much. If  
I *have* to use a not-Smalltalk text editor then I prefer StrongEd  
(google it) and I can tolerate TextWrangler - just barely.

StrongEd? What's wrong with Zap eh?

On 1-Feb-08, at 12:33 AM, Ben Goetter wrote:
>
>   But I dearly miss Emacs when working inside Squeak.

I'd have to say that I think you're completely missing out on a lot of  
the Smalltalk Way in that case. I used emacs for *years*. I hated  
modal editing (and as for vi... blech. overwrite mode? insert mode?  
append mode? destroy-your-file-by-mistake mode?) and the totally  
overbearing do-everything with only fifteen convenient keypresses  
approach. I mean who *really* needs access to ctl-alt-opt-shift-meta2-
RMS to get an ascii portrait of Stallman in his speedos?

When your text is in small chunks  - and if you're writing large  
chunks of code you're Doing It Wrong - you just don't need regular  
expression handling that can find all files in a complex set of  
directories based on your .emacsdirpathopt file(s) and then convert  
all complexly specified search targets into complexly specified  
contingent results and then rewrite each file; with another option to  
specify what to do if the file is not writeable, of course.

Having said that, if you really insist on living within some demented  
editor-as-OS world then you are quite at liberty to code up FFI calls  
to provide access to method code to whatever editor you like and to  
make use of OS facilities to have the editor save-file actions result  
in the chunk of code being returned to the compiler for accepting. I  
suspect that in the milieu of COM/OpenDoc type systems it could be  
done quite well. I imagine it would be possible to hook up to XCode,  
for example. But I'm afraid I won't be helping to implement it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A bug in the code is worth two in the documentation.

On Thu, 31 Jan 2008 21:51:18 -0800, Jason Johnson  
<[hidden email]> wrote:

> Fair point.  What about having a sort of "context view" off to the
> side that shows all the methods referenced in by the current method?
> You could even have a setting to say how far out to fan (i.e. 2 levels
> shows all methods used in the current method, and all their methods).
> Of course we would first need a way to filter what would show up in
> such a context window, so we don't get flooded by non-project code.

Yeah, something like that. I was thinking a vertical orientation, but that  
wouldn't be a requirement.

> Are you really implementing?  I suppose you could use some of that
> nice free labor (students) to get something developed. :)

Interesting thought.

One more idea:
How about adding a single input field for 'address', where i can type
Class>>selector and make browser open it.
and make it with hinting while i typing (when i type first letter of
selector, it shows a popup list with number of choices).
Also, it can react on typing just selector (it's easy to determine,
because all classes are starting from capital letter)

What i like in Firefox, that i need to type few letters in address
field to get what i want (the sites i visit most frequently).

Discussion is shifted to speak about text editors. I must say, that
editor capabilities is far than enough to code quickly. What is
lacking is a ways to navigate quickly between different methods and
ways to organize my 'working context' to have almost instant access to
classes/methods i need for my tasks.

--
Best regards,
Igor Stasenko AKA sig.

> To me the source of usability problems in browsers is that there is
> two modes of work: editing and browsing.
> One problem is that when you are in "edit mode", you can't browse
> code: you have to save the code first, or open a new browser window.

open a new browser is ok to me...

> And when you are in "browsing mode" and start to follow senders,
> implementors, references you end with a lot of browsers opened but
> just a few a relevant.

That's a problem.
One thing I tweaked a year ago, was the closeAll command and the
browser, so as to have a command in the window menu to close all non
important window. All browser where code is edited and all browser
checked as relevant wouldn't close.
This was useful but I lost what I did (was too much hack).

>
> And for beginners, I think that big annoyance in Squeak are not
> multiple browsers, but hotkeys,  input focus, and undo.
> For example the FillInTheBlankMorph lost the focus when you point the
> mouse pointer to another place, this is an unexpected behavior.
>
+1
It took me long to learn hot keys and how to navigate in the code...
cmd+... (b, n, m, N) are the most I use in that order to browse
sometimes cmd+... (W, E) to find selector or text from partial word

of course cmd+... (d, p,s) for executing,  (i and I) to inspect and
(c, x v) copy/paste
cmd+l is useful to cancel a change when double edit ans the code
window surronded in red

So it's a LOT to know !

While I'm here, let me say that I'd like an enhanced browse fonctions
so as to use wildcard as in the search browser (like if you type
WA*Test in the search browser or in the upper OBbreowser field).

Input focus is a pain to me... I often lost focus because the mouse
moved, moreover, you always have to have a hand on the mouse.
----------------

**Last point**, I find one proble is that menu are too much populated
! I always use the open menu and that's nearly it. Sometimes the
window menu, sometimes, the change...and saving too... I never use
right click world menu... I hate hitting the "more..." menu

It's even more difficult to feel at ease in the menus than with hotkeys:
left click open a menu, right click too, shift right too, shift left
too, ctrl right and left too... there all differents and also depend
on the object you clicked on (World, Text, PlugableList...). After
several year of squeak practice, I'm still lost in menus ... :)
Could't we come up with a better menu strategy ?

Cheers
Cédrick

2008/2/2, Igor Stasenko <[hidden email]>:
> One more idea:
> How about adding a single input field for 'address', where i can type
> Class>>selector and make browser open it.
> and make it with hinting while i typing (when i type first letter of
> selector, it shows a popup list with number of choices).
> Also, it can react on typing just selector (it's easy to determine,
> because all classes are starting from capital letter)
>

I think the search browser is a start for that. It certainly need to
be improved but there is an adress field in the OBBrowser's where you
can browse/find different stuff. It's based on the Mercury finder Avi
quickly made.
I use it a lot to find classes...  WA*Conf*ation   stuff like that. It
gets more complicated and less useful for selectors (#aSelector) as
there is no wildcard possible for now...

Hello Blake,


B> That was never my suggestion. In fact, the set of code items in question
B> is going to be split among classes, and isn't necessarily going to embrace
B> entire classes. I suspect variants in here--some folks are going to favor
B> a LIFO type stack, while others might prefer an alphabetic arrangement.

a variant of this is done in the TracingMessagesBrowser by Chris Muller
which is a Senders Implementors Browser giving a hierarchical view of
an algorithm across several classes.

Helps me a lot to understand or change code I didn't touch for some
time.


Cheers,

Herbert                            mailto:[hidden email]

On Jan 31, 2008, at 2:56 PM, Blake wrote:

> On Thu, 31 Jan 2008 13:41:49 -0800, Brian Brown <[hidden email]>  
> wrote:
>
>> A lot of this conversation smacks of Ned Konz's Starbrowser - it's  
>> on squeakmap, but I don't think it will run on newer stuff than 3.7  
>> without some love.
>
> The layout's pretty nice. Do those arrows mean you can traverse code  
> like a stack?

Yes, exactly.

>
>

On Sat, 02 Feb 2008 08:00:12 -0800, Herbert König <[hidden email]>  
wrote:

> a variant of this is done in the TracingMessagesBrowser by Chris Muller
> which is a Senders Implementors Browser giving a hierarchical view of
> an algorithm across several classes.
>
> Helps me a lot to understand or change code I didn't touch for some
> time.

Sounds interesting. I can't even get it to load, tho'.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Hello Blake,

B> Sounds interesting. I can't even get it to load, tho'.
right now I dropped (in this sequence)
Ma exception handling-cmm.12.mcz
Ma base additions-cmm.34.mcz
Tracing Messages Browser-cmm.19.mcz
into a fres 3.9 image and it worked.

There may be newer versions. Drop me a mail, if you need the files.

Cheers

Herbert                            mailto:[hidden email]

+ Date class >> today

+ Point >>min: aMin max: aMax

+ Collection >> add: newObject

+ Date class >> today

- Point >>min: aMin max: aMax

     ^ (self min: aMin) max: aMax

 

+ Collection >> add: newObject

 

 

>

IMHO, it would be more convenient to have separate 'tree window' and 'view window'
once you clicking onto item of tree, the view window contents is changing to view corresponding item.

These two widgets should be placed on desktop separately (so you can move and arrange them as you want to).

--
Best regards,
Igor Stasenko AKA sig.

Francisco-

I like the idea of keeping only the methods of interest around somewhere,
like you outline or as someone else mentioned with MorphicWrapers as even as
separate windows.  I was surprised at first to see a PlantStudio reference
in this context, but after seeing the screenshot it made sense. Here are
some comments on the origins of those ideas, as well as a simple suggestion
in the last paragraph, involving just keeping the recently viewed method
history in a side panel of a regular browser, like Firefox can.

=== History

The PlantStudio browser, and also the Garden Simulator browser which
preceded it, screenshot here:
  http://www.gardenwithinsight.com/sc_brows.htm
were inspired from Smalltalk, but also from VisualBasic and Delphi property
tools for editing form widgets.

Lazarus is a free Delphi-like system, a couple "Object Inspector" window
screenshots from it:
http://www.lazarus.freepascal.org/modules.php?op=modload&name=Screenshots&file=index&req=showsc&id=4
http://www.lazarus.freepascal.org/modules.php?op=modload&name=Screenshots&file=index&req=showsc&id=5
These show that idea of having the value on the same line as the name (and
you can change the value on that line), but also being able to expand the
item if it has internal complexity (see the FONT line on the first link) so
you can change the parts separately. In PlantStudio, S-curves were something
that needed to be changed that way as the curves were defined by more than
one numerical value.

PataPata is another variant (post-PlantStudio), except with the expansion in
a lower pane, more like a Smalltalk browser. This is a little bit like what
Igor suggested (but not separate windows, which might be nicer). Here is a
screenshot (see the most front window):
   http://sourceforge.net/project/screenshots.php?group_id=165910
In the end, I didn't like it much, for a few reasons. (*)

In the Garden Simulator (released around 1997) we organized what we called
"aspects" (variables or derived or simulated current values) related to
simulation objects into Smalltalk-like protocols we called "groups". One
difference was that you could have an aspect in more than one group. We
removed that flexibility to make your own groups in PlantStudio (thinking
less is more? :-) I would put that flexibility back in a more generic way if
I did it again (I would like users to be able to create their own models and
declare their own groups).

There was another idea in the Garden Simulator browser:
  http://www.gardenwithinsight.com/sc_brows.htm
"The browser is a tool for examining the simulation in detail. The browser
has two sides. The numbers side shows you the numbers in the simulation very
simply as numbers with units on a sliding gauge. The pictures side shows the
same information, but arranged in ways that are more visual and easier to
understand. For the weather, you can see running graphs of temperature,
humidity, precipitation, radiation, day length, and wind speed. For the
soil, you can see a soil profile with soil color, temperature, pH, nitrogen,
phosphorus, soil materials, or plant roots. For a plant, you can see a
close-up look at the plant, a breakdown of plant biomass in various plant
parts (such as leaves and fruits), or the stresses on the plant's growth.
Groups help to manage the complexity of the over 800 aspects in the
simulation. You can create your own groups. You can also use the browser to
harvest fruits from a plant, create your own plant cultivars (varieties),
soil types, and climates, and change many of simulation values. "

What is most important there is that the browser could actually mix
presentations of the same data. So, in a Smalltalk context, imagine a
browser with a left hand side which is the bookmarked methods you indicate,
and perhaps a right hand side which might be, say, a graphical network
visualization of the way the methods call each other. That browser was
inspired by the left brain (logical) / right brain (visual) duality idea
some have proposed.

== Generalizing

So to generalize that with the bookmark idea, what you kind of want is some
way to collect all the views on a specific task you are working on into a
coherent whole, especially one you can dismiss or hide with one click. I
have so often opened two dozen windows trying to debug something, or trying
to make some change to the code, and then had to find each window, remember
why I opened it, and close it, while still leaving some windows open.  I'm
not sure how to do that in a generic way, especially because tasks seem to
shade into each other -- you solve one issue but a related one comes up.

Perhaps an OLPC/Sugar-like history list of *when* you opened windows in
time-order might be most useful? Or it could track when you last looked at
the window or changed something relevant to it? It's almost a workflow-like
problem. Definitely a possible area of exploration.

Maybe it would be useful to have one method per window but just have a
better way to organize and reorganize windows (or window icons) in Squeak.
Perhaps that generic system might know something about when the window was
opened or what else was going on in the system or how the windows were
related (which browser window spawned from another).

But perhaps simplicity is a good philosophy here -- and one window with a
bunch of related bookmarked methods of interest might be good. But you still
end up needing to spend time managing what you put in and take out of your
bookmarks, and if they keep growing you end up with clutter again.

Other simple things might be holding or coloring or graying methods in a
browser based on how recently you looked at them. That way you could find
them again more easily at a glance.  I think someone did this? Maybe part of
Spoon for methods which were actually used as code coverage?

Generalizing, this is all about restricting views of the system to what is
interesting or useful to you at the moment. That can be done by your own
choice (bookmarks), or it can even be done by others in an educational or
corporate setting, restricting programmers to what they are allowed (by
someone else's bookmarking choices) to view or change (assuming a security
model, which Smalltalk does not have, and maybe shouldn't). Completely
generalizing this would entail making "bookmarks" somehow a first class
object in the system's design, perhaps called "shadow modules"? :-)

== Simplest suggestions

In practice, what I often want is to view only a *few* classes of interest,
and then perhaps simplify the methods of interest for those classes; so,
sort of like a regular browser, but with just some classes and then for
these classes, just some methods. It might be nice to drag and drop to this
browser from regular browser. One might also have prepared class/method sets
for newbies to use (hiding much of the system complexity); LearningWorks had
some ideas along this line of hiding complexity in the debugger (not showing
new programmers some intermediate methods).

Or even easier, what I think I would like is another panel on a regular
browser which keeps a method viewed history in chronological order, so as I
look at methods they show up in the list (Class and name) and I can just
click in that list to make the browser go back and forth to that method
(including being able to open a new browser on the method with a double
click?). But I wonder if I have seen that somewhere too? Or maybe I have
just wanted it for so long? :-) The FireFox web browser can have a side bar
which can do that. Maybe that is what I am thinking of?

--Paul Fernhout
(*) While I thought it was a good idea at the time to try, PataPata's
hierarchical browser (which was *not* fully Self-like, Self-s was much
better) became very confusing lumping everything into a big hierarchical
inspector (although you could have more than one). Using it entailed lots of
scrolling where you could easily lose your place in lots of clutter. That
clutter came in part from mixing variables and methods, but also from mixing
classes and instances (since it was a Prototype-based system and there was
no clear difference). I also learned I did not like Self's choice (which I
had followed) of merging separate method and variable namespaces (of
Smalltalk) into one common one where any variable could be method. If you
separate classes and instances there would not be so much clutter. I tried a
wonderful browser for an prototype-ish extension to TCL that did a good job
of supporting mixing prototypes/singeltons and classes using a browser
desing which looked more Smalltalk-ish:
  "XotclIDE"
  http://wiki.tcl.tk/2131
"Integrated interactive development environment for the XOTcl extension (but
supports also regular Tcl programs). Provides a Smalltalk like graphical
programming environment (ENVY, Squeak, Visual Works) with graphical
introspection and editing of a running system. It supports also normal Tcl
procs and packages. State can be saved in the form of Tcl packages. Can
optionally use a sql-based version control system ..."
  "XOTclIDE. Integrated Development Environment for XOTcl and Tcl"
  http://www.xdobry.de/xotclIDE/

Francisco Garau wrote: