HenriAugusto / completion-plugin

Completion for Pure Data
BSD 3-Clause "New" or "Revised" License
19 stars 1 forks source link

Plugin gets buggy when found through 2 search paths #25

Open sevdh opened 4 years ago

sevdh commented 4 years ago

I've tested completion 0.47.0-test1 with the just released Pd 0.50.0 and come accross a new problem. The first time of using completion it gives the right list of objects containing the already typed characters. The second or third time of using completion it doesn't generate the correct list and gives a list with all installed objects...

HenriAugusto commented 4 years ago

I can't see to reproduce the issue. Can you give a step-by-step guide?

What system are you on?

sevdh commented 4 years ago

I'm on macOS 10.14.6

I have updated the completion plugin via Deken. There could maybe some traces left from the previous install?

When I load Pd I see the following in the Pd window:

[completion-plugin] version 0.47.0-test1 [completion-plugin] finished scanning externals [completion-plugin] loaded 3194 completions in 210 milliseconds 'completion-plugin.tcl' already loaded, ignoring: '/Users/edwinvanderheide-user/Documents/Pd/externals/completion-plugin/completion-plugin.tcl'

Should the last line indeed be there?

I launch Pd, open a new window with Command+n, I place a new object with Command+1, I type 'sf' in the object and press Command+space. From the list I choose writesf~ by clicking on it and click outside of the object to finish the object creation. Afterwards I place another new object with Command+1, I type 'play' in the object and press Command+space. Now I get a list with, i suppose, all the installed objects including for example links to the completion plugin settings:

Screenshot 2019-08-22 at 06 31 53

Sometimes the effect occurs after placing the second object and sometime it only occurs after placing the third object. I haven't experienced it but maybe there are situations where it starts to happen later...

This is the contents of the plugin folder:

Screenshot 2019-08-22 at 06 50 33

These are my settings:

# ===== Completion Plugin =====

# you can change this settings on this file but it is recommended to use the plugin menu while using PD

# hotkey for bringing the completion window.
# for syntax check:
# https://www.tcl.tk/man/tcl8.4/TkCmd/bind.htm
# some examples: "Tab", "Control-Alt-space", "Control"
hotkey Control-space

# maximum lines shown in completion window
max_lines 20

# completion font family
font DejaVu Sans Mono

# fontsize (it usually looks bigger in the completion window so you might need to use a smaller size here)
font_size 12

# The max depth the plugin will scan for externals when descending a folder tree.
max_scan_depth 1

# Auto complete library names. Example:
# On:  "[list-abs/list-compare]"
# Off: "[list-compare]"
auto_complete_libs 1

# ===== Colors =====

# selected completion background color (the color used in the current selected element)
bg #0a85fe

# selected completion background color in the skipping search
skipbg #0ad871

# selected completion background color in the monolithic search
monobg #9832ff

# selected completion foreground color
fg white

# ===== Positions =====

# (vertical) offset for the popup position
# this can be needed if your window manager removes title bar (like awesome, etc)
offset 0
HenriAugusto commented 4 years ago

'completion-plugin.tcl' already loaded, ignoring: '/Users/edwinvanderheide-user/Documents/Pd/externals/completion-plugin/completion-plugin.tcl'

It do have two plugin copies. How you've installed the plugin the first time?

Maybe you've installed manually the first time in one folder. Then, this time, deken installed it in another folder so you've ended up with two copies.

I've tested having two copies, each in different folder, and i've managed to reproduce this bug. Also the leftovers bug1, bug2 bug3 are not included in the 0.47 plugin version so the folder you've posted in the screenshot is an older one.

I'm not sure why it happens when you have two copies because PD should be able to ignore the second plugin but still, this bug doesn't happens with only one copy, at least for me.

I recommend having only a single folder to put all your externals (like C:\pd-externals) and using this as your only custom defined path for PD. Then be sure to instruct Deken to install stuff in that folder.

HenriAugusto commented 4 years ago

Do a system-wide search for files named completion-plugin.tcl. Keep only the fodler that doesn't contain the "bug1,bug2, bug3" files

Let me know how it works after removing the duplicate folder.

sevdh commented 4 years ago

I have used the Find Any File application to search my drive and there is only one completion-plugin.tcl file on my computer. It’s in /Users/edwinvanderheide-user/Documents/Pd/externals/completion-plugin

I’ve installed the previous version either through Deken or manually (I’m not quite sure but I think it was through Deken).

I’ve updated to the latest version using Deken.

I’m attaching my completion-plugin folder and screenshots of my path and startup settings. Maybe it is occurring because I have both /Users/edwinvanderheide-user/Documents/Pd/externals and /Users/edwinvanderheide-user/Documents/Pd/externals/completion-plugin in my path?

