Export symbol action

[kubaPod]

It takes some time to get to the top of the file, export a symbol and go back to editing it.

It would be nice to have a "Export Symbol" action that could put a symbol:

BeginPackage["MyPackage`"]

(*here*)

Begin["`Private`"]

[...]

I understand that not every .m file has this structure or that the plugin may not aware of it so I wouldn't give that feature a high priority. Just feels like something that could be used a lot, similarly to 'Localize variable'.

[szhorvat]

We would need to figure out:

• When does the simplest method to do this not apply? (E.g. packages split through files, "new style" packages, etc.)

• How to detect when it can't be done safely?

• In general, how to ensure that people won't inadvertently break things when trying to use this in a case when it doesn't apply?

[kubaPod]

• When does the simplest method to do this not apply? (E.g. packages split through files, "new style" packages, etc.)

I'd say the opposite, explain where it applies and expect users to think. At the end it won't be an automatic action.

For a start it could just assume a simple old style package.

More files? New style? Just don't use it, it is not for that.

• How to detect when it can't be done safely?

Probably, as I said, I don't know what the plugin knows about .m file structure.

• In general, how to ensure that people won't inadvertently break things when trying to use this in a case when it doesn't apply?

I'm not a fan of thinking too much for users. You can break things by renaming global symbols or localizing stuff that is a global symbol yet you can do this.

p.s. for a new style package it could be a separate action. Once multi file standard is described there could be an action for that as well. Maybe in future they could be combined but I'd not aim to high right now.

[szhorvat]

Based on my experience with other IDEs that messed up my code during refactoring, I would be extremely careful with adding a feature that has the potential to break your code in subtle and unexpected ways.

If the feature does not work (e.g. doesn't do anything) in many cases, or even most cases, that is not a problem at all.

But if "does not work" results in messing up my code, that's a problem. If there are cases where it messes up my code in ways that I might not immediately notice (e.g. when I'm tired and in a hurry), that's a very big problem.

So the question for me is not "does it work?" but "what exactly happens when it doesn't work?"

---

(And just to avoid misunderstandings, of course it would be a useful feature and of course I wished for this on multiple occasions.)

[kubaPod]

Here is an idea:
I don't know if that is possible or how much work would it be but I imagine that after using that action a prompt would show up with a slice of code where that symbol is going to be inserted and user would have to confirm/cancel that.

Something similar to when you hover on a closing bracket and it shows the opening if it is outside of current view range. Or like with search features.

[szhorvat]

More thoughts on this:

If this feature always inserts just a single line at the top level, that makes it a less risky action than other types of refactorings.

(There are many ways to implement this, e.g. one possibility is to move the ::usage to the export section. That would not only insert a line, but also delete one. That's more risky.)

[kubaPod]

For me a symbol is fine enough for me as I keep my messages next to implementation. (I ofc know that not everyone does this).