Python implementation using pybind11 and gobject introspection

[zalox]

[zalox]

Replaces #99

[zalox]

Working plugins here for now: https://github.com/zalox/jucipp-plugins

[zalox]

@milleniumbug Did you manage to test the plugins?

[milleniumbug]

Not yet, I'm trying to. The missing Py_DecodeLocale was the immediate issue that prevented me from compiling this branch.

[milleniumbug]

Ok, after installing necessary dependencies, setting site-packages in config.json to correct path, snippet.py works correctly, but tools.py doesn't seem to load at all. (Python version: 3.4)

Dependencies for Fedora 23: gobject-introspection-devel pygobject3-devel python3-gobject (posting here so I won't forget)

[zalox]

Are there no errors in the terminal?

[milleniumbug]

None at all. I've verified that it doesn't load by putting some logging statements in tools.py (with jucipp.terminal.println("test"))

[milleniumbug]

Okay, nevermind. Moving snippet.py outside and renaming tools.py to snippet.py loads the plugin, so probably I have forgotten to put it on some list.

[zalox]

@eidheim I'm having trouble persisting my config.json file. Is there any mechanism that overwrites the file or anything in it?

I had the issues in msys2.

[eidheim]

As long as you have the same version number in the config file, as in the files.h, juCi++ will not touch the config file. However, if the versions are different, changes will be done to the old config file so that it corresponds to the new file specified in files.h.

[zalox]

I had some very strange behaviour then. I'll try to reproduce when I get back to windows.

[eidheim]

Windows does some file lock if a file is opened by another process? That might have been the case, denying the write to you your config file. Although, I'm not very experienced with Windows.

[milleniumbug]

I've debugged the program, and it seems it stops searching for plugins on first hidden file.

/home/milleniumbug/.juci/plugins/snippet.py - full
snippet - stem
/home/milleniumbug/.juci/plugins/.gitignore - full
 - stem
/home/milleniumbug/.juci/plugins/__pycache__ - full
__pycache__ - stem
/home/milleniumbug/.juci/plugins/README.md - full
README - stem
/home/milleniumbug/.juci/plugins/LICENSE - full
LICENSE - stem
/home/milleniumbug/.juci/plugins/tools.py - full
tools - stem
/home/milleniumbug/.juci/plugins/.git - full
 - stem

Changing from

    auto module_name=it->path().stem().string();
    if(module_name.empty())
      break;

to

    auto module_name=it->path().stem().string();
    if(module_name.empty())
      continue;

fixed the problem.

[zalox]

@eidheim Would it be possible to hook up to the auto-complete dialog somehow? While looking through the source I can't see any simple way as is...

Use-case: Writing for would produce an auto-complete suggestion for a snippet as well as other completion data for for.

[zalox]

It might be possible to do it inClangViewAutocomplete::autocomplete_get_suggestions by asking i.e.Python::Interpreter::get_suggestions. The suggestions can be dynamically produced by clang context in plugins. If the interpreter and clang works in parallel I think it might work without a huge performance drop.

This approach isn't very generic and re-factoring might be needed for a reasonable solution.

[eidheim]

@zalox I've been thinking about simpler ways to reuse the autocompletion dialog. I'll prioritize this in the coming weeks.

[zalox]

I updated the docker images with python now. I only updated the packages, so it shouldn't break other builds. https://hub.docker.com/r/cppit/jucipp/builds/

[eidheim]

Coincidently, I'll test it on master now:)

[zalox]

https://github.com/cppit/jucipp-docker/commit/9cb5f6e2a5051342fc9b22439372ed9cb84c6c5f