(Note: not off topic per Is it appropriate to post vim questions on Stack Overflow now that there is a vi/vim site?)
On my mac using vim version:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 10 2016 10:50:34) MacOS X (unix) version Included patches: 1-1219
when I am in visual mode, select a block of text, then click x, the text is removed but the whitespace remains. Here is a video: https://vimeo.com/176318393
similarly, when I paste using "+p (pastes from the system clipboard), the text overwrites whatever is on those lines and does not "bump" down the text being pasted. Video: https://vimeo.com/176319290
I want to solve these two problems but I have a hunch they are related so I am posting them in one question here.
A subset of my vimrc (vimrc is massive but nearly positive the plugin stuff has nothing that could affect this) that handles generic settings is here: http://pastebin.com/2APD1ycp
What is wrong?
The behavior shown in both videos is perfectly normal and expected in visual block mode.
You have visual mode and visual line mode at your disposal so, if you don't want the behavior of visual block mode… don't use it.
Related
In the VS Code editor window, there are squares of another color that bother me when coding.
Has anyone had or has the same problem?
I started experiencing this issue in my MacBook Pro M1 after the June 2022 autoupdate.
Setting "disable-color-correct-rendering": false in ~/.vscode/argv.json worked for me.
I hope this is fixed in the next release. It seems to be an old issue based on what I found when searching for a solution.
If you are on a mac, see Different colored area on macOS - although there is a linux report there too. Same dark grey patches of color. There are a couple of suggested fixes mentioned.
The most reliable appears to be changing this setting:
"disable-hardware-acceleration": true
Open command palette and search for "Configure Runtime Arguments"
Set "disable-hardware-acceleration": true
Restart
from https://github.com/microsoft/vscode/issues/156405#issuecomment-1196503399
or starting vscode from a terminal with code --disable-gpu.
Also
What did work is removing "disable-color-correct-rendering": true from
~/.vscode/argv.json file and restarting vscode. Now the different
coloured patch on the side and bottom is gone.
Or
This happens to me with an intel mac as well. It was fixed by setting
"disable-hardware-acceleration": true in the .vscode/argv.json file.
More from the issue:
Had the same problem on my M1 macbook air, I had to open the argv.json
file (you can use Shift + CMD + P and type Configure Runtime Arguments
to open it) and set this line to false :
"disable-color-correct-rendering": false (it was on true, maybe by
default).
After that, just close your VS Code instance with CMD + Q and restart
it.
And here are download links (for macOS) for the previous vscode version v1.68 in case you want to rollback:
https://az764295.vo.msecnd.net/stable/4af164ea3a06f701fe3e89a2bcbb421d2026b68f//VSCode-darwin-universal.zip
https://az764295.vo.msecnd.net/stable/4af164ea3a06f701fe3e89a2bcbb421d2026b68f/VSCode-darwin.zip
https://az764295.vo.msecnd.net/stable/4af164ea3a06f701fe3e89a2bcbb421d2026b68f/VSCode-darwin-arm64.zip
Thanks for the information to those posting in the issue comments.
if you are facing this on mac you have to follow following steps
open terminal and type cd ~/.vscode
then open 'argv.json' file using vim argv.json
just uncomment the line // "disable-hardware-acceleration": true to "disable-hardware-acceleration": true
quit vim Esc then shift+: then wq then press enter, restart vs code your vs code will work normal again.
Visual Studio (the full-fat version, not Visual Studio Code) and SQL Server Management Studio both feature editing commands that emulate (replicate? reimplement?) UnderWare Brief and Emacs (but not Vim, hmpf!)
In the IDE's Tools > Options > Keyboard Shortcuts window, the Brief-emulation commands have the prefix Edit.Brief... and the Emacs-emulation commands have the prefix Edit.Emacs...:
I was setting up some custom shortcuts of mine (as I like to bind Ctrl+E to Edit.LineDelete and Ctrl+D to Edit.Duplicate), and I noticed that the IDE has seemingly duplicate functionality from the Brief and Emacs emulation commands, which made me wonder what the difference was.
Unfortunately there's no documentation available online that describes exactly how each Edit.* command differs from each other - I know I could dive through VS' editor's DLLs to try to find out but before losing a weekend down a rabbit-hole I thought to ask first...
So, can someone explain the differences between these similarly-named commands?
Normal
UnderWare Brief
Emacs
Edit.BreakLine
Edit.BriefBreakLine
Edit.EmacsBreakLine
Edit.LineDelete
Edit.BriefLineDelete
Edit.DeleteToEOL
Edit.BriefLineDeleteToEnd
Edit.EmacsDeleteToEOL
Edit.DeleteToBOL
Edit.BriefLineDeleteToStart
Edit.Find
Edit.BriefFind
Edit.Replace
Edit.BriefFindReplace
Edit.EmacsFindReplace
Edit.WordDeleteToEnd
Edit.BriefWordDeleteToEnd
Edit.EmacsWordDeleteToEnd
Edit.WordDeleteToStart
Edit.BriefWordDeleteToStart
Edit.EmacsWordDeleteToStart
Edit.WordPrevious
Edit.BriefWordLeft
Edit.EmacsWordPrevious
Edit.WordNext
Edit.BriefWordRight
Edit.EmacsWordNext
Additionally, what exactly does Edit.WordNextExtend and Edit.WordNextExtendColumn do?
I'm
running IntelliJ 14
using Mac OS X layout
running on OS X (Yosemite)
IntelliJ is using DVORAK in general but not for keyboard shortcuts.
keyboard shortcuts are in QWERTY. As if they were scancode based instead of the key value after mapping.
Ideas?
edit 1
#gabriel hard to tell but here are some examples...
note: m, a and 0-9 are same on DVORAK and QWERTY
cmd+/ 'comment line' flashes code menu and sometimes moves to a brace (/ == {)
cmd+b works, goes to definition (b == n)
cmd+opt+l 'reformat' flashes code menu (l == p)
It turns out this is a problem in Java that has existed for some years, and is still present in Java 9. See the bug report here: https://bugs.openjdk.java.net/browse/JDK-8022079
JetBrains has been aware of the problem for some years, but is waiting for Oracle to fix it. See these JetBrains bug reports: https://youtrack.jetbrains.com/issue/IDEABKL-6493 and https://youtrack.jetbrains.com/issue/IDEA-63779
In those reports you'll find a work-around using a free tool called Karabiner. I have just verified that it works for IntelliJ. It will probably also work for other Java-based tools.
For OSX earlier than Sierra The work-around is:
Download and install Karabiner from https://pqrs.org/osx/karabiner/
In the OSX System Preferences, set your keyboard to the default "U.S. International" PC. If you don't often type diacritics and other international characters, it's easier to just set the keyboard to "U.S" instead.
In the Karabiner settings, type "dvorak" in the search box, then scroll down to the section For U.S. Input Source and check Use Dvorak Keyboard Layout (QWERTY to Dvorak)
From macOS Sierra onwards, as reported by user MithrilTuxedo in the comments, the procedure is different. You have to use Karabiner Elements (the new Karabiner core) with a configuration file. I have outlined the procedure at https://cpbotha.net/2016/12/16/dvorak-remapping-with-karabiner-elements-on-macos-sierra-works/ and summarise it here briefly:
Download and install Karabiner Elements.
Copy qwerty_to_dvorak.json from the examples and install it as the new karabiner.json configuration file.
If Karabiner Elements is running, it'll pick up the new file.
This bug will affect most Java-based tools such as those by JetBrains (IntelliJ, PyCharm, WebStorm, AppCode) and probably also Netbeans. The work-around summarised above should alleviate the problem in all cases.
I've had a similar problem using key combinations like ctrl+n in intellij 16 on linux (red hat). I use Colemak keyboard. I had two input sources setup in my operating system, system preferences .
English(US)
English(Colemak)
When I changed the order of the Input Sources, and put Colemak first, the problem seemed to go away.
System Tools > Settings > Keyboard > Input Sources
JetBrains are waiting for the bug to be fixed upstream in JDK, which of course will never happen. The other answer here is informative, but will only work on Mac OS, so if you're on linux or windows you're out of luck there.
I wrote a script to work around the issue, which you can find here. If you normally use GNOME keymap in pycharm on linux, then you're in luck - you can simply import my dvorak_settings.jar file and get back to coding.
Otherwise you can use the script to generate your own bugfixed keymap, read on...
The original keymap files are located in <pycharm>/lib/resources.jar/idea/Keymap_*.xml.
Example usage:
./to_dvorak Keymap_Emacs.xml -o Keymap_Emacs_Dvorak.xml
Have a browse over the generated file and if it looks sane, pack it up into the .jar file (see my dvorak_settings.jar example for the required structure) and import this in your IDE.
This problem is (finally!) fixed in IntelliJ IDEA 2017.1. See JetBrains issue JRE-172, “Wrong keys are picked up on dvorak layout in Mac OSX 10.6.2”.
It also seems to be fixed in other JetBrains tools. I tested that it's fixed in PyCharm 2017.1, CLion 2017.1, and AppCode 2017.1.
We have recently switched from autocad 2010 to autocad 2014, and are encountering some annoying problems. Every drawing we open, is now opening in a separate application. So, instead of multiple drawings per application, it is opening each and every one in a single window..
When opening drawing from our datamanager, we check if an application of autocad 2010 is running through the following line of code:
(setq ddeconv (ddeinitiate "AutoCAD.r18.DDE" "System" ))
What is the equivalent of this code for autocad 2014? Or, simply put, how do we check if the autocad 2014 is already running?
Note that I am a complete novice in LISP, so if you require more code or information, please leave a comment!
After some trying, I've found the answer myself. It seems it was as simple as changing the release version from 18 to 19, becoming:
(setq ddeconv (ddeinitiate "AutoCAD.r18.DDE" "System" ))
I am using VS2013 as my IDE and ever since I installed it acts very oddly when pressing ALT and any of the ARROW keys. I use ALT+LEFT and ALT+RIGHT to navigate backward/forward which works in principal but once VS completes the jump it writes out a single character.
This is before the jump:
This is after the jump/after pressing ALT+LEFT:
Those are the characters that are being written:
ALT+UP: ◘
ALT+RIGHT: ♠
ALT+DOWN: ☻
ALT+LEFT: ♦
I am using VS2013 at work as well all the time and I have never seen this before. I know that pressing ALT+NUMPAD_KEYS produces ASCII characters but why is that happening for my arrow keys and only in VS? Apparently ALT+UP for me is the same as pressing ALT+6 (http://www.irongeek.com/alt-numpad-ascii-key-combos-and-chart.html). I actually swapped out my keyboard to see if its got anything to do with that. No joy.
Any ideas?
Update 1:
Looks like this fellow has a similar issue but with Eclipse on Windows:
https://superuser.com/questions/668394/turn-off-alt-numeric-keypad-ascii-symbol-insertion
Sadly no answers to his post.
Update 2/Solution:
As per the comment of 'Hans Passant' I found a solution. See below for details.
I have found the cause thanks to Hans Passant.
I did a diagnostic boot and discovered the issue even then still persisted. I then went on to kill all remaining processes until I struck gold:
With this process gone ALT+ARROW_KEYS don't trigger ASCII symbol insertion anymore. I ended up doing two things in total to get rid of this process:
Reinstalled .NET Framework 4.5.1
Renamed/Removed this file: C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegSvcs.exe
On booting into Windows there are neither errors pertaining to that particular executable nor have I noticed any other malfunctions. Just to be sure, I ran a couple of virus/malware removal tools. They all came up with no threats.