Warning: first-time Vim "user"
I'd like to make the GUI font much bigger.
It is installed on a modern windows 32-bit machine.
I've used the Edit menu and found a good font using Select Font...
Then I entered the command:
set gfn?
To return ...
guifont=Consolas:h16:cANSI
Now apparently I need to add something to my vimrc file. I think I have found the file here?:
So why am I now struggling to make the changes?
Whichever way I try (notepad or via Vim>Open) to open this file it seems to be read-only.
I assume once open I need to add something like the following at some point(?) in the file?
if has('gui_running')
set guifont=Consolas:h16:cANSI
endif
Because your _vimrc lives under Program Files, Windows is trying to protect you from potentially damaging the system (and is preventing potentially malicious programs from doing the same).
In order to edit your _vimrc, you need to be running Vim as administrator. Right-click the gVim icon and select Run as administrator from the menu. You should then be able to edit the file.
You'll probably want to make lots of other changes to this file over time; you'll have to remember always to edit it as administrator.
I don't know much about the windows platform, but it seems that you were editing the system vimrc. try to start (g)vim, and type :e $MYVIMRC this should be user-lvl. usually under $HOME
write the setting you want there, and save.
or you could in vim, :echo $HOME, to see which dir is your HOME. then create the _vimrc file there.
Related
I want to increase the default font Lucida Console from 9pt to 12pt and adjust the blue color quality. Currently the only way I can find to do it is by right-clicking the Cygwin window and selecting Options & Text and Apply as described in this answer.
I tried to edit .minttyrc to change the font size and color as suggested here. Settings are shown below. But when I relaunch the Cygwin shortcut the default window reappears.
C:\cygwin64\home>cat .minttyrc
FontHeight=12
Blue=127,127,255
BoldBlue=191,191,255
Is there a way to set .minttyrc programmatically ? Surely there is a way to change the default settings without doing this manually every time.
EDIT.
I have Cygwin configured like this ( a screen shot of the window opened by the DOS batch file).
Here is the code suggested by me_and
C:\cygwin64\home\Greg\Work\CMI>cat ~/.minttyrc
cat: '~/.minttyrc': No such file or directory
I can get .bashrc to find .CMI_functions in a sub-directory but I don't know how to get it to find .minttyrc in the same directory
CONCLUSION.
Best results came from editing the Cygwin batch file to relocate all .executable bash files, together with .minttyrc, into C:\cygwin64\home\%USERNAME%.
cd %USERPROFILE%\Desktop\Archive\UTIL
xcopy . C:\cygwin64\home\%USERNAME%\Work\CMI\UTIL /E /I
copy Misc\* C:\cygwin64\home\%USERNAME%\Work\CMI
copy Bash\.* C:\cygwin64\home\%USERNAME%
copy Scripts\*.sh C:\cygwin64\home\%USERNAME%\Work\CMI
The Super User question you've linked to talks about putting the .minttyrc file as ~/.minttyrc, which as a Windows path (at least with default settings) would be something like C:\cygwin64\home\Greg\.minttyrc, but you have it as C:\cygwin64\home\.minttyrc. That's the wrong place, so it's never going to work.
To change the settings for Mintty, you need to have the file in the right location, otherwise it won't be able to load them. Try moving the file to the correct location, and see if that resolves things for you.
I am trying to use Jedit as an external editor to 7zip.
7zip opens Jedit as external editor however edits are only saved back if Jedit was not running previously. I probably should pass -noserver or -newview command line arguments to Jedit as an external editor, but when I do that 7zip gives an error: 'Cannot start editor'.
How could I use Jedit as an external editor to 7zip so that edits are saved back?
You cannot give arguments to the programs you configure in 7-Zip.
What you need to do is to create a batch file that you call from 7-Zip that sets the options you want to have and that forwards all other arguments.
What you do NOT want to do is to use the -noserver option without a -settings option if a jEdit instance is already running. Currently jEdit does not behave nice if you start two really separated instances in the same settings directory, as the first that writes a specific settings file after the second instance is started "owns" it and the other just does not save it anymore, so your positions, recent files, changed settings etc. will not be persisted and there is no prominent warning about this.
What you DO want to do is to use the -wait option, that is present for exactly those cases.
So create a file jedit-wait.bat (e. g. in the jEdit installation directory) with content #jedit -wait %* and then configure that batch file as 7-Zip editor. That is also how I have set it up and it works exactly like expected. The only slightly unnice thing is, that you will have a black command line window sitting there as long as you edit the file, but that is not as disturbing as it sounds, at least to me.
I have perl scripts which were running in Windows 7 just fine as of this morning. I made the mistake of using NotePad as the default for opening/editng my .pl files. Now, when I attempt to run the unedited .pl files from a DOS prompt, the script does not execute but opens the associated source code file in Windows Explorer. This is the same for all my .pl files no matter the complexity (including classic "hello world".
I have been researching changes need to the registry - it all looks fine. Tried assoc and ftype changes - nothing. Tried reinstalling ActivePerl - no solution.
You don't need to go into the Registry.
Go into Windows Explorer.
Find a file that ends in a *.pl suffix.
Right click on it and bring up the Context menu.
Select "Open With" (It might just be Open... with an ellipse after it. I don't have a Windows machine at the moment to verify this). This will bring up a dialog box with all the various programs. NOTE: Perl may not be listed in the initial set of programs. No worry, just navigate to it.
On the bottom of the dialog box is a checkbox (Something like open all extensions with this program). Make sure that checkbox is checked.
After this, all files that end with *.pl will open with Perl instead of Notepad.
It is highly likely that someone did this with a Perl script in order to edit it, and messed up the file association.
However, who ever did this should be doped slap -- not for messing up the file association, but for editing a program with Notepad. Bad Developer! No doughnuts for you!
Programs should be opened with a Program Editor. If you're a real he-man, you can use VIM. VIM is a fast, and powerful program editor, but you will need to spend an internship at the feet of a VIM Ninja master in order to learn how to use it. Your first three to six months with VIM will be What a idiotic program! This is awful. Who wrote this crap?. Then, one day, you will understand its power and efficiency. You will be one with the program.
If you aren't brave or fearless or don't have six months to waste learning a programming editor, you can use Notepad++. Compared to VIM Notepad++ is like driving a Minivan. It's safe, it's practical, and it gets the job done.
Both editors do Syntax Highlighting which can help you find issues. Both, (VIM can -- I think Notepad++ can too) offer help with syntax and usage. Both can edit a file without messing up the line endings (They'll both detect whether a file has Unix or Windows line endings and keep those or allow you to convert them). Both will number your lines, have extensive cut/paste buffers, powerful search and replace features. And will not mess up your file encoding. Both offer visual diffing between files and do automatic backups when you edit a file.
Finally, these two editors will embed themselves into the context menu you get when you right click on a file. You can edit a file by clicking on it, and selecting VIM or Notepad++ directly from the context menu. No need to select "Open with..." and possibly mess up the file suffix association.
Never ever use Notepad to edit a program.
Sounds like your .pl extention association is now set to Notepad rather than perl.exe. If you are too busy to fix that, just type "perl yourscript.pl" in a command promot window to start the perl interpreter and to send your script to it to run.
See this answer to fix the association:
File Type .pl Association and Using cmd.exe to Run the Script
I have the same problem. None of the method mentioned above solve the problem. The problem actually came from Windows 7! Windows 7 Doesn't allow you to associate .pl to perl.exe in c:\Perl64 directory, for whatever reason.
Here is the solution:
If you look at c:\Perl64\Bin directory (or the path where your ActivePerl binary installed), you'll see another file: Perl5.14.2.exe. This is the same file as perl.exe in same directory but with version number attached as postfix in the name.
You can associate .pl file to that Perl5.14.2.exe instead of perl.exe. Bingo, it works now.
On Windows, I normally work with Total Commander, which can easily be configured to ignore these *.*~ and *~ completely. But occasionally when I switch to Windows Explorer, I get little bit confused with all that "unknown" files/.
Can I set up Vim so that for every backup it creates it will also set "hidden" attribute?
Or set up some nice workaround?
I know I can set up Vim to put these in other directory, but I'd like to avoid that, since IIUC, it could suffer from naming conflicts.
If the backup option is set, vim updates the backup file every time we write the file with :w. And every time, it creates a file which is not hidden even though you had forcibly hidden it previously! So we need to do something everytime we write the buffer into file.
You can do this on windows. In your _vimrc file ( generally found at C:\Program Files (x86)\Vim ), add this line
autocmd BufWritePost,FileWritePost * silent ! attrib +h <afile>~
Where,
attrib=Windows File attribute changinf command
<afile>= Name of the file being sourced
silent= Prevent an annoying command window from popping up and asking user to press a key
This will make sure that the backup file gets hidden with every write to file from buffer. Why every time? Cos vim creates a non-hidden file at every write!
But you have to live with a flashing black window ( command window where we are running attrib command ) every time you save your file, but worth the pain :)
On linux/unix systems you can add this in your .vimrc
autocmd BufWritePost,FileWritePost * silent ! mv <afile>~ .<afile>
Hope this helps all those trying to find how to hide vim backup files.
I wrote a plugin for this a while back called autohide. It works by setting the "hidden" attribute after write as suggested in Pavan's answer. By default it only does this for swap files, viminfo, and persistent undo files; you can make it only hide backup files by configuring let g:autohide_types='b' in your .vimrc, or add it to the default list instead with 'suvb' instead of just 'b'.
Benefits over the manual method in Pavan's answer include handling of additional file types, arbitrary file patterns (like dotfiles), and some error handling (especially related to slow network shares that don't allow setting attributes right away after creating a file).
I have this in my _gvimrc:
set nobackup
No backup files are generated in the first place.
However, the swap file (.*.swp) is still generated during editing (and deleted when you close Vim). So if your computer crashes, you can still recover your changes.
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...