On 22 Aug 2019, at 16:51, Henri Augusto notifications@github.com wrote:

Do a system-wide search for files named completion-plugin.tcl. Keep only the fodler that doesn't contain the "bug1,bug2, bug3" files

Let me know how it works after removing the duplicate folder.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HenriAugusto/completion-plugin/issues/25?email_source=notifications&email_token=AEBMOIHOBR2TJ365BKENNK3QF2RYHA5CNFSM4INWDTGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD45LCPY#issuecomment-523940159, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBMOIEYRU7TEUFY5TY5W7TQF2RYHANCNFSM4INWDTGA.

sevdh commented 4 years ago
Screenshot 2019-08-22 at 21 34 21 Screenshot 2019-08-22 at 21 36 40

completion-plugin.zip

HenriAugusto commented 4 years ago

Yes, PD is finding the plugin twice because it finds it after searching those two paths

/Users/edwinvanderheide-user/Documents/Pd/externals/
/Users/edwinvanderheide-user/Documents/Pd/externals/completion-plugin

That is why i always recommend having only a single search path set.

/Users/edwinvanderheide-user/Documents/Pd/externals/ in your case. Then just put all your stuff there. And if Deken ask if you wanna add something to the search paths just don't let it.

Anyway if you don't want use the single path for any reason to solve your problem you still need to delete one of the paths.

sevdh commented 4 years ago

I see that I’ve been using the search path wrongly!!! In my case it means that PD would find all the other libraries twice as well… Somehow it is the first time run into this problem and it is an easy mistake to make if you don’t know what to click when Deken asks this question. I'm happy the problem is solved for me! I think it would be great if the plugin could be made resistant for this because I guess I’m not the only one with overlapping search paths. Thanks a lot for helping me out!

On 22 Aug 2019, at 22:05, Henri Augusto notifications@github.com wrote:

Yes, PD is finding the plugin twice because it finds it after searching those two paths

/Users/edwinvanderheide-user/Documents/Pd/externals/ /Users/edwinvanderheide-user/Documents/Pd/externals/completion-plugin That is why i always recommend having only a single search path set.

/Users/edwinvanderheide-user/Documents/Pd/externals/ in your case. Then just put all your stuff there. And if Deken ask if you wanna add something to the search paths just don't let it.

Anyway if you don't want use the single path for any reason to solve your problem you still need to delete one of the paths.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HenriAugusto/completion-plugin/issues/25?email_source=notifications&email_token=AEBMOIAVYG3D3MSKXRNNVPLQF3WRDA5CNFSM4INWDTGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD46HSLQ#issuecomment-524056878, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBMOIEM33TMDMWICKIROYTQF3WRDANCNFSM4INWDTGA.

HenriAugusto commented 4 years ago

Yeah, there were always confusion regarding PD searchpaths in our community. It's not something only you did.

Anyway i currently have no idea how this bug is happening.

The relevant plugin-loading code is in load_plugin_script and load_startup_plugins.

Here's a reduction of what the relevant code on thoses procs looks like (some lines were ommited and are marked with [...] )

