I've installed win32yank through chocolatey and changed clipboard setting in init.vim:
set clipboard=unnamedplus
Everything works however I notice that copy and paste operations now have very slight but noticeable delay. Is there any alternative way to copy to system clipboard? (I'm using neovim in WSL2 Ubuntu)
Just remove clipboard option. It's harmful and useless.
What it essentially does, it prepends "quote-plus" to all yank/delete/put commands automatically. Instead of this, manually type "+ when you want to access system clipboard and don't when you don't.
I've expanded on Matt's feedback and put this in my vimrc:
let mapleader=" "
noremap <Leader>y "+y
noremap <Leader>p "+p
noremap <Leader>d "+d
Select a block of text, press and then either y/p/d for yanking, pasting and deleting lines into the system buffer. It automagically seems to work with win32yank.exe (which is in my PATH in WSL2).
Related
So, i've found this page here, showing how to use intellij's idea merge and diff from command line, and i'm trying to set it as a default for hg.
However, i still have some problems when merging branches (many files):
If hg merge is called while there's no idea instance running, it starts a new instance, show the diff, wait for my response (click on apply / abort). After that, it proceeds to the next file, and do the same. File by file. Works pretty well, but is also veery slow (since it needs to start a new instance every time). Also, as said, there must be no idea instance running, to do that.
If hg merge is called while an idea instance is running, it shows the first diff window, but at the same time starts to merge all other files... This end up in a lot of pop-ups of "file not found" on idea, pointing to tmp files (of .other and .original).
Does anybody know how to do that in a usable way? hg merge using idea merge as default ?
Here's my .hgrc file: [ui]
merge=idea
[merge-tools]
idea =
idea.gui = True
idea.args = merge $local $base $other $output
idea.priority = 1000
idea.premerge = False
Sorry for the bad english, and thanks to all in advance
Hi here are the settings I used successfully.
[ui]
merge=idea
[merge-tools]
idea.args = merge $local $other $base $output
Also ensure that idea is on the path.
My references are the mercurial MergeToolConfiguration and Merging files using IntelliJ IDEA as a command line tool.
Idea does not wait, but gives return too early. A good way to solve this problem is to get mercurial to prompt you.
By setting this configuration in the .hgrc
idea.check = prompt
Mercurial will ask for confirmation on each file. You must finish the merge in Idea before clicking "Yes" on the confirmation box.
I've done very little with batch files but I'm trying to track down a strange bug I've been encountering on a legacy system.
I have a number of .exe files in particular folder. This script is supposed to duplicate them with a different file name.
Code From Batch File
for %%i in (*.exe) do copy \\networkpath\folder\%%i \\networkpath\folder\%%i.backup.exe
(Note: The source and destination folders are THE SAME)
Example Of Desired Behavior:
File1.exe --> Becomes --> File1.exe.backup.exe
File2.exe --> Becomes --> File2.exe.backup.exe
Now first, let me say that this is not the approach I would take. I know there are other (potentially more straight forward) ways to do this. I also know that you might wonder WHY on earth we care about creating a FileX.exe.backup.exe. But this script has been running for years and I'm told the problem only started recently. I'm trying to pinpoint the problem, not rewrite the code (even if it would be trivial).
Example Buggy Output:
File1.exe.backup.exe
File1.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
etc...
File2.exe.backup.exe
File2.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
Not knowing anything about batch files, I looked at this and figured that the condition of the for statement was being re-evaluated after each iteration - creating a (near) infinite loop of copying (I can see that, eventually, the copy will fail when the names get too long).
This would explain the behaviour I'm seeing. And when cleaned the directory in question so that it had only the original File1.exe file and ran the script it produced the bug code. The problem is that I CANNOT replicate the behaviour anywhere else!?!
When I create a folder locally with a few .exe files and run the script - I get the expected output. And yes, if I run it again, I get one instance of 'File1.exe.backup.exe.backup.exe' (and each time I run it again, it increases in length by one). But I cannot get it to enter the near-infinite loop case.
It's been driving me crazy.
The bug is occurring on a networked location - so I've tried to recreate it on one - but again, no success. Because it's a shared network location, I wondered if it could have something to do with other people accessing or modifying files in the folder and even introduced delays and wrote a tiny program to perform actions in the same folder - but without any success.
The documentation I can find on the 'for' statement doesn't really help, but all of the tests I've run seem to suggest that the in (*.exe) section is only evaluated once at the beginning of execution.
Does anyone have any suggestions for what might be going on here?
I agree with Andriy M's comment - it looks to be related to Windows 7 Batch Script 'For' Command Error/Bug
The following change should fix the problem:
for /f "eol=: delims=" %%i in ('dir /b *.exe') do copy \\networkpath\folder\%%i \\networkpath\folder\%%i.backup.exe
Any file that starts with a semicolon (highly unlikely, but it can happen) would be skipped with the default EOL of semicolon. To be safe you should set EOL to some character that could never start a file name (or any path). That is why I chose the colon - it cannot appear in a folder or file name, and can only appear after a drive letter. So it should always be safe.
Copy supports wildcard characters also in target path. You can use
copy \\networkpath\folder\*.exe \\networkpath\folder\*.backup.exe
How do I navigate the MiniBufExplorer without going into the MiniBufExplorer window?
In lines 170-174 of minibufexpl.vim:
" To enable the optional mapping of <C-TAB> and <C-S-TAB> to a
" function that will bring up the next or previous buffer in the
" current window, you can put the following into your .vimrc:
"
" let g:miniBufExplMapCTabSwitchBufs = 1
I added that to my .vimrc, restarted a blank Vim, then did the following commands to bring up multiple buffers (and consequently, the MiniBufExplorer):
:e somefile
:e someotherfile
Now, with my cursor inside the file window (not the MiniBufExplorer window), I try CtrlTab and CtrlShiftTab to no effect. Something I missed?
I think this is most likely a conflict with snipMate, which I believe you have since you mention the tab mapping works in select mode. I tried to do it manually map <C-Tab> :bn<cr>,
and it did not work either. I now use map <C-P> :bp<cr> and map <C-N> :bn<cr> to navigate through buffers, and I suppose other mappings would work just as well as long as there is no conflict.
Minibuf explorer shortcuts (may require additional configuration):
[C-TAB] and [C-S-TAB] - move to next and prev buffers
Vim regular buffer shortcuts:
:bn and :bp - move to next and prev buffers
:b# - move to buffer of number #
:h :buffers - for additional help
Did you leave the " at the beginning of the let line? If so, it's commented out, and will not work. Otherwise, you may have a mapping conflict between plugins. The :map command will list current mappings.
It's easier to deal with mappings if you install headlights though.
I'm trying to start the process Store.Client.UI.exe which is located at: "C:\Program Files\Intel\IntelAppStore\bin\Store.Client.UI.exe", or "C:\Program Files (x86)\Intel\IntelAppStore\bin\Store.Client.UI.exe" for 64bit like me, so I use the code:
If My.Settings.instpathtype = 86 Then
Process.Start("C:\Program Files\Intel\IntelAppStore\bin\Store.Client.UI.exe")
Else
Process.Start("C:\Program Files (x86)\Intel\IntelAppStore\bin\Store.Client.UI.exe")
End If
Where my.settings.instpathtype is whether the computer is 64 or 32 bit. But when I run it, it doesn't run Store.Client.UI.exe for some reason. When I go into Explorer and type "C:\Program Files (x86)\Intel\IntelAppStore\bin\Store.Client.UI.exe" it runs Store.Client.UI.exe. What's wrong?
From the code that you posted, I don't know where/how you're getting the value for instpathtype, or what type it is declared as.
But regardless, you really shouldn't be doing it this way. Hard-coding paths to the file system is a very bad practice if you want your code to "Just Work." What you posted above will not only break depending on the bitness of the OS, but also if the user has renamed or moved their Program Files folder. If my boot drive is E:, your code will fail on my computer as well.
Instead, you should be using the special system folders. That way, you don't even need to check whether you're running on a 32-bit or 64-bit operating system. The .NET Framework provides a really easy way of getting at these values with the Environment.GetFolderPath method, and specifying the type of folder you want to retrieve.
In this case, you want the 32-bit Program Files folder, regardless of the host OS's bitness, so you can use the ProgramFilesX86 value to retrieve the appropriate folder, like so:
Process.Start(System.Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86) & "\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
When you are encountering problems like this, debugging comes in. Try to display what My.Settings.instpathtype outputs, by a simple MessageBox or similar. If your testing machine is 32 bit, and if the output is different from 86, change it.
EDIT: So I guess you have a 64 bit machine? Try it the other way around. Swap the statements under If and Else, then put My.Settings.instpathtype's output at the condition.
EDIT: If there are no errors on the condition, then it might be because \ is being read as an escape character. You can fix it by adding another \ before it.
If My.Settings.instpathtype = 86 Then
Process.Start("C:\\Program Files\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
Else
Process.Start("C:\\Program Files (x86)\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
End If
It's possible the process is starting and then exiting immediately with an error. Use the return process from Process.Start and check some of its properties, such as proc.exitcode, proc.starttime, and proc.exittime.
dim proc as process
...
proc = Process.Start("C:\\Program Files\\Intel\\IntelAppStore\\bin\\Store.Client.UI.exe")
I am trying to make elinks dump the web-page at the URL which starts at the current buffer position in vim (and ends at EOL), by mapping this keyboard shortcut and putting it in my .vimrc:
nmap owp :norm yE \| new \| .!elinks -dump #"<CR>
This yanks the rest of the line into the " register. Then it's supposed to open a new buffer and invoke elinks which should dump the rendered web-page into this new buffer. When I run the command the URL gets yanked, and that's it. New buffer does not open and elinks does not get invoked.
What am I doing wrong here?
Is there a smarter way to yank URLs
under the cursor? This method won't
work for URLs which occur in the middle of the line.
Never mind. Dug around in the vim manual and found some workarounds. One problem was with this:
.!elinks -dump #"<CR>
this won't work as expected. Everything after ! operator is passed to the shell verbatim by vim - so the register value will not be passed to elinks. Another problem is that the command separator somehow is not working after :norm yE. The final solution to get around these problems was this:
function! Browser ()
normal yE
new
execute ".!elinks -dump " . #"
set nomodified
endfunction
nmap owp :call Browser ()<CR>
Notice the use of execute to get around the limitation of "!" operator. I still need to figure out a solution for question 2 though.