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.
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.
(Not sure if this belongs on superusers, but it seems there is a cmd.exe tag here, so here goes...)
As background, I'm working on a Firefox add-on (This question does not require knowledge of Firefox, btw, as Firefox add-ons can call the command line.) The add-on aims to build different kinds of shortcuts to cmd.exe (especially for the sake of my project https://github.com/brettz9/webappfind which allows files to be opened directly from the desktop into web apps).
Anyways, I'd like to give users the option to associate these shortcuts:
As the default handler for specific file extensions or file types.
To show up within the Open With list of applications (even if the user opts not to make the apps as default handlers)
As far as the default handling, I have found the ftype and assoc (and associate) commands, but I have read that user selections will override their behavior. Is there some way to ensure that I can get priority from the command line in associating file extensions to types and specific executables (until the user changes it again), or if it is not possible, then at least through C++ or the like?
As far as the Open With list:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\<file extension>\OpenWithList
...in my testing (with an exe), this command:
reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.svg\OpenWithList /v d /d D:\wamp\www\webappfind\cplusplus\WebAppFinder-view-mode-Firefox.exe
...did cause the exe file to show up in:
reg query HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.svg\OpenWithList
...but it did not show up when I subsequently right-clicked a file with the ".svg" extension.
I would really appreciate any help with these two points.
REGEDIT4
[HKEY_CURRENT_USER\Software\Classes\Applications\MYFOO.exe\shell\open\command]
#="\"C:\\MYFOO.exe\" \"%1\""
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.myfoo]
"Application"="MYFOO.EXE"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.myfoo\OpenWithList]
"a"="MYFOO.EXE"
"MRUList"="a"
So I got to an investigation what makes those file associations. It appears that you have to create a mapping from the bare EXE name to the full path as shown in the first two long-ish lines. Then you must only use the EXE name in the .extension branch. Setting the .extension's Application value will give you your default app instantly. Remember, only use APP.EXE, its full path must be defined as above. This was your main error. The "%1" part allows you to customize the parameters of your program so that it doesn't have to be just the opened document in quotes, as shown here. The backslashes are just escape characters for Regedit, you may discard them as you see fit.
The OpenWithList is tricky in the sense that there are letters for entries and just a blind write may overwrite some of the user's favorite apps. One approach would be to call your item "z" to lower the probability of overwriting. The right way would be enumerating the key and giving your app the first free letter. The MRUList is not essential, although it should have each used letter once and yours bumped to the start.
Note about user friendliness: Explorer will cache these values until next reboot. Make sure you update the registry and place exe first and create your file later. Although the caching only fully influences the display of the file and when it is run, the registry is read again and it will execute as you want.
TIP: If you decide to use Regedit instead of reg, the /s parameter skips the confirmation message and applies the values right away. Make sure you use double backslashes in the full path as shown. When preparing your temporary .reg file, make sure you append two CRLF's to the end or a glitch may cause your last line of code to be ignored. This sample starts with REGEDIT4 which signifies an ANSI file. If you need support for Unicode in your app path, you'll have to start the file with Windows Registry Editor Version 5.00 and store it in UTF16. This is already a superior solution to calling reg because there's no way you could get CMD.EXE to process special UTF stuff through the command line without mangling.
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.
I want to hide a bat file or its commands in a image file so when the image is opened the commands in the bat file is executed.
Assuming you're speaking specifically for the windows platform (what with "batch" files), you can't.
Batch files are parsed, not compiled, so an image file with batch in it would still be read as an image file.
I really can't sum it up more clearly than things just don't work like this.
However, assuming you're doing things ethically, you can re-associate, say, a .jpg extension to be opened with the command prompt and put your batch script in a text file with a .jpg extension.
Just a final note: Questions like these are often looked poorly upon by the StackOverflow members simply because you're hardly ever trying to achieve something like this with good intentions. I won't be the first to flame you, but I definitely won't be the last.
There are a number of ways in which a single file can contain two distinct streams of data which are independent of, and don't interfere with, each other. One commonly cited example of this is how it is possible to append a .zip file to a .jpg file and still have the combined file function as both types of files, depending on what sort of application is opening it. This trick takes advantage of the specific way jpeg and zip files are structured. These sorts of files are akin to polyglot program.
Another common method of embedding unrelated information into a file is steganography, which is the concealment of messages within mundane objects (like an image file.)
You might also consider using an Alternate Data Stream, though in such a case the batch file would arguably not be embedded in the image.
Once you have your batch file embedded, by whatever means, you must then find a way to cause the batch file to be run instead of--or in addition to--whichever image-viewing application the user has configured.
It can be safe to assume that the average user does not expect a file ending in .jpg (for example) to open a cmd.exe window and start executing unknown instructions. Windows Explorer, the application which under most circumstances decides what program to run when a certain file type is double clicked, has sane defaults (i.e. a .jpg file gets opened with an image viewing application) though these can be changed (though users generally don't change these sane defaults to insane customizations like cmd.exe.)
The simplest method would be to write your own handler program and cause it to become the default handler for image file types. I believe that all handler applications must be compiled PE application or library files (.exe, .dll, .scr, etc.) so another batch file won't work here. Your custom handler must reverse the embedding to retrieve the embedded batch file and then execute it with cmd.exe.
But if you've already managed to supplant the default handler with your own code then the embedded batch file is moot since you've already got your code running.
I have to echo what #Di-0xide said about this question. If you're trying to write a legitimate application and this is part of your design plan, then you need to go back to the drawing board because no legitimate application should ever do this sort of thing.
Although there are no doubt many more malace reasons why someone would want to embed a batch file within an image,
and have it execute when the image is opened. I can see at least one legitimate reason for wanting to perform the task.
What if you have a family computer, shared with your 2 kids, the wife, and yourself. Lets say you have some files you don't
want your children to come across, or a directory full of journal entries. It would be pretty neat if a simple batch file that would
change the attributes settings of the directory, containing the sensitive files. This way a parent could rest assure that their
kids wont stumble upon dads nudie pics. LOL
IE: Lets say someone wrote 2 simple batch files s.bat(to show the directory) and h.bat(to hide the directory)
hide.bat
#echo off
REM Show the directory containing sensitive info:
attrib +a +s +h +r C:\path\to\the\directory\to\hide
REM Hide this batch file(or image containing the batch file):
attrib +a +s +h +r C:\path\to\the\batch\files\hide.bat
REM Show a batch file(or image containing the batch file) that will allow for showing the directory:
attrib -a -s -h -r C:\path\to\the\batch\files\show.bat
show.bat
#echo off
REM Show the directory containing sensitive info:
attrib -a -s -h -r C:\path\to\the\directory\to\hide
REM Show the batch file(or image containing the batch file) that will allow user to hide directory:
attrib -a -s -h -r C:\path\to\the\batch\files\h.bat
REM Hide this batch file(or image containing the batch file):
attrib +a +s +h +r C:\path\to\the\batch\files\s.bat
I think it would work better having images that would execute the show.bat and hide.bat batch files, rather than just changing the icon on each batch file.
Perhaps writing a handler program that would change the attributes of the directory then open the image and associate the handler to some unused extension, would work.
Just a thought.
Simplest way to do this is to just create your batch file as normal and then create a desktop shortcut of the same batch file. Finally right-click on the shortcut and change the icon to what ever image you want. Once all changes are made then anytime the image is opened, the batch file will run.
This is easy just use winrar archive to embed bat file in image. This will run bat file before image or you can change settings to run image file before bat.
Follow this tutorial to do so:
https://www.youtube.com/watch?v=ytvKVYYrqEw
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...