proc load_startup_plugins {} {
    [...]
    # load other installed plugins
    foreach pathdir [concat $::sys_searchpath $::sys_temppath $::sys_staticpath] {
        set dir [file normalize $pathdir]
        if { ! [file isdirectory $dir]} {continue}
        foreach filename [glob -directory $dir -nocomplain -types {f} -- \
                              *-plugin/*-plugin.tcl *-plugin.tcl] {
            set ::current_plugin_loadpath [file dirname $filename]
            load_plugin_script $filename
        }
    }
}
proc load_plugin_script {filename} {
    global errorInfo

    set basename [file tail $filename]
    if {[lsearch $::loaded_plugins $basename] > -1} {
        ::pdwindow::post [_ "'$basename' already loaded, ignoring: '$filename'\n"]
        return
    }
   [...]
}

I'm not sure what the following line does in load_startup_plugins

set ::current_plugin_loadpath [file dirname $filename]

but it seems to only be used by deken on pd_deken.tcl

if { "" != "$::current_plugin_loadpath" } {
    ::pdwindow::debug [format [_ "\[deken\] deken-plugin.tcl (Pd externals search) loaded from %s." ]  $::current_plugin_loadpath ]
    ::pdwindow::debug "\n"
}

So, in theory, nothing should change...hmm

sevdh commented 4 years ago

Another thought: would it be possible that the problem is not the plugin loading twice but that the scan of the completion plugin get’s somehow confused/corrupted because of the overlapping paths?

On 22 Aug 2019, at 23:05, Henri Augusto notifications@github.com wrote:

Yeah, there were always confusion regarding PD searchpaths in our community. It's not something only you did.

Anyway i currently have no idea how this bug is happening.

The relevant plugin-loading code is in load_plugin_script https://github.com/pure-data/pure-data/blob/8bc046e972a30eadf1eadea609e9d34426c496ee/tcl/pd-gui.tcl#L747 and load_startup_plugins https://github.com/pure-data/pure-data/blob/8bc046e972a30eadf1eadea609e9d34426c496ee/tcl/pd-gui.tcl#L770.

Here's a reduction of what the relevant code on thoses procs looks like (some lines were ommited and are marked with [...] )

proc load_startup_plugins {} { [...]

load other installed plugins

foreach pathdir [concat $::sys_searchpath $::sys_temppath $::sys_staticpath] {
    set dir [file normalize $pathdir]
    if { ! [file isdirectory $dir]} {continue}
    foreach filename [glob -directory $dir -nocomplain -types {f} -- \
                          *-plugin/*-plugin.tcl *-plugin.tcl] {
        set ::current_plugin_loadpath [file dirname $filename]
        load_plugin_script $filename
    }
}

} proc load_plugin_script {filename} { global errorInfo

set basename [file tail $filename]
if {[lsearch $::loaded_plugins $basename] > -1} {
    ::pdwindow::post [_ "'$basename' already loaded, ignoring: '$filename'\n"]
    return
}

[...] } I'm not sure what the following line does in load_startup_plugins

set ::current_plugin_loadpath [file dirname $filename] but it seems to only be used by deken on pd_deken.tcl https://github.com/pure-data/pure-data/blob/8bc046e972a30eadf1eadea609e9d34426c496ee/tcl/pd_deken.tcl#L473 if { "" != "$::current_pluginloadpath" } { ::pdwindow::debug [format [ "[deken] deken-plugin.tcl (Pd externals search) loaded from %s." ] $::current_plugin_loadpath ] ::pdwindow::debug "\n" } So in theory nothing should change...hmm

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HenriAugusto/completion-plugin/issues/25?email_source=notifications&email_token=AEBMOIBXFM6BXGT2U54EB23QF35QDA5CNFSM4INWDTGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD46MRIY#issuecomment-524077219, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBMOIASLT3PJFMUL4WL7ITQF35QDANCNFSM4INWDTGA.

HenriAugusto commented 4 years ago

That is the issue. Looking at the load_plugin_script and load_startup_plugins functions i can't find anything wrong.

The line that loads the plugin is not called when the code detects the plugin is already loaded

[catch {uplevel #0 $tclcode} errorname]

Of course I'm missing something but, currently, i don't know where to look.

HenriAugusto commented 4 years ago

Through issue #30 'ive realized that the plugin is actually using the ::current_plugin_loadpath variable!

Interestingly:

  1. the plugin reads it on initialization, which souldn't be a problem.
    • it reads the .cfg file
    • uses this path to find the objects located in custom_completions and monolithic_objects folders
  2. the plugin reads it at run-time which might be a problem
    • but it only does when opening the help file and writing to the config file.

So while it opens the chance for chaos by reading this variable i don't see how it can affect the search routines, even if somehow we wrote the config file to the wrong place.

Moreover i've tried reproducing this issue again with the plugin v0.47.0 and couldn't. Maybe it was somehow related to #26 ?

sevdh commented 4 years ago

v0.47.0 gives still the same issue for me. I’ll do more testing.

On 10 Sep 2019, at 16:17, Henri Augusto notifications@github.com wrote:

Through issue #30 https://github.com/HenriAugusto/completion-plugin/issues/30 'ive realized that the plugin is actually using the ::current_plugin_loadpath variable!

Interestingly:

the plugin reads it on initialization, which souldn't be a problem. it reads the .cfg file uses this path to find the objects located in custom_completions and monolithic_objects folders the plugin reads it at run-time which might be a problem but it only does when opening the help file and writing to the config file. So while it opens the chance for chaos by reading this variable i don't see how it can affect the search routines, even if somehow we wrote the config file to the wrong place.

Moreover i've tried reproducing this issue again with the plugin v0.47.0 and couldn't. Maybe it was somehow related to #26 https://github.com/HenriAugusto/completion-plugin/issues/26 ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HenriAugusto/completion-plugin/issues/25?email_source=notifications&email_token=AEBMOIFBL2AMJMOW2RKQL3TQI6UBJA5CNFSM4INWDTGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6LIA2Q#issuecomment-529956970, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBMOIDYDPQQKHL47674FZTQI6UBJANCNFSM4INWDTGA.