I find that the "Reformat Code" action in IntelliJ (and, by extension, Android Studio) will put a full stop on a new line in Markdown files if the full stop is the character at the "Hand wrap at" limit.
For example, take the following two lines:
The full stop on line 13 is the only character past the "Hand wrap at" limit. If I apply the Reformat Code action with all the default Code Style settings for Markdown files, the full stop (and only the full stop) will be moved to a new line, as follows:
This means that a space will be placed between the full stop and the word before it when the Markdown file is rendered. That is incorrect. It would be better if the Reformat Code action kept the full stop on line 13 or moved the full stop to a new line together with the word that precedes it.
Is there any Code Style setting for Markdown files which will prevent the Reformat Code action from moving the full stop to a line of its own? Or is adding Markdown files to the "Do not format" list the only way to prevent this?
The issue described in my question is a bug in older versions of IntelliJ. See IDEA-276835 for details. The issue is fixed in the 2022 releases of IntelliJ. I tried it in the 2022.3.1 release of IntelliJ and it does the correct thing, as follows:
Related
I opened a Modelica library in Dymola, changed one line, closed Dymola and clicked "Save all", now TortoiseSVN is showing several hundred changed files instead of just one file with the one line changed I intended to do. All these changes are either whitespace, or line breaks, introduced by Dymola it seems.
Of course I can now be careful to only commit the file I have changed (and revert the rest), but that makes committing more time-consuming and error-prone than it needs to be. Or I can just commit it all, but that makes it hard for my colleagues to review the change. Also, it feels like it is not deterministic, so a later commit might just revert parts back. I sometimes even revert all changes, then use a text editor to change just the one line. All this makes version control unnecessarily complicated.
When I look at the commits and diffs for e.g. the Modelica Standard library:
https://github.com/modelica/ModelicaStandardLibrary/commits/master
The diffs are nice and small and readable usually. Is there a trick to avoid the whitespace issue?
How I can I turn off all autoformatting by Dymola? Is there a technical reason to do it in the first place?
You can reduce (but not entirely prevent) this behavior as follows:
Increase the maximum line length, e.g. to 130
In the GUI: Options > Text Editor > Max line length
From the command line: Advanced.MaxLineLength=130
Let Dymola format your whole library one time
Open the text view of the top-level package
Mark everything with Ctrl+A
Auto-format with Ctrl+Shift+L or Right-Click > Auto-Format
Save everything with Ctrl+Shift+S
Now go through the changes. Most will be useful, but sometimes spaces are removed, which you usually like to keep (especially before import and extends statements. They are sometimes moved to the very left)
Commit the changes
From now on try to save individual models only, not packages
(When packages are saved, Dymola sometimes reformats the nested classes)
There are some things you can do to make pretty git commits for Modelica code:
Use a text editor instead of a graphical editor. You have absolute control of what you change.
Use a graphical editor that does not change whitespace. I'm not sure of other alternatives, but OpenModelica/OMEdit will preserve existing indentation as much as possible (it can also be used to minimize diffs from changes in other tools, but it works less and less well the more changes there are).
Use a formatter as a pre-commit hook (indenting all files according to some settings in the formatter; but then you can't manually change whitespace).
Hope someone on stackoverflow has more alternatives than this.
I can't comment out multi line in sublime 3. Looked at this Keyboard shortcut to comment lines in Sublime Text 3 already but it is not fixing it
Sublime version is 3.2.1 build 3207 . on windows 10.
Please help me out if have any tips.
The keyboard binding for commenting is indeed Ctrl+/ (Cmd+/ on MacOS) so in the general case what you're trying should work just fine.
That said, the keys in question are bound to the toggle_comment command and that command requires language specific metadata to know what comments are supposed to look like. For example comments look and work differently in HTML than they do in C or JavaScript. Some file types (such as plain text files) aren't code and thus don't have a concept of comments at all.
If the metadata file for a file type is missing, then the toggle_comment command won't do anything because comments are assumed to not be valid, which seems to be what's happening to here.
The first thing to check would be to examine the bottom right of the window to see if Sublime agrees with you about what the file type is supposed to be. For example, newly created tabs are Plain Text files until you save the file for the first time, and comments are not allowed in Plain Text files.
If the file type doesn't say what you think it should, you can click it to open a menu and select the appropriate type for that file.
If the type of the file looks to be correct and the command still doesn't work, then the metadata file needed is not being provided in the package that is adding support for that language. In that case you should raise an issue with whoever is responsible for the package in question and get them to add the appropriate file.
Based on the comments on your question, you think you're editing JavaScript files but Sublime thinks you're editing an ActionScript file instead. The JavaScript package includes the appropriate file, but the ActionScript package does not.
So in your particular case, your best bet is to switch the file type to JavaScript and your problem should go away. If you actually want to be editing ActionScript instead, then you need to create an issue on the Default package tracker and ask for this to be added.
I am typesetting a latex file in VIM using the Vimtex plugin.
Every time I close a bracket, this text shows up automatically in the <++>.
For example:
\section{This is one}<++>
\section{The variable $V_L$<++> explains things}<++>
\begin{equation}
<+content+>
\label{<+label+>}
\end{equation}<++>
LaTeX compiles my text with those printed out in the pdf so I have to manually remove the every time. This behavior goes from $$ to {} to others also and even inside certain areas when using autocompletion features wit F5.
I did look add this question but it did not provide much help as to how to solve my issue.
How can I prevent the from being added to my tex files?
If they are a feature meant for something I do not understand, how do I prevent them from compiling in my pdf's?
This part of the documentation on the vim-latex (not Vimtex) repo on github
explains how the macro system works, how it's useful and solely meant for editing
NOTE: Place Holders
-------------
Almost all macros provided in Latex-Suite implement Stephen Riem's
bracketing system and Gergely Kontra's JumpFunc() for handling
place-holders. This consists of using "place-holders" to mark off
locations where the next relevant editing has to be done. As an example,
when you type EFI in |insert-mode|, you will get the following: >
\begin{figure}[<+htpb+>]
\centering
\includegraphics{<+file+>}
\caption{<+caption text+>}
\label{fig:<+label+>}
\end{figure}<++>
The text <+htpb+> will be selected and you will be left in |select-mode|
so that you can continue typing straight away. After having typed in the
placement specifier, you can press <Ctrl-J> (while still in insert-mode).
This will take you directly to the next "place-holder". i.e, <+file+> will
be visually selected with Vim in select mode again for typing in the file
aaaa. This saves on a lot of key presses.
Note: Upon testing I realized that the placeholder only appears when the bracketing is empty.
I am using vim as my text editor for programming in react/javascript, and trying to use flow for static type checking. In my .flowconfig, I have all=true, meaning I would like to have flow type checking on all .js files without requiring a comment at the top of each file. I have the vim plugin ale setup to lint flow and give errors, and it works fine when I have the flow comment (// #flow) at the top of the file, but I would like this to work on every .js file without needing the comment at the top (as specified in my .flowconfig).
Afters spending some time tinkering with ale, I thought my best option may be to simply prepend the comment at the top of the file when a new buffer is opened, and then remove it before saving. Is there a way to do this in my .vimrc with an autocommand?
Bonus: Extra brownie points if you can get this to work using only ale and not needing to add the flow comment to every file
I'm writing a syntax definition for Sublime Text 3, using the new YAML fornat and not the deprecated one. I'm not seeing changes to the text I'm trying to highlight, though. When are changes to my syntax definition file applied to the files it's meant to highlight? And if I can force a definition reload, how can I do so?
Changes to .sublime-syntax files take effect as soon as they are saved - ST detects any changes made when the file is within the Packages folder structure. You can see this in the ST console (View menu -> Show Console) when saving the file:
generating syntax summary
Unfortunately, there is no timestamp on the entries, so sometimes it can help to manually enter something into the console to help visually separate the lines. i.e.
import time; time.asctime(time.localtime())
'Mon Jan 8 09:11:06 2018'
then, you know any lines that appear under that in the console happened after that time.
One caveat is that ST currently doesn't detect changes automatically when the files are in a symlinked folder: https://github.com/SublimeTextIssues/Core/issues/1154
In such cases, the only way to get ST to reload modified/new files is by restarting ST.