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