On 04/03/2011 05:57 PM, Hans-Christoph Steiner wrote:

Wow, I love the tab autocompletion plugin! What would be amazing if we had a bash-style completion files were the arguments were also tab-completable, when relevant. Things like filenames, table/array names, send/receive names, etc. This completion file could be included in libraries. It really highlights how badly we need Enter/Return to instantiate the object.

Personally I prefer the default tcsh/bash-style where tab doesn't cycle thru the options when you hit tab repeatly. I could see a bash/tcsh style display of the options, like in a popup when you hit tab repeatedly.

hey thanks. I'm not really supposed to dedicate that ammount of time developping for pd but as I'm unemployed right now =) I'm afraid the bash style auto-completion is a bit above my head, but the idea is nice.

One thing that needs to happen to make the auto-complete plugin more deployable is to have all its procs in its own namespace. Otherwise there can easily be name conflicts with other things named 'init', 'trigger', etc.

done

(FYI: sending to pd-announce also sends to pd-list)

okay

cheers, _y

On 04/03/2011 06:44 PM, Hans-Christoph Steiner wrote:

On Apr 3, 2011, at 12:12 PM, yvan volochine wrote:

...

On 04/03/2011 05:57 PM, Hans-Christoph Steiner wrote:

...

Wow, I love the tab autocompletion plugin! What would be amazing if we had a bash-style completion files were the arguments were also tab-completable, when relevant. Things like filenames, table/array names, send/receive names, etc. This completion file could be included in libraries. It really highlights how badly we need Enter/Return to instantiate the object.

Personally I prefer the default tcsh/bash-style where tab doesn't cycle thru the options when you hit tab repeatly. I could see a bash/tcsh style display of the options, like in a popup when you hit tab repeatedly.

hey thanks. I'm not really supposed to dedicate that ammount of time developping for pd but as I'm unemployed right now =) I'm afraid the bash style auto-completion is a bit above my head, but the idea is nice.

Basically, the first is the trigger: hitting tab twice where the tab does not add any more characters. So using your plugin as an example, type M-O-Tab-Tab would then list 'mod' and 'moses' as options but not change the 'mo' in the box. Those options could then be in a popup menu to both see and select with the keyboard or mouse.

yeah that's what I wanted first: a ComboBox below the object box, but then I had troubles with object box coordinates (did the user click or is the object still moving with the cursor, etc...) and I started adding some "if" and all kind of stuff inside mouse motion procedures and that became nasty. this (and the fact that I wanted it now =) made me rewrite the plugin with the "cycling-through-completions-with-tab" behavior (which I still find very cool for speedy-patching)

cheers, _y

Adding the argument completion would probably be a lot more work, but I haven't really thought about it. But just having object name completion is huge!

.hc

...

...

One thing that needs to happen to make the auto-complete plugin more deployable is to have all its procs in its own namespace. Otherwise there can easily be name conflicts with other things named 'init', 'trigger', etc.

done

...

(FYI: sending to pd-announce also sends to pd-list)

okay

cheers, _y

---

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

On Apr 3, 2011, at 12:53 PM, yvan volochine wrote:

On 04/03/2011 06:44 PM, Hans-Christoph Steiner wrote:

...

On Apr 3, 2011, at 12:12 PM, yvan volochine wrote:

...

On 04/03/2011 05:57 PM, Hans-Christoph Steiner wrote:

...

Wow, I love the tab autocompletion plugin! What would be amazing
if we had a bash-style completion files were the arguments were also tab-completable, when relevant. Things like filenames, table/array names, send/receive names, etc. This completion file could be
included in libraries. It really highlights how badly we need Enter/Return
to instantiate the object.

Personally I prefer the default tcsh/bash-style where tab doesn't
cycle thru the options when you hit tab repeatly. I could see a bash/tcsh style display of the options, like in a popup when you hit tab repeatedly.

hey thanks. I'm not really supposed to dedicate that ammount of time developping for pd but as I'm unemployed right now =) I'm afraid the bash style auto-completion is a bit above my head,
but the idea is nice.

Basically, the first is the trigger: hitting tab twice where the tab does not add any more characters. So using your plugin as an example, type M-O-Tab-Tab would then list 'mod' and 'moses' as options but not change the 'mo' in the box. Those options could then be in a popup
menu to both see and select with the keyboard or mouse.

yeah that's what I wanted first: a ComboBox below the object box,
but then I had troubles with object box coordinates (did the user
click or is the object still moving with the cursor, etc...) and I
started adding some "if" and all kind of stuff inside mouse motion
procedures and that became nasty. this (and the fact that I wanted it now =) made me rewrite the
plugin with the "cycling-through-completions-with-tab" behavior
(which I still find very cool for speedy-patching)

I think many people prefer this kind of auto-complete, or at least it
is not uncommon. So its good to have no matter if there is a bash- style plugin or not.

I'm trying to think if there is a way to keep or get the coordinates
of the object itself. On the C-side there is, plus when an object is
created or edited then the GUI knows the location of it. Here's how,
in your pdtk_text_editing, you just need to query the coords of the
active text widget. This is a rough attempt that just gets a menu
popping up:

proc pdtk_text_editing {mytoplevel tag editing} { set tkcanvas [tkcanvas_name $mytoplevel] set rectcoords [$tkcanvas coords ${tag}R] if {$rectcoords ne ""} { set x [expr int([lindex $rectcoords 0])] set y [expr int([lindex $rectcoords 1] - 20)] pdtk_post "currently editing at: $x $y\n" if {! [winfo exists .completepopup] } { menu .completepopup .completepopup add command -label mod -command bell .completepopup add command -label moses -command bell } tk_popup .completepopup $x $y } if {$editing == 0} { selection clear $tkcanvas # auto-completion set ::completions {} set ::new_object false set ::lock_motion false set ::cycle false } { set ::editingtext($mytoplevel) $editing # auto-completion set ::new_object $editing } $tkcanvas focus $tag }

.hc

cheers, _y

...

Adding the argument completion would probably be a lot more work,
but I haven't really thought about it. But just having object name
completion is huge!

.hc

...

...

One thing that needs to happen to make the auto-complete plugin
more deployable is to have all its procs in its own namespace. Otherwise there can easily be name conflicts with other things named 'init', 'trigger', etc.

done

...

(FYI: sending to pd-announce also sends to pd-list)

okay

cheers, _y

---

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

Mistrust authority - promote decentralization. - the hacker ethic