Setting ft=vb causing vim's parenthesis matching to stop working - vb.net

I'm having a weird issue in which I can't get parentheses to match in VB files in vim or gvim.
For example, if I start vim and insert Iif(test, 0, 1), I can use % to jump between the two parentheses like normal. Then if I run :set ft=vb, it stops working. Actually, I get one more jump, then it stops working.
I have tested this on two different machines running Windows and Linux and I get the same results.
Does anyone know why this might be?

You're using the matchit plugin that comes with Vim. In $VIMRUNTIME/ftplugin/vb.vim, it defines custom pairs (e.g. If...End If) which override the default pairs. To re-enable those (in addition), put the following into ~/.vim/after/ftplugin/vb.vim:
let b:match_words .= ',(:)'
Cp. :help b:match_words.

Related

How to have special/accented characters support in IntelliJ terminal

I use the IntelliJ IDEA's Embedded Local Terminal quite a lot, but there is one thing that is driving me nuts : special and accented characters do not work.
This is what should but is not working :
HOME key to go to the beginning of the line : does nothing
END key to go to the end of the line : does nothing
[CTRL + left arrow] to go to previous word : prints D
[CTRL + right arrow] to go to next word : prints C
all accented characters : prints nothing at first, then ? when I hit another key
There are probably other combinations that should but do not work ... but these are the most annoying ones.
I'm using :
Ubuntu 16.04 virtual box guest running on a Windows 10 host
IntelliJ IDEA 2016.2.4
zsh
oh-my-zsh
Important notes :
in a GNU Terminal (outside of IntelliJ then) everything works perfectly, so I don't think that the "running inside a VM" thing is the source of the problem.
if I run bash instead of zsh the special characters are working (home, end, next work, etc...) but I still don't have propre support of accented characters (prints �), and I'd really prefer using zsh.
showkey --scancodes prints Couldn't get a file descriptor referring to the console
if I start od -c I get ^[[H for the HOME key and ^[[F for the END key
showkey --ascii works and prints ^[[H too for the HOME key
What I did already :
checked that the TERM variable is not overridden in .zshrc
add bindkey "${terminfo[khome]}" beginning-of-line and end of line equivalent in .zshrc
add lines (that seemd appropriate) in .inputrc for readline (OK I see now that this was useless as Zsh does not use readline)
edit : I could make the home/end keys work (see accepted answer below), but not the CTRL+LEFT and CTRL+RIGHT key (for forward-word and backward-word). After some more digging this seems to be an issue with IntelliJ not 100% properly emulating the terminal. 4
There is an issue here, with interesting input from an oh-my-zsh contributor : https://youtrack.jetbrains.com/issue/IDEA-118848#comment=27-1292473
They consider ditching smkx (which appears to be the root of the problem) from oh-my-zsh soon. I've checked out this PR and now my keys work fine (still need the bindings, but CTRL+LEFT and CTRL+RIGHT are ok now)
edit: accented/special characters are now properly supported in IntelliJ (yeehaa !), be sure to have at least the following version : IntelliJ IDEA 2016.3.1, Build #IC-163.9166.29, built on December 9, 2016
I can appreciate that zsh works fine outside IntelliJ.
Step 1
Find the correct key codes being used by the terminal inside Intellij. This will depend on the OS you are using. For OSX and Linux od -c followed by pressing the keys will result in the key code being emitted.
Step 2
Once you have the keycodes, modify your ~/.zshrc :
bindkey "$HOME_KEY_CODE_FROM_STEP_1" beginning-of-line
bindkey "$END_KEY_CODE_FROM_STEP_1" end-of-line
for example (as was the case for the OP):
bindkey "^[[H" beginning-of-line
bindkey "^[[F" end-of-line
and restart the terminal.

Renaming a Yakuake session from commandline

Yakuake provides a hotkey and a GUI way to rename commandline tabs/sessions.
I'd like to do the same via the command line, so I can script it and use it in an alias. (My goal is that if I use an alias which does an SSH to some server, then the tab is renamed according to this servers name...)
I tried the suggestions shown here Renaming a Konsole session from commandline after ssh so far no luck.
Since KDE4, one should use qdbus to control KDE apps (instead of deprecated and deleted DCOP).
For example, to change a title of the first session one may use:
qdbus org.kde.yakuake /Sessions/1 org.kde.konsole.Session.setTitle 1 "New title"
To explore available interfaces, methods and properties one may use qdbusviewer.
As a homework try to get a list of active sessions (before you going to change smth).
Like #fgysin pointed out, his command also works for me. BUT it needs the ` character and not " for the subcommand :
qdbus org.kde.yakuake /yakuake/sessions org.kde.yakuake.activeSessionId
It gives :
qdbus org.kde.yakuake /yakuake/tabs org.kde.yakuake.setTabTitle `qdbus org.kde.yakuake /yakuake/sessions org.kde.yakuake.activeSessionId` "NEW TAB TITLE";

Zsh trouble when using echo with color/formatting characters

I'm just switch to zsh and now adapting the alias in which was printing some text (in color) along with a command.
I have been trying to use the $fg array var, but there is a side effect, all the command is printed before being executed.
The same occur if i'm just testing a echo with a color code in the terminal:
echo $fg_bold[blue] "test"
]2;echo "test" test #the test is in the right color
Why the command print itself before to do what it's supposed to do ? (I precise this doesn't happen when just printing whithout any wariable command)
Have I to set a specific option to zsh, use echo with a special parameter to get ride of that?
Execute the command first (keep its output somewhere), and then issue echo. The easiest way I can think of doing that would be:
echo $fg[red] `ls`
Edit: Ok, so your trouble is some trash before the actual output of echo. You have some funny configuration that is causing you trouble.
What to do (other than inspecting your configuration):
start a shell with zsh -f (it will skip any configuration), and then re-try the echo command: autoload colors; colors; echo $fg_bold[red] foo (this should show you that the problem is in your configuration).
Most likely your configuration defines a precmd function that gets executed before every command (which is failing in some way). Try which precmd. If that is not defined, try echo $precmd_functions (precmd_functions is an array of functions that get executed before every command). Knowing which is the code being executed would help you search for it in your configuration (which I assume you just took from someone else).
If I had to guess, I'd say you are using oh-my-zsh without knowing exactly what you turned on (which is an endless source of troubles like this).
I don't replicate your issue, which I think indicates that it's either an option (that I've set), or it's a zsh version issue:
$ echo $fg_bold[red] test
test
Because I can't replicate it, I'm sure there's an option to stop it happening for you. I do not know what that option is (I'm using heavily modified oh-my-zsh, and still haven't finished learning what all the zsh options do or are).
My suggestions:
You could try using print:
$ print $fg_bold[red] test
test
The print builtin has many more options than echo (see man zshbuiltins).
You should also:
Check what version zsh you're using.
Check what options (setopt) are enabled.
Check your ~/.zshrc (and other loaded files) to see what, if any, options and functions are being run.
This question may suggest checking what TERM you're using, but reading your question it sounds like you're only seeing this behaviour (echoing of the command after entry) when you're using aliases...?

Inconsistent Behavior In A Batch File's For Statement

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?

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.