I'm using JetBrains GoLang IDE, and couple of parameters are not applied, somehow.
I want to remove last line
I want to be able to add empty lines, in the middle
package main
>
> I want an empty line
import (...)
func main() {
...
...
}
> I don't want this line
I don't see such issues with PyCharm, and WebStorm, I guess it is GoLang feature.
I've tried EditorConfig plugin set it up, but it is not working at all
root = true
[*]
charset = utf-8
tab_width = 4
end_of_line = lf
indent_size = 4
indent_style = space
max_line_length = 120
insert_final_newline = false
ij_continuation_indent_size = 8
I do understand that there are maybe some standarts, but this is annoying, I get used to different style of code
New versions of GoLand use gofmt on save (Command/Ctrl+S or any action, e.g., switch to a different window) that reformats your files in this way.
On the other hand, GoLand has a built-in formatter (Code | Reformat Code) that formats the code the same way as gofmt, but allows you to change some style settings via Preferences/Settings | Editor | Code Style | Go.
To disable these features, you can disable two things:
Preferences/Settings | Tools | Actions on Save | Reformat Code.
Preferences/Settings | Editor | Code Style | Go | Other | Run gofmt on code reformat.
It will allow you to use your custom code style until you run gofmt or Reformat Code action manually.
Anyway, please keep in mind that gofmt is a de-facto standard in the Go world and it is not recommended to use a custom code style without serious reasons, e.g. Effective Go says:
Formatting issues are the most contentious but the least consequential. People can adapt to different formatting styles but it's better if they don't have to, and less time is devoted to the topic if everyone adheres to the same style. The problem is how to approach this Utopia without a long prescriptive style guide.
With Go we take an unusual approach and let the machine take care of most formatting issues. The gofmt program (also available as go fmt, which operates at the package level rather than source file level) reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments. If you want to know how to handle some new layout situation, run gofmt; if the answer doesn't seem right, rearrange your program (or file a bug about gofmt), don't work around it.
Related
I am working with a fixed-width file where all lines start with certain strings to denote what they contain.
TXX 12345 1111
TXY 123 1 2222
TXZ 1 2 3 4 5
What I want to happen is that I want to be able to add rulers or any form of formatting to rows that start with the specified text. (For example, I want to be able to set the line to red if the line starts with TXX, but blue if the row starts wtih TXY and so on)
What is the first step towards being able to do this?
Generally speaking, most roads here lead to a plugin of some sort that's doing work for you, though conceivably you could also get some coloring going using a custom syntax definition and alterations to your color scheme.
Which one is the correct one depends on circumstance and what works best for you. The following are some samples, which will work with the output you provided above but which could probably be made more robust (again depending on your use case); think proof of concept stuff.
Rulers
Rulers can only be applied to the file as a whole, not to specific lines. So for something like that you're looking at a plugin which, every time the cursor moves, tries to look at the current line to see what it is and then sets up rulers based on knowing what the line looks like.
A quick example of that is the following; the event listener will only apply to files that have the _fixed_rulers setting applied; simplistically, while you have your file open you can enter view.settings().set("_fixed_rulers", True) in the Sublime console, or if you have a syntax you could put the setting into syntax specific settings, etc.
import sublime
import sublime_plugin
def _get_rulers(line):
if line.startswith('TXX'):
return [4, 10]
if line.startswith('TXY'):
return [4, 8, 10]
if line.startswith('TXZ'):
return [4, 6, 8, 10, 12]
return []
class RulerListener(sublime_plugin.ViewEventListener):
#classmethod
def is_applicable(cls, settings):
return settings.get("_fixed_rulers", False)
def on_selection_modified_async(self):
# Cursor position of the first selection; get the full text of the
# line its on
pt = self.view.sel()[0].b
line = self.view.substr(self.view.line(pt))
self.view.settings().set("rulers", _get_rulers(line))
Since there can be multiple selections but rulers are not line specific, this uses the line the first cursor (based on position, not selection order) and applies rulers to the file based on that.
Regions
Colors can be applied to regions of content via a plugin, in a variety of styles (outlined only, underlined, filled, etc), and the API also allows you to find text regions via regex.
So it's also possible to have regions assigned that give things the color you want. A simple example of that would be this command, which will add/update the regions in the file that's active when you execute the color_line_regions command.
import sublime
import sublime_plugin
class ColorLineRegionsCommand(sublime_plugin.TextCommand):
def run(self, edit):
v = self.view
v.add_regions('_txx', v.find_all('^TXX.*$'), 'region.redish')
v.add_regions('_txy', v.find_all('^TXY.*$'), 'region.bluish')
v.add_regions('_txz', v.find_all('^TXZ.*$'), 'region.purplish')
This example is hard coded and requires you to manually invoke the command; you could also have this trigger in response to a file with a specific name opening, and so on.
As defined here this is a one time thing; if you are actively modifying the content of files, adding or changing lines will not adjust regions unless you run the command again (or, have an event listener listen for on_modified_async and trigger this after a delay, etc).
Syntax Definition
Another potential option is creating a custom syntax definition that recognizes the content of the file and applies the appropriate scopes to color things.
This is a much more complex option (the example below is very bare bones and not nearly production ready, but is a good simple test) in that it requires you to construct the syntax definition, but can yield good results if you put in the work.
What you would actually want to do is create your own custom scopes in your syntax, probably with much more robust rules, and then augment your color scheme to match those. Here we're just hackily using scopes that equate to the proper colors if you happen to be using Mariana as your color scheme.
%YAML 1.2
---
# See http://www.sublimetext.com/docs/syntax.html
file_extensions:
- fixed
scope: text.plain.fixed
name: Fixed Field Data
contexts:
main:
- match: '^TXX.*'
scope: variable.language.python
- match: '^TXY.*'
scope: variable.function.python
- match: '^TXZ.*'
scope: keyword.declaration.class.python
A Mix
The ultimate solution may be a mixture of these; perhaps you want the syntax to provide colors and the rulers plugin to make things easier to view as well (as a bonus, with a custom syntax you can have syntax specific settings, which makes the first plugin easy to deploy when files open).
The above examples just scratch the surface; be sure to check out the API Reference for information on how the plugins are working and for more details. There are also a variety of videos that teach how to create and use plugins on my YouTube channel.
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 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 mess with software written by completely unrelated groups of people, and it all uses completely different indentation standards. I'm okay with having to set the indentation width, but there's nothing more annoying than opening up a file with tabs, making some changes, and finding that my changes used spaces for indentation instead.
All the software I write uses four-space indentation. Then I go to make a Quake 3 mod and the entire codebase uses tabs. When I make changes I have to be incredibly careful to set my indentation settings first or I'm going to have to manually rewrite the indentation before committing, every single time.
I went through the settings and couldn't find anything. The tabs-and-spaces mode literally doesn't do anything special and just sets it to tabs mode instead (after a reset). I went through google and all I found was this extremely unhelpful mailing list message. Detecting consistent indentation isn't that difficult, other text editors manage it fine, it doesn't have to be perfect, it just has to work most of the time.
If Kate has a setting for this, where is it, and if it doesn't, when is it going to get such a setting? If I can't make Kate do this I'm going to have to switch off of it. I already went through Notepad++ and Geany, but they both have serious problems with doing regexes on extremely large files (say, tens of megabytes of text) or with rendering monospace non-european text.
Unfortunately, kate does not support this right now. There is a bug report for this from 2005, but noone implemented that yet (yes, 13 years ago).
What Kate does support though are Kate modeline (also called document variables). For instance, you can write in your text document e.g.:
// kate: replace-tabs on; indent-width 4;
And then the document containing this comment will automatically use 4 spaces and use spaces to indent.
Instead of writing these kind of comments into files, you can also write this into files called .kateconfig. You can find more information about .kateconfig files and modelines in this article.
from https://stackoverflow.com/a/21666354/433570
It's dos based solution though, can it be done for linux based system?
I'm trying to highlight stuff in my log file.
For instance, I want to highlight the line of nginx log which has slower response time than 1 sec.
** edit **
Currently I'm using hi-lock-mode
eg, I put a mark on a line that shows slow response, then use regex & hi-lock to highlight it.
I guess this is ok solution, for now.
I am wondering if there's a better solution.
hi-lock mode with user-defined function rather than regex is what I would hope for.
I would define functions, and mapping between function-color.
Then I would M-x apply [function]
def slow(line):
if ... :
return True
return False
slow: yellow,
iPhone: blue,
I think this would be useful to inspect logs..
I wonder if there's a similar functionality available out there?
Why don't you write your own major mode for your files?
A basic major mode with font-lock support is not hard to implement. There are plenty of documentation on this on the net. All you need is a syntax table (so that Emacs would know which characters start strings etc.) and some font-lock rules for syntax highlighting.
The easiest, though, is to start with an existing one, for example ini-mode, a small major mode for editing Windows-style ini files.
Unless your files have a specific file extension or otherwise follow a specific naming convention, you might want to add an entry to magic-mode-alist, which provides you with a way to recognize specific files based on the content rather than the file name.
If you would like to see your files colored in a terminal window when viewed using more or less, you can use e2ansi, a package that use Emacs to generate an ANSI version of syntax highlighted files.