I am using the Atom text editor, and for the longest time the syntax highlighting was working perfectly. Then I upgraded atom, and it changed the default syntax from JavaScript (rails) to just JavaScript syntax highlighting. Now I manually have to change it everytime I open a new file.
After searching for a while, I found something that works well. In Atom go to
Atom > Init script
Then add the following code
path = require 'path'
atom.workspace.observeTextEditors (editor) ->
if path.extname(editor.getPath()) == ".js"
editor.setGrammar(atom.grammars.grammarForScopeName('source.js.rails source.js.jquery'))
In this case I am setting the default syntax highlight for all files ending in .js to my preferred syntax source.js.rails source.js.jquery
You can find the source name of the syntax you want by manually going to the syntax highlighting, and it will be listed next to the name on the right
I'm trying to output the compiled CSS to a different directory.
/project/scss/ to /project/css/
I've tried this, but get the error below:
Error: error No such file or directory - /Applications/MAMP/htdocs/project/public/css/style.scss
What are the Arguments and Output paths to refresh exactly for?
I got it working now with the following settings:
The only difference now is the Output paths to refresh field. It's the default now.
$FileParentDir$ contains the path of the parent SCSS file. So in our case it will be /project/scss. In order to make it work like you need, it is necessary to use $ProjectFileDir$ variable or (if you insist to use $FileParentDir$) $FileParentDir$/../ so it would go to an upper level directory.
If you will open any file in Editor and then go to Preferences | Tools | File Watchers > edit your file watcher settings > press Insert Macro button, you will see the list of all the variables with previews for currently opened file so you can see the values and build the arguments accordingly.
Note that Output paths to refresh also should be modified according to the Arguments path.
How can you change permanently the default colors of gradle output?
With my background color, gradle output is difficult to read.
So I want to change the output color.
One blog claims it can be done:
http://gradle.1045684.n5.nabble.com/Colourizing-console-output-td3073839.html
So I tried to put this in my (home)\.gradle\gradle.properties:
org.gradle.color.normal=YELLOW
org.gradle.color.info=YELLOW
org.gradle.color.identifier=YELLOW
and
systemProp.org.gradle.color.normal=YELLOW
systemProp.org.gradle.color.info=YELLOW
systemProp.org.gradle.color.identifier=YELLOW
It didn't help. So I tried this in my (home)\.gradle\init.gradle:
initscript {
System.setProperty('org.gradle.color.normal', 'WHITE')
System.setProperty('org.gradle.color.identifier', 'WHITE')
System.setProperty('org.gradle.color.info', 'WHITE')
}
It also didn't help.
So far, the only way I can remove the colors is to run gradle with
gradle -v --console plain
But I don't want to type that every time I run a command. So I tried to make it permanent with:
set GRADLE_OPTS=--console plain
But when I do that gradle complains : Unrecognized option: --console.
So is there any way to make a permanent change in the output colors?
Two solutions so far: 1. doskey gradle=gradle --console plain $* and 2. set TERM=dumb. I would like errors to remain red though.
Adding org.gradle.console=plain to gradle.properties removed the colors for me.
I'm using Vim with a bunch of plugins (pathogen, ctags, snipmate, supertab, ...), and everything works fine for all kinds of file extensions.
However, when I'm try to edit .tex files it presents two problems which seem related. First, Vim starts to work really slow, and second, when I press "any letter + Tab", it tries to auto-complete with words previously written in the text.
One way which I tried to solve those issues, is by removing the supertab plugin from my bundle folder, but it's a not satisfactory solution.
The problem is due to the relativenumber option, when I turned it off the latex edit speed come back to normal.
The following relativenumber, cursorline and MatchParen can slow vim down a lot, especially when dealing with large latex files. When I turn them off then vim becomes much more responsive when dealing with large latex files.
To turn off relative number, type the following in editor mode:
:set nornu
To turn off cursorline, type the following in editor mode:
:set nocursorline
To turn off MatchParen, type the following in editor mode:
:NoMatchParen
If you still want regular line numbering then you can have
:set number
For a more permanent solution, you can also set latex specific settings in your ~/.vimrc file:
" Latex specification
au BufNewFile,BufRead *.tex
\ set nocursorline |
\ set nornu |
\ set number |
\ let g:loaded_matchparen=1 |
The \ and the | are there to allow you add the latex commands over multiple lines.
The other two possible problems are the following being active
cursorline
DoMatchParen
So to make your LᴬTᴇX editing experience much better, you can do something like the following in your ~/.vimrc
au FileType tex setlocal nocursorline
au FileType tex :NoMatchParen
After doing this my Vim is as fast with .tex files as it is with .cpp ones.
I know this is an old issue, but, to anyone seeing this now, it is better to use the ftplugin/ folder in your .vim directory to instruct Vim to enable certain options on a specific file type. Create a file ~/.vim/ftplugin/tex.vim with the following options:
set nocursorline
set nornu
let g:loaded_matchparen=1
This makes Vim load these options only on TeX files (*.tex and related) without resorting to an :autocommand like gloriphobia’s answer does.
Folding is another common source of slowdown. It is normally disabled by default, but perhaps you have enabled it. You can just disable it again:
" (1) if you use the builtin TeX support:
" comment the line in your vimrc that looks like this:
"let g:tex_fold_enabled = ...
" OR, just to be sure, do:
unlet! g:tex_fold_enabled
" (2) if you rather use VimTeX:
" comment the line in your vimrc that looks like this:
"let g:vimtex_fold_enabled = 1
" OR, just to be sure, do:
let g:vimtex_fold_enabled = 0
Note that folding must be enabled/disabled before TeX syntax is loaded in the buffer. Also, Vim option 'foldenable' (toggled by the normal-mode command zi) does not actually clear folding, it just hides it but it’s still there).
However, if you don’t want to give up on folding altogether, I found a single bottleneck in the builtin TeX folding that was responsible for most of the slowdown in my case: the document environment. Simple test: typing stuff just before \begin{document} is reasonably fast, but typing right after it is amazingly laggy. I guess it happens because that environment commonly spans hundreds of lines.
If you use the builtin TeX folding, you can prevent the folding of just the document environment by disabling the texDocZone matchgroup¹. Anyway, why would you want to fold the toplevel contents?
" put this in your vimrc :
au FileType tex :syntax clear texDocZone
" OR put this in ~/.vim/after/syntax/tex.vim :
syntax clear texDocZone
Alternatively, if you have VimTeX, you can replace the builtin TeX folding with the VimTeX’ one. I find it generally better, and it carefully avoids folding the document environment.
" put this in your vimrc :
unlet! g:tex_fold_enabled " just to be sure
let g:vimtex_fold_enabled = 1
VimTeX’ folding is nicely customizable, see :help vimtex-folding.
¹ As of version 121 (April 2022) of the builtin TeX syntax.
In Geany, editing PHP scripts, when you select lines and press control-e, the selected lines are commented by being wrapped in "/* ... */". Is there a way to change this behaviour so that it instead puts a "//" in front of each line?
All the other IDEs that I've used make use of "//" (Eclipse, Netbeans, Textmate, etc).
Settings like comment characters are controlled by filetype definition files. Assuming your scripts end in .php, you should find the default system-wide filetype definition file filetypes.php, and copy it to your filedefs directory in your user configuration directory. Then you can modify it as necessary.
This is all explained in detail in the manual (link above).