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).
Related
I am keeping notes in console vim on my laptop, and
I want to add syntax highlighting to my notes in order
to enhance them. However, I don't want to add a
million different filetypes for every area of knowledge
(for example my notes on compilers would have different
keywords than my notes on the FHS), and I also want to
make it easy to share these notes. After doing some
research, I discovered that I can get the behavior I
want, but it doesn't seem like a very elegant solution.
I added the following lines to my .vimrc:
if (filereadable("./.custom_syntax.vim")
let mysyntaxfile = "./.custom_syntax.vim"
syntax enable
else
syntax enable
endif
I don't really like this solution because it still
requires me to ask them to modify their .vimrc, but I
suspect that there's no way to do this without changing
anything on their system. Additionally, if I have any
files in the directory that aren't notes, vim will still
highlight them with the .custom_syntax.vim file because
I don't know what the filetype is.
Is there any better way to accomlish this?
Instead of using the old mysyntaxfile variable, I'd just :syntax enable (once) and then :source the syntax file. You can define an :autocmd that looks for an eponymous Vimscript file next to the original:
" Automatically source an eponymous <file>.vim or <file>.<ext>.vim if it exists, as a bulked-up
" modeline and to provide file-specific customizations.
function! s:AutoSource()
let l:testedScripts = [expand('<afile>') . '.vim']
if expand('<afile>:e') !=# 'vim'
" Don't source the edited Vimscript file itself.
call add(l:testedScripts, expand('<afile>:r') . '.vim')
endif
for l:filespec in l:testedScripts
if filereadable(l:filespec)
execute 'source' fnameescape(l:filespec)
endif
endfor
endfunction
augroup AutoSource
autocmd! BufNewFile,BufRead * call <SID>AutoSource()
augroup END
You do need this or something like this in your Vim configuration, though.
While trying to setup a dropbox folder with git, I saw a "Icon\r" file which is not created by me. I try to ignore it in the ~/.gitignore file. But adding Icon\r Icon\r\r Icon? won't work at all.
You can use vim as well.
vim .gitignore
in a new line write Icon, then
press ctrl+v and then press Enter
repeat step 3
save and exit (shortcut: ZZ)
Now you should have Icon^M^M and it's done :)
For a smarter use you could add it to your gitignore global config file in ~/.gitignore_global.
(This improves on the original answer, following a suggestion by robotspacer, according to hidn's explanation.)
The Icon? is the file of OS X folder icon. The "?" is a special character for double carriage return (\r\r).
To tell git to ignore it, open a terminal and navigate to your repository folder. Then type:
printf "Icon\r\r" >> .gitignore
If the file does not exist, it will be created and Icon\r\r will be its one line. If the file does exist, the line Icon\r\r will be appended to it.
"Icon[\r]" is probably a better alternative.
In vim, you just put Icon[^M], which is Icon[ followed by CtrlV, Enter then ].
The problem with "Icon\r\r" is EOL conversion.
The whole line is actually "Icon\r\r\n", counting line ending. Based on your setup, CRLF may be converted to LF on commit, so your repo will actually have "Icon\r\n". Say you sync the changes to another repo. You will get "Icon\r\n" in that working directory, which ignores Icon but not Icon^M. If you further edit .gitignore and commit it there, you will end up with "Icon\n" - completely losing \r.
I encountered this in a project where some develop on OS X while some on Windows. By using brackets to separate \r and the line ending, I don't have to repeat \r twice and I don't worry about EOL conversion.
The best place for this is in your global gitignore configuration file. You can create this file, access it, and then edit per the following steps:
>> git config --global core.excludesfile ~/.gitignore_global
>> vim ~/.gitignore_global
press i to enter insert mode
type Icon on a new line
while on the same line, ctrl + v, enter, ctrl + v, enter
press esc, then shift + ; then type wq then hit enter
Regarding Naming (and Quoting) Things: First, more people would benefit by knowing that ANSI-C Quoting can be used to unambiguously match the macOS icon file. Both Icon$'\r' or $'Icon\r' and work in Bash and Zsh and most other modern shells, I hope, such as Fish.
Keep Your .gitignore Editable: While I'm impressed by the byte-level manipulation offered by other answers here, these methods are brittle in practice. Simply put, programmers tend to use text editors, and many of these editors are configured to alter line endings when saving a file. (For example, see this VS Code discussion about line ending normalization.)
Do you want your careful byte editing undone by your editor? Of course not. So perhaps you find it practical and convenient to configure your editor so that it doesn't affect line endings. You might look into (a) editor-specific configuration settings; or (b) cross-editor configuration (i.e. EditorConfig).
But this gets complex and messy. If want a simpler, more flexible way, use this in your .gitignore file:
# .gitignore
Icon?
![iI]con[_a-zA-Z0-9]
Explanation for the patterns:
Use Icon? because the gitignore format does not support \r as an escape code.
Use [iI] because Git can be case sensitive.
Use [_a-zA-Z0-9] to catch many common ASCII characters; you may want to broaden this.
You can test that your gitignore patterns are working as expected with:
git check-ignore -v *
For example, for testing, with these files in a directory:
-rw-r--r--# Icon?
-rw-r--r-- icon8
drwxr-xr-x icons
-rw-r--r-- iconography
... the result of git check-ignore -v * is:
/Users/abc/.gitignore:3:Icon? "Icon\r"
/Users/abc/.gitignore:4:![iI]con[_a-zA-Z0-9] icon_
/Users/abc/.gitignore:4:![iI]con[_a-zA-Z0-9] icons
This is what you want.
Long Term Recommendation This problem would be trivial to fix if Git supported the \r escape in .gitconfig files. One could simply write:
# .gitignore
Icon[\r]
So I suggest we engage with the Git community and try to make this happen.
(If you do want to wade in and suggest a patch to Git, be sure to read first.)
References
From the gitignore documentation:
Otherwise, Git treats the pattern as a shell glob: "*" matches anything except "/", "?" matches any one character except "/" and "[]" matches one character in a selected range. See fnmatch(3) and the FNM_PATHNAME flag for a more detailed description.
Please see This linuxize.com article for good examples of the square bracket syntax and negation syntax in .gitignore files.
For those that want to dig deep and see how pattern matching has changed over time in the Git source code, you can run this search for uses of fnmatch in the git repository on GitHub.
The Icon? is the file of OSX folder icon. It turn out that \r is actually CRLF. So I use ruby to add the line to .gitignore file. Open terminal and navigate to home folder, then:
> irb
>> f = File.open(".gitignore", "a+") #<File:.gitignore>
>> f.write("Icon\r\r") # output a integer
>> f.close
>> exit
For me this worked in TextMate: Icon<CR><CR>. The <CR> is a carriage return character, which is at ctrl-alt-return on the keyboard. You can also find it in the standard Character Viewer app searching for cr. Please note that the <CR> is an invisible character, so it's only visible if the editor is set up to show them.
I'm posting just an update answer because the one above didn't work for me but actually simply adding Icon? in my .gitignore worked. If you look at your name file on your Finder, it is actually how it is displayed.
Icon[\r] did not work for me. I had to use the following in .gitignore...
Icon*
I also added Icon* to my Settings > Core > Ignored Names in Atom...
.git, .hg, .svn, .DS_Store, ._*, Thumbs.db, desktop.inis, Icon*
Add Icon? to your .gitignore file and save it. It should do the job.
Icon?
To avoid wasting time on such trivial issues, I recommend using gibo.
gibo dump macOS >> .gitignore
The result:
### Generated by gibo (https://github.com/simonwhitaker/gibo)
### https://raw.github.com/github/gitignore/e5323759e387ba347a9d50f8b0ddd16502eb71d4/Global/macOS.gitignore
# General
.DS_Store
.AppleDouble
.LSOverride
# Icon must end with two \r
Icon
# Thumbnails
._*
# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk
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.
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.
If I try to autocomplete smth in a Ruby file, that has require 'xxx' statement, it starts to scan all files required (and files required by required files as well). and it does that every freakin time!
Is it possible to make vim autocomplete to NOT scan required files or just files in particular path (e.g. app/ only)?
One of the following should work
:set path=.,/myinclude1,/myinclude2 to set your own include path
:set complete-=i to disable use of included files in default completion
:set include= to unset the include file matching pattern
I would suggest you use the second one, so CTRL-X CTRL-I will still work correctly