Per-project / per-directory set of macros

[janpipek]

Ok, I agree that I am now being a bit greedy and want more and more fancy stuff, but this could actually help :-) I am working on a few separate projects, each of them having a different set of commands. It would be nice if working on them I could use different command trees in parallel.

Is that feasible? Or even possible?

[natl]

It's quite possible by having a local completions.json file in the root directory of your project, which atom could look for before defaulting back to the main completions.json that ships with the package. For example, https://atom.io/packages/linter-gcc lets you specify project specific settings in a JSON file.

I would advocate a different approach however, which is to chain your G4command.txt files together, just adding the new command directories that you add particular to each project.

A nice thing would be to do this more automatically via maybe saying:

python process_commands.py --add-file new_commands.txt

What do you think?

[janpipek]

I am not sure if I understand what is your "different" approach. So I cannot really say what I think :-)

Anyway, if Python-related work is necessary, I may contribute. I just don't have time / mental capacity to start learning CoffeeScript now.

[natl]

You're right, I can explain it better. Essentially process_commands.py builds a JSON data structure that is read by Atom.

There are two functions in process_commands.py, read_command_file and recurse_dictionary.

First, read_command_file is run. This takes every command and puts them in a huge dictionary. Each key is the entire path of the command, so the dictionary looks a little like this:

{"gps/ang/dist": [stuff], "gps/ang/theta1": [other stuff]}

There is no hierarchy to the commands.

Secondly, recurse_dictionary is run on the dictionary, repeatedly, breaking down each command into it's proper subdirectories.

The idea would be to change process_commands.py to function in a new way, that accomodates multiple G4command.txt files. Suppose I have ten projects, then I would make project1commands.txt, project2commands.txt etc.

I would then run: python process_commands.py project1_commands.txt project2commands.txt ...

This would run read_command_file on the ten files, producing ten dictionaries. These could be combined, overwriting commands that are the same.

Then a JSON file would contain all the completions necessary for all 10 projects, provided they had a consistent naming scheme amongst their macro commands. I personally prefer this approach, as I like all the completions being in the same place. But you might feel differently, let me know...

[janpipek]

Aaah. Thanks for the explanation. Now I understand the intention.

The combination will of course work (dict.update() to the rescue). I thought on the other hand, that my workspace would be somewhat cleaner without "/otherProject/doSomething"-like commands being suggested. But I agree this is a bit more difficult to achieve and unless it's really necessary, it's perhaps not worth the effort.

[natl]

Yeah, dict.update() is the right method there, good call. I get what you're saying about having a clean workspace, but at the same time, adding that functionality makes using the actual plugin more complicated.

I'm imagining a situation where your build directory isn't always in the same hierarchy as your project, and then Atom can't find the correct completions, or where you might be editing macro files from multiple projects in one editor (because typically, only one set of autocompletions is used per editor window).

There are likely ways to get around that, one way is to specify the location of the correct autocompletions in each file (via a comment line at the start, like #autocomplete:/path/to/file.json, but it still seems clunky. What do you think?

[janpipek]

Aaah, seems you're right. I am a build-in-the-source-tree guy (and consequently be-careful-what-you-commit headache victim) so typically I am not confused about which macros are relevant where but in that, I probably belong to a minority. In principle, you never who needs what :-)

The #autocomplete:../path is a good idea (especially if relative path is enabled) but perhaps quite a lot of work...

Maybe just forget about it completely before your user base grows :-)

[natl]

I'm going to close this issue for now, but might consider the #autocomplete:/path/to/file method later. Shouldn't be too much work, but I don't like it all that much compared to something that works every time uniformly. The main thing to do is tinker with the activation settings in the package to keep everything local to each editor tab (I think).