Re: [Help-smalltalk] Keysym Fix and Transcript Keybindings

[Paolo Bonzini]

> [snip]

Your code is very interesting.  I would very much like to receive a patch
for it.  The next step, then would be to evaluate do-its in a separate
process (leaving the Transcript process waiting on a semaphore), so that you
can interrupt them with another key-binding (sending the UserInterrupt
exception to the other process with #queueInterrupt: maybe).

>   doLine
>       "Select the current line, exec it, and deselect."
>       | endPt |
>       endPt := Point x: 1 y: blox currentLine.
>       blox selectFrom: (Point x: 1 y: (blox currentLine - 1)) to: endPt.
>       self eval.
>       blox selectFrom: endPt to: endPt

doLine
    | endPt |
    endPt := 1 @ blox currentLine.
    blox selectFrom: 1 @ (blox currentLine - 1) to: endPt.
    self eval.
    blox selectFrom: endPt to: endPt

> It might be worthwhile to add other keybindings, specifically for Accept
> in the browser.  And perhaps Ctrl-1 through Ctrl-3 for opening a
> Worksheet, the Class Browser, and the Namespace Browser respectively.

Yes.

> Unfortunately, BLOX passes through the Return _before_ #doLine is called,
> which means I have to have my cursor positioned at the end of the line for
> #doLine to function.  Is there a way to prevent BLOX from reading the
> Return in the Ctrl-Return sequence?

The problem is in Tk, as all that Blox does is doing the mangling in
#getKeyPressEventName:.  I don't know if it is a bug -- ask on a newsgroup.

> I'd like to be able to hit doLine at
> the beginning, middle, or end of a line, eventually.  (But I'd also like
> to keep the binding as Ctrl-Return.)

As you probably know, the standard behavior of other Smalltalks is to check
if there is a selection and, if not, evaluate the current line.  I would not
mind another keypress (Ctrl+D/P/I for Do it, Print it, Inspect it for
example).

After Camp Smalltalk, I tried doing something with the Refactoring Browser
(thanks for the pointer about the test suites!).  2.0c has all of my work so
far. The bad thing is that the library does not work well at all with
namespaces (I should have got it from the very bad work they did with VW7 --
WRT namespaces I think that even GNU Smalltalk's Namespace Browser is easier
to use!).  I already tried using variable bindings instead of class names in
the BrowserEnvironments, and it passes the test suite (and to my surprise,
it was not very hard to do!).  I also introduced the VariableBinding
subclass of Association which knows about the namespace it lives in, it
probably makes the task of doing the same with RBClass etc. a bit easier.

Paolo