When I type :e, MacVim automatically expands this to :Edit. The problem with this is that I can't discard my current buffer with :Edit!, because I get an error message saying that "!" isn't allowed.
I have two questions:
Why does :edit! work and not :Edit!
Is there a way to disable this auto-expand feature in MacVim, or perhaps switch it to expand to :edit! and not :Edit! ?
Thanks!
If the expansion happens immediately after typing the e, it might be due to a command-mode mapping (i.e. :map!, :cmap or :lmap). If it is only expanded after typing e followed by a space (or enter), then it might be an abbreviation (i.e. :abbreviate or :cabbrev).
You can temporarily avoid a mapping-based expansion by typing Control‑V or Control‑Q before e. Another workaround is to type Control‑F while entering a command-line command (i.e. you are at the : prompt; or type q: instead of : when starting a command). This will bring up the command-line window so that you can edit your command via normal/insert modes (this avoids all command-line mode mappings).
Once you have a way to enter e into a command-line again, you can use :verbose to find the source of the mapping:
:verbose cmap e
(You must either use the command-line window to type this literally, or enter it at the command-line by typing a Control‑V or Control‑Q before each e.)
This will show you the definition of the mapping. Additionally, if it came from a plugin, then the source will be identified with a second line like Last set from /path/to/some/file.
Checking for an abbreviation is a bit tricker since there are two chances for expansion (while typing and when the command line is being parsed):
:verbose cab ^Ve
The ^V needs to be an actual Control‑V. Usually you accomplish this by typing Control‑V twice (or Control‑Q, then Control‑V).
As for the Edit command itself, it is not a built-in command, so something plugin must be defining it. Very few built-in commands start with an uppercase letter, and all “user defined” commands must start with one; see :help E183.
You can use :verbose again to find where :Edit was defined:
:verbose command Edit
I suspect the mapping/abbreviation and the command probably come from the same place.
You can manually disable a mapping-based expansion with :cunmap and an abbreviation-based expansion with :cunabbrev:
:cunmap e
:cunabbrev ^Ve
Again, you may need type Control‑V or Control‑Q before each e, and the ^V must be a literal Control‑V (type Control‑V twice to enter it).
Unfortunately, you can not just put these in your ~/.vimrc if the definitions are coming from a plugin because plugins are loaded after ~/.vimrc. You should investigate the plugin to see if it offers a option to disable the intrusive mapping. Sometimes plugins check a :let variable to see if they should enable some feature. Maybe your problematic plugin has a “knob” that will let you tell it not to install its e -> Edit expansion. If not, you might be able to report a bug about :Edit! not working properly and ask for a way to disable the expansion too.
Do you use TextExpander, Typinator or some text expansion utility? If yes, those might be the culprit. As far as I know, MacVim does not expand text like that.
Related
By default Terminal.app has a keybinding for ⌘+↑ that scrolls the screen back to (and briefly highlights) the previous command prompt. (This seems to be independent of shell although I've only tried a couple. I'm using bash.)
I'm trying to get similar behavior in iTerm2, but I haven't found a mapping that does that. None of the search terms I've tried in iTerm2's list of key mappings suggest anything like this function. The iTerm2 mapping preset called Terminal.app Compatibility causes ⌘+↑ to scroll through previous commands, the same way ↑ does, rather than the window scrolling back to the lines on which previous commands were input.
Based on this answer to a similar question, I looked through the output of bind -p and see entries "\e[A": previous-history and "\e[B": next-history, but these seem to be describing the scrolling through previously-entered commands rather than scrolling through the entire terminal window output to the prompt at which the command was input. These are the only bind -p entries that refer to up or down arrows (if my assumption is correct that [A refers to the up arrow, which I determined with xxd -psd as suggested in this answer.
Is this behavior in Terminal.app the result of a key binding? Or, how would I determine whether it is or not? And is there a way to get iTerm2 to duplicate this behavior?
Have you tried
fn + CMD + UpArrow ?
Only an ersatz for Terminal.app "going up one prompt at a time” behavior, but maybe helpful as it makes iTerm2 do a Full Page Up consistently across my custom profiles and various key map preferences.
With shell integration installed, iTerm2 creates a "mark" at each prompt, and the default shortcut for moving to the previous mark is ⌘+⇧+↑.
The KDE Daemon global shortcuts allow to choose a shortcut for Take Rectangular Region Screenshot, it defaults to Meta+Shift+PrtScr.
However that takes a screenshot with the mouse pointer, how do I disable that?
When I open Spectacle, the includeMousePointer is not checked, so apparently that's a different setting.
Apparently this commit seems to say it's possible to do so but I don't know how.
If you press the hotkey, a D-Bus command is invoked. These commands accept arguments instead of looking at configuration files for maximum flexibility.
The actual D-Bus command that you would need to invoke is:
qdbus org.kde.Spectacle / org.kde.Spectacle.RectangularRegion false
The argument for this RectangularRegion method indicates the value for includeMousePointer. The commit you referenced indeed makes the default hotkey action call this with a true argument instead of false.
If you want to change the default, edit spectacle.khotkeys file in your system. Locate the [Data_1_4Actions0] section, and change Arguments=true to Arguments=false. The result should look like this:
[Data_1_4Actions0]
Arguments=false
Call=RectangularRegion
RemoteApp=org.kde.Spectacle
RemoteObj=/
Type=DBUS
It might be required to restart your session after changing this.
I don't like text editors that perform auto-indentation in my code, because of various reasons, but Kakoune seems to be hardcoded to do that? Is it possible to disable it?
I couldn't find any defined "hooks" for indent, just for autocomplete.
Just run :set global disabled_hooks .*-indent in your Kakoune window or put
set global disabled_hooks .*-indent
in your kakrc.
Found the answer at https://github.com/mawww/kakoune/wiki/How-To#disable-auto-indentation, although it wasn't immediately clear what "disabled_hooks option" meant.
It's not strictly an answer to your question, but I sometimes need to paste text into kakoune over an SSH session from Windows. In vim, I could do :set paste/:set nopaste.
In kakoune, I found I can enter insert mode with disabled hooks (see "Disabling Hooks" in https://discuss.kakoune.com/t/hooks/544) by typing in a \ first, e.g. \i. Then I paste the text without indentation fuss and can leave insert mode again. Neat!
I want to write a macro that if there is no selection it automatically operates on the current word, otherwise it operates on the selection. However I cannot find a suitable action, EditorSelectWord keeps on expanding the selection forever.
p.s. The macro is meant to change "xyz" to "{#code xyz}", but it also needs to change "x/y/z" to "{#code x/y/z}".
IntelliJ IDEA does not appear to be the best tool for this specific job. It looks like macros only support a fixed list of steps that will always be executed, without the possibility for if statements: https://www.jetbrains.com/idea/help/using-macros-in-the-editor.html.
You could use Ctrl-W manually when there is no selection, but it would of course be much nicer if the macro could handle it. Another possibility is to use a tool like the stream editor sed. The substitution command of sed might be usable in your case, unless the text occurs in places where you do not want to substitute it:
sed 's/xyz/{#code xyz}/g' inputFileName > outputFileName
It might also be a great reason to write a small program of your own that for example modifies only specific strings in Javadocs in your source files.
I have my Qt Creator 3.1.1 setup to indent with 4 spaces on Tab, but for some reason tab key doesn't work when I edit CMakeLists.txt. This only happens when I open it with CMake Editor, it works when I use Plain Text Editor. Is this a bug or I need to configure it somehow to make Tab key work?
I had exactly the same problem.
This issue occured because I have enabled auto-indent. The value in the "Preferences->Text Editor->Behavior" tab "Typing->Tab key performs auto-indent" was set to something else to "Never".
So to fix this issue you you need to set "Tab key performs auto-indent" to "Never".
Additionally to the answer above, inside 'Options' window and 'Behavior' pane, have a look at 'Tab Policy' section as well as 'Cleanups upon Saving' - and check if it is really what you expect.
For me the settings there were not what I have expected and it was triggering issues, eg. in a Makefile, first command of a task looks like line continuation for Qt Creator so, upon saving, it was "cleaning" (= breaking) the indentation by replacing it with 4 spaces, that was incoherent with overall indentation in the script. Et voilà - error, make didn't work correctly!
As always, it is a very nice tool but one needs to know how to use it...