@jportway
There are two issues:
- Some things are difficult to implement (a few may be possible though)
- Some things don’t really seem that useful in practice. I think most people ask for them because they come from another language and are used to the workflow of that language (which may be suboptimal for Mathematica)>
Overall, I think it would be useful to get feedback from users like you not only about what they want, but also why they want it.
This is why I asked for more details on why you find debugging painful.
However, to be realistic, debugging would be prohibitively difficult to implement without documentation ...
The other two things were:
- REPL. I don’t see how this is useful in practice.
- "Run package.” The the Workbench this just auto-loads the package in a notebook. I can do that manually by evaluating a single cell, so I don’t see any value in it.
That said, I am sure that there are multiple use cases that I did not think of or that never come up for me personally but may come up for you.
That’s why I asked for more information.
Will try to make minimal example later
Please open an issue for that.
Also, there might be a difference if you use absolute URLs like
https://github...
[[nested/path]] does not work and direct links open in a new tab
I'm not sure we had nested content but the links to internal md pages definitely open in the same tab for me.
I want to keep'em organized in a nested directory structure
Files, not the sidebar content (yet).
I don't know without trying.
I'm not sure if I'm doing something wrong or there's a bug here (I only just discovered the proper module structure set-up in order for cross-module linking to work)... I have a project with two modules, module B is dependent on module A. Module A uses the same context (MyContext) in two different files MyContextComputation.m and MyContextObject.m. They both have a public section where they declare the usage messages of functions defined in those files. In Module B, functions defined in MyContextComputation.m correctly get underlined as coming from a different file but the functions defined in MyContextObject.m get a wriggly line with "Could not resolve symbol definition". I think the way I have it structured is not entirely unusual (although I don't know if having non-private contexts in multiple files is standard or not). Is this a known limitation, anything else I should try to tickle some indexing or similar?
And I figured out the first question too -- the two different files thing is a red herring. In the MyContextComputation file I don't have explicit
symbol::usage = ... settings, I've factored it out into a addUsageMessage[symbol, "substring used in a template"] because I have quite many very similarly structured functions and I wanted a nice long usage message for all of them. And I guess the linking relies of this symbol::usage = ... line, yes?
@gerli To give some context: It's not possible to do correct resolving of symbols because for that, one would need to evaluate the code. Only when the kernel runs the code, we can be certain which symbols resolves to which definition. This is not possible in the IDE and we need to make crude assumptions to get a practical solution. Even getting the context of a symbol right is tricky at best and impossible in other cases.
What the plugin does is looking for
symbol::usage = as you have correctly determined. This leads to the following things- You need to give a symbol a usage message if you want it to be found in a different file
- Since I'm not checking the context where a symbol lives, you can also give private symbols a usage message and it will be found in a different package. So you have to be careful to import the correct context.
- If you have symbols that don't do anything (think of
NodeorLeafin a tree) and IDEA warns you that it doesn't find a "definition", you can simply give it a usage message to make it resolve (which is both good programming style and informative for people reading your code)
Whether I defined this with or without full context in
knownSymbols.m, it’s not recognized when written with full context inMATLink.m
This is from a discussion in October. I'm stumbling on this same issue -- symbols that I reference with their full context (usually because of pulling in symbols from a private context of some file) don't get the linking, even if I add a usage message explicitly with the full context. Should I create a bug report for it?
@gerli No need for a bug-report, because I'm aware of this and unfortunately, it's exactly where reality hits the hardest. To be specific: If you enter
Foo`bar`fun[3] then of course the plugin knows that you mean fun in the context Foo`bar` . However, at the position where you defined fun[x_]:=.. inside your package, I would need to evaluate the whole code to find that when the symbol fun is put into the symbol-table, it is put into the context Foo`bar` .
Also, the new style package format makes this entirely hidden from the user and the rules what is done to
$Context and $ContextPath during loading of a file changed with the Mathematica version.
myContext = "C" <> ToString[1 + 1] <> "`";
Begin[myContext];
var = 3;
End[]
While this example is extreme and no one would do this in practice, we have similar things all over the place that might look innocent at first. Consider for instance the commonly used idiom
If[isMessageDefined, func::usage = "blub"]
which is often used at the top of packages. Evaluating the
If and knowing that the usage message of func is defined makes all the difference between exporting a symbol from a package.