[PD-dev] PD AutoComplete Plugin

[Henri Augusto Bisognini]

On 2018-06-11 05:21, IOhannes wrote:
> ithink it is one of max's most cumbersome "inventions", and actively hinders patching.

I've never been a Max user. I've only experimented with it twice at a studio but nothing more.

Why it is cumbersome and hinders patching?


Anyway this plugin only activates if you say so because you must trigger the auto completion with the Tab key :)


On 2018-06-11 05:21, IOhannes wrote:
> otoh, it is of course a nice way for beginners to get an overview over existing objects.


It also allows for really fast typing and automatically types the library names for you. You can very quickly type long stuff like


list-abs/list-unitvec
zexy/0x3d0x3d0x7e
list-abs/list-geometric-mean
mrpeach/packOSCstream

thus encouraging use of "namespaces", which facilitates good patching practices because it avoids name collisions and also allows for easy finding missing dependencies. Such "namespace" use is not something i see everyday even in some experienced user's code.


On 2018-06-11 05:21, IOhannes wrote:
> but anyhow, a very brief glance at the code shows, that the plugin draws
> its knowlege about auto-completion from hardcoded lists.
> i think it this is plainly the wrong approach, instead that knowledge
> should be gathered on-the-fly from the list of currently available classes.


It only reads a hard-coded list for vanilla objects, which is faster and very easy to maintain (and its only a 2kb increase in file size)


For all other externals it reads the $::sys_staticpath and $::sys_searchpath variables to get the PD paths


and then intelligently scans .pd files (skipping -help.pd ones) and system dependent files (.dll, pd_linux, pd_darwin) for each path.


The only thing it can't do is to read inside those sys dependent files to know what objects are there inside monolithic libraries, like zexy. For that reason it reads a .txt file that the user can set that contains that information. Something like:

[...]
zexy/atoi
zexy/demultiplex
zexy/demux

[...]
hoa/hoa.2d.decoder~
hoa/hoa.2d.encoder~
[...]

You can find them separately using a special "monolithic search mode" that displays the library name on the completions list but only auto completes the object name (since you can't use namespaces with those).


It would definitely be better to communicate with pd directly to query those objects. Is that possible for a GUI plugin?



About it running on slow computers like Raspberry Pis. What exactly would be the the problem? Processing or memory?

Right know the plugin only increases 424kb in RAM usage on my windows computer and i have a reasonable amounts of externals.


About processing power: on startup it scan the externals. Afterwards it will only act if the user press the Tab key to trigger the auto completion.


Cheers,

Henri.

________________________________
De: Pd-dev <pd-dev-bounces at lists.iem.at> em nome de IOhannes m zmoelnig <zmoelnig at iem.at>
Enviado: segunda-feira, 11 de junho de 2018 05:21
Para: pd-dev at lists.iem.at
Assunto: Re: [PD-dev] PD AutoComplete Plugin

congrats to the re-surrection of the plugin.

On 2018-06-10 03:07, Alexandre Torres Porres wrote:
> OMG, this HAS to be part of the vanilla distribution!

however: personally, i am not very sure about this.
ithink it is one of max's most cumbersome "inventions", and actively
hinders patching.

otoh, it is of course a nice way for beginners to get an overview over
existing objects.

so i'm not trying to say that the plugin is a bad-idea in the first
place, but rather rejecting the notion of "OMG, MUST".


but anyhow, a very brief glance at the code shows, that the plugin draws
its knowlege about auto-completion from hardcoded lists.
i think it this is plainly the wrong approach, instead that knowledge
should be gathered on-the-fly from the list of currently available classes.

but of course, i haven't even tested the plugin, so this might already
be happening (and the hardcoded lists might be either left-overs or
additional hints).


fgmasdrt
IOhannes

PS: and my understanding of the legalese is pretty close to dan's.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20180611/f30afe6e/attachment-0001.html>