I want to change all source file's type from txt into utf8.
In Perforce, can change all .h, .cpp files in subfolders?
I can't find menu at P4V.
I don't think you'll find this option in P4V, but at the command line you can do:
p4 edit -t utf8 ....h
p4 edit -t utf8 ....cpp
Check out folders
Select all files
Right click -> Change Filetype -> Change base filetype and/or file attributes -> change Base Filetype as utf8.
If there are too many files, pending list doesn't show files, then
Click on "Server Data" and you'll see a setting labeled "Maximum number of files displayed per changelist*:" Raise that to 4000+ and you should see all those files.
Related
I am using vim to edit .sh file. Last time, I was making changes I got: "E297: Write error in swap file" and I accidentally managed to erase the content and save.
Now, all I have is .sh .sh~ .su~ .sv~ .sw~ .sy~ .sz~ files with empty content and "E297: Write error in swap file" message. When I do :u, it says: "already at oldest change".
when I do :recover, it says: "E305: no swap file found"
How to recover my file? thanks
In this case, the original file may be recovered using swap files which have the form .filename.sh.swp. These are files that Vim creates to back up in case of a potential crash. In order to recover your original file, try these steps:
Look for swap files in the current directory (there could be more than one for a particular file):
ls -a
Open the first swap file in Vim from the terminal:
vi .filename.sh.swp
or alternatively, launch Vim with vim and edit the swap file with :e .filename.sh.swp.
From within the swap file type :recover. Now Vim will load the recovered file on a new buffer. If this is the file that you needed then simply save the file :w.
It could be that the recovered file is not exactly the latest version of your filename.sh, in this case repeat steps 2 and 3 above with a different swap file e.g. .filename.sh.swo. Once the desired file has been recovered removed the swap files.
These help pages are also relevant for recovering files:
:help swap
:help recover
:help e305
nerdtree allows navigation through the file system within vim and performing file system operation like creating and deleting files and directories.
Is there any command to see file metadata like timestamp, owner or permissions, as a unix ls -l command would output?
This is an explicit answer. You can find the answer if you dig into the comments from Ingo Karkat's answer.
Open Nerdtree
Move to the specific file or directory
Press the keys m and l
92 represents the filesize in bytes.
There's nothing built-in (as NERDTree is mainly a file explorer for locating and opening files within Vim, this isn't a typical use case), but you can surely build something like that through the plugin's extension points.
:help NERDTreeAPI documents how to define custom key mappings and menu items. As these get passed the current tree object, you can then query and display the metadata, e.g. using
let metadata = system('ls -l ' . shellescape(filespec))
The CSS3PIE .htc filetype in Perforce seems to cause issues when requesting the latest version. Changing the filetype from Text to Binary directly in Perforce fixed the problem.
Out of curiosity, does anyone have an idea why the PIE.htc format causes these problems? Could it be the encoding, the filetype, or attributes? If PIE.htc file type is set (as happens by default) to text in Perforce, it won't work when you try to submit it.
I don't know what a '.htc' file is, but if you want all your '.htc' files to be treated as binary files by Perforce, rather than as text files, you can use the Perforce 'typemap' feature to do this: use 'p4 typemap'.
This blog: http://blogs.encodo.ch/news/view_article.php?id=79 has a nice writeup.
Generally, the reason you do this is that Perforce tries to normalize the line ending characters for text files, so that the files are a single line-end on Unix computers, but are carriage-return/line-end pairs on Windows computers.
And if your filetype contains 0x0a characters, but it is NOT a textual data type and these characters do NOT indicate line ends, then turning them into CRLF pairs will mess you up.
So then binary is the better filetype for such files.
I'm moving from Textmate to vim (with janus) and want to exclude some directories from Ack in particular, and also NERDTree.
The reason I want to do this is that Ack is useless (takes minutes to run, and produces no results) with one of my large projects which contains a directory full of marshalled db data (with many subdirectories and hundreds of thousands of files).
I know how to exclude files (not directories) from NERDTree, and also exclude patterns from CommandT. Neither of these solve my Ack issue.
I'm a complete vim n00b. Thanks for reading.
By default, ack only checks your ~/.ackrc file for it’s default
switches. You can have per directory ack settings if you add this to
your .bash_profile:
export ACKRC=".ackrc"
http://www.rustyrazorblade.com/2012/03/making-better-use-of-your-ackrc-file/
For NerdTree, use NERDTreeIgnore setting.
as for Ack - you can set --ignore-dir flag in your .ackrc (as explained in Ack's man page)
I only had to create a .ackrc in my top directory with the following:
--ignore-dir=log/
I would like to *.pyc files not to be shown in NERDTree vim plugin.
How to achieve that?
You want the NERDTreeIgnore option. For example, in your .vimrc:
let NERDTreeIgnore = ['\.pyc$']
Where NERDTreeIgnore is an array of regular expressions that match the files you want to exclude.
Just ran into the problem: What about hiding binary files that do not have an extension?
Can't hide them, but can sort files to eliminate some cheesy clutter. Problem looks like:
file1*
file1.c
file2*
file2.c
Solution:
let NERDTreeSortOrder=['\.c$']
Result:
file1.c
file2.c
file1*
file2*
which will sort first the files ending with ".c" (followed by some other extension if you want). You don't get rid of the binary files, but it becomes manageable.
NERDTree has a mechanism to detect and highlight files with the extra execute bit, where -rwxr-xr-x displays in bold with a "*" at the end of the filename. It would not be hard to add an extra mechanism to hide executable files (useful for compiled stuff, not so desirable for scripts).