Closed JonMcLoone closed 3 years ago
I often have sort of the opposite wish: just don't auto-add a closing comment, as it's more trouble than good. I know: I should get used to using the shortcut key for commenting out parts of the code (my most common use of comments). :-)
I have mixed feelings about auto-bracket closing anyway. I am not used to it so get more unwanted closes than I am being saved from missed closes. But with (*) the partial close is the worst of both worlds.
I actually prefer the Mathematica FE way of cmd-/ 'comment out the selection' rather then the IntelliJ 'comment out the line'. But that is wish-list not a bug.
On 09/04/2021 13:41, Szabolcs Horvát wrote:
I often have sort of the opposite wish: just don't auto-add a closing comment, as it's more trouble than good. I know: I should get used to using the shortcut key for commenting out parts of the code (my most common use of comments). :-)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/halirutan/Wolfram-Language-IntelliJ-Plugin-Archive/issues/180#issuecomment-816653987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3NEDVEVVCZEHB4WWEO7KTTH3YYLANCNFSM42UOUL6Q.
IntellIJ has not one, but two commenting shortcuts: one is for block comment, the other for line comment.
On my macOS system, the line comment is Cmd-/ and the block comment is Opt-Cmd-/
With Mathematica, "line comments" and what Cmd-/ does make no sense. This has been a long-standing annoyance for me, but I was too lazy so far to switch the keyboard shortcuts around. I think I am going to switch them over right now, so Cmd-/ does what I usually want (block comment).
Thank you. My life just got a little better!
Just for the record, the biggest thing for me will be when imported package symbols are supported and the "Could not resolve definition" go away.
On 09/04/2021 14:26, Szabolcs Horvát wrote:
IntellIJ has not one, but two commenting shortcuts: one is for block comment, the other for line comment.
On my macOS system, the line comment is Cmd-/ and the block comment is Opt-Cmd-/
With Mathematica, "line comments" and what Cmd-/ does make no sense. This has been a long-standing annoyance for me, but I was too lazy so far to switch the keyboard shortcuts around. I think I am going to switch them over right now, so Cmd-/ does what I usually want (block comment).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/halirutan/Wolfram-Language-IntelliJ-Plugin-Archive/issues/180#issuecomment-816680547, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3NEDVBGU2RU7RPCDDB7PDTH357LANCNFSM42UOUL6Q.
Just for the record, the biggest thing for me will be when imported package symbols are supported and the "Could not resolve definition" go away.
This is already supported, with limitations. One must add the location of the external packages to the project. Then all symbols in the external package which have a ::usage
message will be considered public. (At least, as I recall, currently usage messages are the only way that it identifies public symbols. I don't recall if PackageExport
without ::usage
is already supported. @halirutan ?)
Do you have any ideas about how else one may detect which symbols from a package are public, and which aren't? I remember we had multiple discussions about this with @halirutan and could not find any other way which is both simple and robust. While this method is not ideal, one advantage is that package authors can adapt to the behaviour of the IDE fairly easily, and add the missing usages. This is what I have been doing.
I am talking about external to the file but within the project.
IE with a file layout...
/Kernel
/init.m
/package1.m
/package2.m
And package 1 starts
BeginPackage["package1`",{"package2.m"}]
I get unknown markers on ever package2 symbol in the package1 source file.
I don't think its unreasonable to require usage messages for this to work.
The only thing that I can think of that doesn't require evaluating the code is to count symbol first use vs Begin and BeginPackage statements. Usage messages are only a convention for first-use.
If the symbol is first used after a BeginPackage but before a Begin, it is public. This won't help if they use fully qualified names or mess with $ContextPath, but they seem like corner cases. Something like ...
package =
ImportString[
"BeginPackage[\"mypackage\"];\n\ myfn::usage=\"somemessage\";Begin[\"
Private`\"];\nmyfn[x_]:=g[x]\n\
End[];\nEndPackage[]", {"Package", "HeldExpressions"}]
flat = Join @@ (package //. HoldComplete[a, fn[args__], b] :> HoldComplete[a, fn, args, b])
firstUse = DeleteDuplicates[flat]
removePrivate = firstUse //. HoldComplete[a, Begin, Shortest[private], End, b___] :> HoldComplete[a, b]
public = DeleteCases[DeleteCases[removePrivate, x_Symbol /; Context[x] === "System`"], _String | _Integer | _Real | _Complex]
On 09/04/2021 15:43, Szabolcs Horvát wrote:
Just for the record, the biggest thing for me will be when imported package symbols are supported and the "Could not resolve definition" go away.
This is already supported, with limitations. One must add the location of the external packages to the project. Then all symbols in the external package which have a |::usage| message will be considered public. (At least, as I recall, currently usage messages are the only way that it identifies public symbols. I don't recall if |PackageExport| /without/ |::usage| is already supported. @halirutan https://github.com/halirutan ?)
Do you have any ideas about how else one may detect which symbols from a package are public, and which aren't? I remember we had multiple discussions about this with @halirutan https://github.com/halirutan and could not find any other way which is both simple and robust. While this method is not ideal, one advantage is that package authors can adapt to the behaviour of the IDE fairly easily, and add the missing usages. This is what I have been doing.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/halirutan/Wolfram-Language-IntelliJ-Plugin-Archive/issues/180#issuecomment-816733989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3NEDTTGIZJ4Z7BJNZ4CF3TH4HC7ANCNFSM42UOUL6Q.
I get unknown markers on ever package2 symbol in the package1 source file.
Do you get that even for symbols which had a usage in package2? That should not happen. Within a project, all symbols with a usage should be considered defined, regardless of which file they are defined in.
I think we can call it an RTFM issue. Once, I knew it was supported I tracked it down to not having set the source folder in the Project Structure dialog. Not obvious, but the documentation was there for me to read!
On 09/04/2021 17:15, Szabolcs Horvát wrote:
I get unknown markers on ever package2 symbol in the package1 source file.
Do you get that even for symbols which had a usage in package2? That should not happen. Within a project, all symbols with a usage should be considered defined, regardless of which file they are defined in.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/halirutan/Wolfram-Language-IntelliJ-Plugin-Archive/issues/180#issuecomment-816793866, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3NEDXIBOTYUVSXN4OK2Q3TH4RYNANCNFSM42UOUL6Q.
I should add that I am VERY excited to have this working. Now the errors in the margin are useful and the last reason to miss Eclipse has gone!
On 09/04/2021 17:15, Szabolcs Horvát wrote:
I get unknown markers on ever package2 symbol in the package1 source file.
Do you get that even for symbols which had a usage in package2? That should not happen. Within a project, all symbols with a usage should be considered defined, regardless of which file they are defined in.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/halirutan/Wolfram-Language-IntelliJ-Plugin-Archive/issues/180#issuecomment-816793866, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3NEDXIBOTYUVSXN4OK2Q3TH4RYNANCNFSM42UOUL6Q.
Hey Jon,
as usual, my un-paid head of tech-support, Szabolcs, was already faster with answering :) Here is a quick list that hopefully helps and it assumes you're on Windows or Linux (Mac has slightly different shortcuts):
Ctrl
+Shift
+/
to get a new, empty (**)
with the cursor insideCtrl
+/
will comment the current line if there's something on itCtrl
+/
will comment out the lines that span the text and Ctrl
+Shift
+/
will comment out exactly your selection. Please note that you can easily select bigger code constructs.Ctrl
+ Shift
+ Enter
will jump to the next line and create a new comment with the cursor inside.Ctrl
+Space
. In an empty comment (**)
with the cursor inside, Ctrl
+Space
will suggest all the styling directives like ::Section::
You see there are a lot of one-hit shortcuts that allow you to work with comments and you basically never have to type the (*
yourself. As Szabolcs mentioned, we had quite some discussions about how much automatic intelligence we should put into the plugin and the general consensus was: Too much cleverness is often bound to break in specific situations, can be surprising and turns out to be annoying at times.
Associations are similar to typing comments, but the IntelliJ Platform provides much more things for comments. Association cleverness is implemented as Live Templates which means you simply type ass
, hit Tab
and a new <|...|>
we appear. With the next version of the plugin, the cursor will be placed between the brackets. Note how many of the standard constructs are supported by Live Templates and that you can also wrap selected code using Live Templates.
As Szabolcs already disclosed, you have to set up the project structure correctly to get the IDE to recognize symbols from other files. Although not much WL Plugin-specific documentation exists, this topic was indeed RTFM. Additionally, I need to stress that most language-unspecific features of IntelliJ IDEA also work with the WL Plugin and having a look at the IntelliJ IDEA Documentation can never harm. At least the Code Editing sections are a must. Note that you can switch the OS keyboard layout at the top-right of the page so that you always see the correct shortcuts. Things like column-selection mode, several cursors, jumping and navigating source code, etc. are a real breeze in IDEA. And if you ever run into a situation where you think that something appears as if there should be a better way, please just drop me a line. I'm always glad to help.
Thanks. Clearly I need to read more of the docs. Keep up the good work, what I have learned in the last day has settled the issue that this is now the recommended platform for my team.
On 10/04/2021 04:58, Patrick Scheibe wrote:
Hey Jon,
as usual, my un-paid head of tech-support, Szabolcs, was already faster with answering :) Here is a quick list that hopefully helps and it assumes you're on Windows or Linux (Mac has slightly different shortcuts):
Commenting
- Without any selection, you can always press |Ctrl|+|Shift|+|/| to get a new, empty |(**)| with the cursor inside
- Without any selection |Ctrl|+|/| will comment the current line if there's something on it
- With selected text, |Ctrl|+|/| will comment out the lines that span the text and |Ctrl|+|Shift|+|/| will comment out exactly your selection. Please note that you can easily select bigger code constructs https://www.jetbrains.com/help/idea/working-with-source-code.html#editor_code_selection.
- Inside a comment, |Ctrl| + |Shift|+ |Enter| will jump to the next line and create a new comment with the cursor inside.
- You can autocomplete function names in comments with |Ctrl|+|Space|. In an empty comment |(**)| with the cursor inside, |Ctrl|+|Space| will suggest all the styling directives like |::Section::|
You see there are a lot of one-hit shortcuts that allow you to work with comments and you basically never have to type the |(*| yourself. As Szabolcs mentioned, we had quite some discussions about how much automatic intelligence we should put into the plugin and the general consensus was: Too much cleverness is often bound to break in specific situations, can be surprising and turns out to be annoying at times.
Associations
Associations are similar to typing comments, but the IntelliJ Platform provides much more things for comments. Association cleverness is implemented as Live Templates https://wlplugin.halirutan.de/docs/live-templates/ which means you simply type |ass|, hit |Tab| and a new |<|...|>| we appear. With the next version of the plugin, the cursor will be placed between the brackets. Note how many of the standard constructs are supported by Live Templates and that you can also wrap selected code using Live Templates.
Final Notes
As Szabolcs already disclosed, you have to set up the project structure correctly to get the IDE to recognize symbols from other files. Although not much WL Plugin-specific documentation exists, this topic was indeed RTFM https://wlplugin.halirutan.de/docs/projects-modules/. Additionally, I need to stress that most language-unspecific features of IntelliJ IDEA also work with the WL Plugin and having a look at the IntelliJ IDEA Documentation https://www.jetbrains.com/help/idea/discover-intellij-idea.html can never harm. At least the Code Editing sections are a must. Note that you can switch the OS keyboard layout at the top-right of the page so that you always see the correct shortcuts. Things like column-selection mode, several cursors, jumping and navigating source code, etc. are a real breeze in IDEA. And if you ever run into a situation where you think that something appears as if there should be a better way, please just drop me a line. I'm always glad to help.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/halirutan/Wolfram-Language-IntelliJ-Plugin-Archive/issues/180#issuecomment-817073222, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3NEDSFJUOB34CMOMXXR53TH7EHHANCNFSM42UOUL6Q.
@JonMcLoone Now I can claim it's RTFM next time :)
With bracket typing enabled type "(" and you automatimatically get "()" However type "(*" and you end up with "(*)", an unterminiated comment. It would be better if you got "(**)"
Likewise typing "<|" is not recognized as a token needing closing.