[PD] [PD-announce] completion-plugin new version

[yvan volochine]

On 05/27/2011 05:37 PM, Hans-Christoph Steiner wrote:
> It wouldn't be hard to code this in C, the question for me is what would
> the interface be, both in terms of coding in Tcl and the GUI itself.

I wouldn't spend too much time on this but rather move on and completely 
separate pd and its GUI so all these kind of GUI goodies would be a snap 
to add (my 0.02€).

> This plugin is really looking quite amazing. I am curious about the
> send/receive symbols in it. Does it use all s/r symbols that are active?
> That list could get quite long, but I guess that's what it is supposed
> to do.

alas no, I thought this would be the way to go until I realized that you 
can't access subpatches/abstractions objects (or can you?). therefore I 
decided to add to completion list any *new* s/r symbols (and same for 
table, throw~, etc). I designed this with a livecoding approach in mind.

> One little deployment suggestion: the 'extra_objects' folder is a good
> idea with auto-loading the text files, etc. I think it would be easiest
> if it just loaded any .txt file that was in 'extra_objects', then people
> could just drop their own custom ones in there without having to edit
> the completion-plugin.tcl. Then the add_libraries_externals loading
> logic could try loading a standard filename like completion.cfg from
> each of the loaded libraries. So anyone can add a 'completion.cfg' to
> their library, and it'll be loaded. Perhaps that's a bigger problem than
> should be tackled now, but I'm thinking it would be very nice, and not
> too hard to make the completion context aware, so that the completion
> list would be per-patch. I.e. taking into account [import mylib], etc.

the *.txt solution would be better indeed, but I won't have much time soon.
pull requests on my github are of course welcome ;)

being aware of [import] might be a bit too much as this plugin is rather 
hacky already.

cheers,
_y