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
Related
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.
In response to this question on SuperUser, I wrote a small vimscript that will detect the filetype of a symbolic link and change the syntax highlighting:
au BufNewFile,BufRead * if &syntax == '' | silent! execute (':set filetype='.matchstr(resolve(#%),'.[^.]*$')[1:]) | endif
So if I open a symbolic link with no extension, it will look at the extension of the file it points to.
It works, but an unintended consequence is that now the syntax highlighting of my .vimrc file is gone. By default, my .vimrc file has vim syntax highlighting (:echo &syntax returns vim).
But when I add the above line, :echo &syntax returns vimrc (an invalid type).
I don't know why this is happening. Shouldn't &syntax=='' evaluate to false, and thus keep &syntax==vim? I suspect that my code is executing before the syntax highlighting is set to vim. But how (and when) exactly is the syntax highlighting set to vim for .vimrc? Additionally, how can I make my script behave the way it should?
Look in Vim's runtime area for filetype.vim. You can bring it up in vim with:
:e $VIMRUNTIME/filetype.vim
In my version, it looks like this line does the trick:
" Vim script
au BufNewFile,BufRead *vimrc* call s:StarSetf('vim')
Perhaps you want to put your autocmd in ~/.vim/after/filetype.vim. I believe this will cause it to be registered after the system ones, and then &syntax should be set up correctly.
jszakmeister's answer diagnoses the problem accurately: filetype.vim sets the filetype for vimrc.
An alternative solution though, to keep everything contained in in your .vimrc file, is to use:
au BufNewFile,BufReadPre * if &syntax == '' | silent! execute (':set filetype='.matchstr(resolve(#%),'.[^.]*$')[1:]) | endif
Note the change from BufRead to BufReadPre. The change causes this line to execute before filetype.vim. The syntax will be changed to vimrc, but then subsequently changed to vim. The upshot is that the script works as it should, but syntax highlighting for vimrc is preserved.
When the current file is ~/.vimrc, this part of your code
matchstr(resolve(#%),'.[^.]*$')
returns your file name: .vimrc.
I have no idea how you could imagine that /home/username/.vimrc would produce vim.
This is rather obviously a bad approach for the problem you tried to solve but there's no bug: you get exactly what you ask for. Using the filename/extension for filetype can't work reliably (js vs javascript, py vs python…).
You will probably need a filename/filetype list or many if/elseif if you want your code to do what you want.
See :h syntax-loading.
Is there a way to set a default document type when saving a NEW FILE?
I created several new files and I want to have a default value of .txt when saving a NEW FILE.
Create a new plugin Tools > Developer > New Plugin...
Paste this in:
import sublime, sublime_plugin
class EverythingIsPowerShell(sublime_plugin.EventListener):
def on_new(self, view):
view.set_syntax_file('Packages/PowerShell/Support/PowershellSyntax.tmLanguage')
Save and call it NewTabSyntax.py. New tabs will now default to Powershell.
You can change the syntax to whatever you prefer. To find out the "path" of a particular syntax, simply open a file of that syntax, open the console (View > Show Console) and type:
view.settings().get('syntax')
This plugin does it:
https://github.com/spadgos/sublime-DefaultFileType
seems pretty great.
Edit:
Ok, two things, there currently seems to be a small bug so the text file syntax is not being correctly picked up due to the whitespace in the filename. In addition you need to set the "use_current_file_syntax" to false, (otherwise the new file will default to whatever filetype you have open already when you hit Ctrl-N)... So the fix/workaround is this:
Put the following code in: Packages/User/default_file_type.sublime-settings
{ "default_new_file_syntax": "Packages/Text/Plain_text.tmLanguage",
"use_current_file_syntax": false }
NOTE THE UNDERSCORE.
Next, find the "Plain text.tmLanguage" file and copy and rename it (in the same folder) as "Plain_text.tmLanguage". [be sure to copy/duplicate it, do not just rename it, as it may have dependancies]
Restart, just to be sure, and this should do the trick.
Also note this plugin only works for new files created with Ctrl-N.
Working after these steps:
1.Uninstalled
2.Installed using Package Control
3.Test using default install (type Jave) <-- worked
4.Copy and Renamed file Sublime Text 2\Packages\Text\Plain text.tmLanguage > Sublime Text 2\Packages\Text\Plain_text.tmLanguage
5.Changed file Sublime Text 2\Packages\Default File Type\default_file_type.sublime-settings >
`{ "default_new_file_syntax": "Packages/Text/Plain_text.tmLanguage", "use_current_file_syntax": true }`
-- All working.
I did not need to copy any files into the 'Packages/User' folder
#fraxel _ Thanks for all the help and quick response.
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).
I'm using nano on a server via ssh; on that system, nano doesn't have syntax color enabled by default. So I copied these nanosyntax files (for alternative, see also #CraigBarnes' answer) on the server, and had set up ~/.nanorc as:
include "~/nanosyntax/syntax-nanorc/php.nanorc"
include "~/nanosyntax/syntax-nanorc/php2.nanorc"
include "~/nanosyntax/syntax-nanorc/sh.nanorc"
include "~/nanosyntax/syntax-nanorc/python.nanorc"
include "~/nanosyntax/syntax-nanorc/html.nanorc"
include "~/nanosyntax/syntax-nanorc/perl.nanorc"
include "~/nanosyntax/syntax-nanorc/ruby.nanorc"
include "~/nanosyntax/syntax-nanorc/js.nanorc"
Now, this is the thing; if I just call:
nano somefile.php
... no php syntax coloring is done. If I try to force:
nano --syntax=php somefile.php
... still no syntax coloring (shown as plain text). However, if I do:
nano ~/.nanorc
... then I do get syntax coloring (that corresponds to .nanorc type file) ?!
So obviously, syntax coloring as such works (i.e. shell and nano are capable of it) - except, it seems to be ignored for some languages, like in this case php ?!
So, does anyone know what is going on - and how could I get syntax coloring also for php files?
Thanks,
Cheers!
I just ran into the same problem, and I fiddled around a bit with the includes to find the error. Surprisingly, turns out that changing the inclusion order fixed the issue:
This works:
include "~/.nano/nanorc.nanorc"
include "~/.nano/sh.nanorc"
# more includes...
This fails to highlight sh files:
include "~/.nano/sh.nanorc"
include "~/.nano/nanorc.nanorc"
# more includes...
So I guess it's probably a bug (in nano 2.2.2; worked fine in nano 2.1.7)
Hm... well, it seems there has been an upgrade on that server I was using; originally, nano didn't have syntax coloring by default, which is why I used my own separate ~/.nanorc.
Now, however, on the upgraded server, nano seems to work with php syntax coloring by default - and me having my own separate ~/.nanorc seems to have conflicted; because, once I commented all the entries in the private ~/.nanorc (with an #), php syntax coloring was back!!
Whowouldathunkit ?! :)
Cheers!
EDIT: Just to add a couple of notes about nano:
As noted above, syntax coloring is forced with --syntax switch; to see which syntaxes are available:
grep 'include' /etc/nanorc | # find lines containing 'include' in nanorc
grep -v '^#' | # don't process lines that start with '#'
sed 's_.*/\(.*\)\.nanorc"_\1_' # extract plain filenames
Result of this command is something like:
nanorc
c
css
debian
gentoo
html
...
So to force "nanorc" syntax coloring, you use:
nano --syntax=nanorc /usr/share/nano/nanorc.nanorc
.. or forcing "bash" shell script syntax coloring (especially useful with bashrc) would be:
nano --syntax=sh ~/.bashrc
Those "nanosyntax" files on Google Code are nearly as bad as ones that come with nano by default.
nano's highlighting engine is more basic than something with nested contexts (e.g. GtkSourceView) but you don't have to settle for crappy highlighting:
https://github.com/craigbarnes/nanorc