From what I can tell from the CSON README and other CSON usages I've found on the Internet, it's conventional to use single rather than double quotes for string literals. Because of this (and because I agree with the rationale I've generally seen behind this convention), I am using it for my Atom config files, such as keymap.cson:
'body':
'ctrl-tab': 'pane:show-next-item'
'ctrl-tab ^ctrl': 'unset!'
'ctrl-shift-tab': 'pane:show-previous-item'
'ctrl-shift-tab ^ctrl': 'unset!'
So far, this has worked fine for me. However, I am running into a problem when I try to use the same convention for my config.cson file as well. For instance, I am trying to have its contents set to the following:
'*':
core:
disabledPackages: [
'exception-reporting'
]
restorePreviousWindowsOnStart: false
telemetryConsent: 'no'
welcome:
showOnStartup: false
whitespace:
ignoreWhitespaceOnCurrentLine: false
But if I open Atom and hit Ctrl+= Ctrl+- (to play with the font size) or do some other similar change and then restore Atom back to its previous state, Atom changes my config.cson file to look like this:
"*":
core:
disabledPackages: [
"exception-reporting"
]
restorePreviousWindowsOnStart: false
telemetryConsent: "no"
editor: {}
welcome:
showOnStartup: false
whitespace:
ignoreWhitespaceOnCurrentLine: false
As you can see, it changed all the single quotes to double quotes and added an unnecessary editor section.
Is there a way to prevent Atom from making these sorts of superficial changes to my config.cson file? The reason this matters to me is that I am keeping my Atom config files in version control, so in order to prevent very noisy diffs, I would need to either disable this behavior or use inconsistent or suboptimal styling for my quotes, and I would find the former option much more preferable if it is possible.
If it's an option to switch the file-format, consider using config.json instead. Since JSON uses double-quotes by convention, there should be no conflict when making changes to your Atom configuration.
Atom is already in the transition to move away from CoffeeScript (and CSON) and you can use JavaScript/CoffeeScript and JSON/CSON interchangeably throughout the app.
As of v2.0.0, the cson-parser library uses the conventional default for quote type when stringifying CSON, so you can write a simple shell script using that library and run it on config.cson before committing to Git. It would also be relatively simple to remove things like the empty editor section in such a script before calling stringify.
You could potentially write this into an Atom package, as #idleberg mentioned in a comment, but I haven't tried that myself.
If season upgrades its cson-parser dependency to v2.0.0, that would solve the quote type problem, but the empty editor section would still need to be removed by something else.
Related
I try to use an ANTLR plugin for IJ, but there is an annoying problem. I don't know, what I'm doing wrong, but after changing something in lexer grammar besides generating ANTLR recognizer (often, but not always) I have to restart IJ to see the correct parsing tree. Already tried to "Save all" or "Synchronize" before testing parser, but nothing helps. Has anyone encountered such a problem?
Thank you in advance.
As glytching suggested in their comment, this is the problem described in this GitHub issue: https://github.com/antlr/intellij-plugin-v4/issues/242
The solution seems to be to hit Save. Another user also mentions touching the file from the terminal.
This puzzled me, as I'm using PyCharm and the way it seems to be set up by default is to auto-save as you work so I basically never interact with Save explicitly in any way. However, in this case hitting Ctrl+S does seem to make a difference (compared with just letting it auto-save) and it solves the issue for me.
For clarity, my situation is:
I have a grammar broken up into several parts (mixture of lexer, parser and combined grammars) which are imported into the 'main' grammar.
I am working interactively with the ANTLR Preview window (OP mentioned generating a recognizer, but I think this issue is completely independent of running the Antlr generator).
If I make a change in one of the imported grammars and switch back to the main grammar to re-run my start rule there it doesn't always pick up the change from the imported grammar.
Hitting Ctrl+S after making the change in the imported grammar, before switching back to my main grammar, fixes the problem.
I have posted on this before, but couldn't find a simple example. Here's one. I had some code commented out. Part if it was a comment. I used un-comment to turn the code back on for testing. And so this...
'check to see if this is a "simple" struct that has only basic types inside, not additional embedded type 5's
Turned into this...
check to see if this Is a "simple" struct that has only basic types inside, Not additional embedded type 5's
Look at the Is and Not. This isn't happening on all keywords, it appears that it's primarily Linq related terms get re-camel cased - Is, On, Where etc. And that's weird, because I don't have or use Linq in any of my projects.
This is annoying, but what is actually damaging is when this happens inside quotes. Let's say you had something like this...
'this is a "really long comment that I want to split into two lines"
Now I place my cursor in front of, say, "I" and hit return. This produces a second line with a trailing quote. Now every keyword in the entire file from that point on is re-cased, because there's an open quote confusing VS. Now my git diff is basically screwed.
Does anyone have any suggestions on what might be happening and how to turn it off?
The re-casing of keywords is a feature of "Pretty listing (reformatting) of code". This feature was less aggressive in VS versions earlier then VS2015 and did not run un-commenting a line.
To disable it go to:
Tools Menu->Options->Text Editor->Basic-> Advanced-> Editor help section
and uncheck "Pretty listing (reformatting) of code".
it bothers me:
why can't i "soft return" in intellij (or any IDE actually)?
is there a way i don't know of to "X + return key"?
situation: i want to copy&paste long paragraphs into a translation.json.
Afterwards, i want to format them with html tags.
So why can't i have
"translation": {
Hi!/
this is/
the text./
maybe there is a/
LINK too?/
/
Second Paragraph/
/
This is the second paragraph./
}
with /being soft wrap markers
instead of
"translation": {
Hi! this is the text. maybe there is a LINK too? Second Paragraph This is the /
second paragraph.
}
(it makes inserting the html tags a PITA)
why can't i "soft return" in intellij (or any IDE actually)?
Most likely because it is not a highly desired feature. Secondly, from a practical standpoint, the implementation would be cumbersome because most file formats an IDE uses are ultimately plain text. As such the file does not have a concept of a soft return. For an IDE to support arbitrary soft returns, it would need to maintain a data store containing the metadata of where in each and every file you've ever edited you want soft returns.
Or alternatively, the soft returns would need to be stored in the file. But the only way to do that and not "effect" the actual code in the file is via comments. Such as how an IDE uses comments to suppress warnings, create an arbitrary folded block, or turn off auto formatting. (And of course, with your example, JSON does not have comments, further complicating things.) Using comments for soft returns would, I think, result in a lot of clutter in the file. For example, for HTML, even using a one character comment of a paragraph symbol "¶" results in a lot of clutter:
"translation": {
Hi!<!--¶-->
this is<!--¶-->
the text.<!--¶-->
maybe there is a<!--¶-->
LINK too?<!--¶-->
<!--¶-->
Second Paragraph<!--¶-->
<!--¶-->
This is the second paragraph.<!--¶-->
}
You could always request a new feature to add support for something like this to IDEA, but I'm fairly sure it would unlikely gain any traction (based on 13+ years of IDEA usage and very active community membership).
I agree with #Peter's comment that more detail about the workflow you have might help. Ultimately, the Paste as plain text action he mentions is likely the solution. Or you can turn off reformatting on paste in Settings > Editor > General > Smart Keys > "Reformat on paste". See the following help page for more information: https://www.jetbrains.com/help/idea/2016.2/smart-keys.html
I'm getting a strange behavior from the Office VBA Editor: certain terms no longer capitalize when they are recognized. In fact, I can use the autoselect to choose the term, which is properly capitalized until the compiler validates the line and the editor actually changes it to lower case.
For example, today I typed this Set wFramework = application.ActiveWorkbook using the auto-select to choose .ActiveWorkbook, but as soon as I pressed [Enter], the compiler changed it to Set wFramework = Application.activeworkbook. Notice that the compiler properly capitalized Application but improperly removed the capitalization from .activeworkbook.
For now the number of objects / methods that don't capitalize correctly is small, but seems to be growing.
I've tried things like turning off all the code settings in hopes this would somehow reset things, but that was a non-starter. I can't find anywhere with controls for that function. I wondered if this is handled through the References, but there doesn't seem to be anyway those should be editable, especially without my doing it on purpose. I'm also wondering if this is somehow a function of Windows improperly tracking case management, but again it seems like that would be specific to a Windows session, and this symptom persists even if I have shut down the computer completely and restarted.
Does anyone know what might cause this, and whether it is possible to reset?
I had the same behaviour with the Enabled property always being displayed as e.g. chkReportFinance.enabled = False.
This was easily fixed by adding a line Dim Enabled, which capitalised all instances, then removing the line.
Tim Williams said:
"Sometime if you have (eg) defined a variable with the name application then the compiler gets "stuck" on that case and doesn't correct later uses to Application, even after renaming the variable. If the problem persists try exporting and re-importing your code modules (see Rob Bovey's "code cleaner" tool for an easy way to do this: appspro.com/Utilities/CodeCleaner.htm)"
This solved the problem. Question answered!
We are testing the Imageresizer.net and have found that the Preset Plugin seems to only work with width and height parameters and completely ignores the mode parameter i.e. mode=crop.
Is this a bug or simply not supported.
Many thanks
It is supported, but know that the presets settings and defaults values must be valid command/querystrings. Spaces or typos in the command string will cause that command (and potentially the rest) not to function.