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 ⌘+⇧+↑.
Related
According to https://github.com/mintty/mintty/issues/944 since mintty 3.5.1 there should be a tab bar where you can open multiple tabs with terminals in parallel. For that reason I performed an installation of MSYS2 which includes mintty 3.5.1, as this seems to be the way how to use the mintty. (I verified this with invoking mintty with -V.)
However, I do not find no possibility for opening and/or managing tabs in the UI.
My requirement: I would very much like to have tabs for organizing terminals in parallel.
My question: What's going on here? Did I miss something? Do I need to execute the mintty/MSYS2 with some special commad line options? How can I enable tabs?
You could use --tabbar option when staring minnty. see here for more information.
It was difficult for me to figure out how to turn this feature on. The answer is sprinkled through the comments of this issue, but not in one place. Therefore I'm posting this to save time for others. Here's how you turn the feature on:
Add --tabbar=4 or --tabbar to the windows shortcut that opens mintty:
The 4 is documented here:
no geometry handling; terminal session windows are separate [default]
sync. position/size when switching/launching/closing a session
sync. also when window is moved or resized
sync. also when window is minimized
sync. also when window is started separately
If you'd like to create new tabs with ctrl-shift-t, close tabs with ctrl-shift-w, switch to previous tabs with ctrl-shift-tab, and switch to next tabs with ctrl-tab, add -o "KeyFunctions=t:new-window-cwd;w:close" as an option to that same line.
Personally, I'd like to have ctrl-t/w open and close tabs, respectively, but the only way I've figured how to do that is to add this option: -o CtrlExchangeShift=yes. The problem is, that changes all ctrl-shift commands to become ctrl commands. That means ctrl-r no longer searches bash history.
When you run the shortcut and create some tabs, mintty will look like this:
I have the following keymap.cson file to config my Atom editor:
'body':
'ctrl-shift-cmd-left': 'window:focus-pane-on-left'
Only when I run this command, the current text is selected. Which without the alt key held, would make sense as a highlighting command.
However, is I bind a key command which I think most likely doesn't have a competing action, say alt-cmd-;, it seems to be registered into the list of key commands in Settings/Keybindings, yet again no window focus is happening.
Edit:
I now realize that pane and not window may be the relevant term for what I want. Still, searching the Key Bindings for pane focus switching didn't yield anything obvious. Surely, there must be a simple way to select through files in the Project area while editing.
Although this answer doesn't match the title of the question, based on your edit I think that tree-view:toggle-focus is what you're looking for.
Please try using Ctrl + 0.
And, if you use Nuclide (related to React), please try disabling it to check the difference.
Is there any way to disable keyboard shortcuts in MacVim? I mean the shortcuts like Cmd + s for example, I want to convince myself to use things like :w, but I can't do so if I can save the file using Cmd + s, you get me?
But I of course, still want to use the GUI, so is there any way to disable these, without stoping using the MacVim GUI?
Thanks for your help. BTW I made a Google search and wasn't able to find an answer.
EDIT:
Following #ChrisJohnsen's suggestion, I have already tried the following with no success:
if has('gui_running')
macmenu File.Save key=<nop>
macmenu File.Save\ As\.\.\. key=<nop>
endif
EDIT 2:
I moved the error I'm getting over to this other question: When I try to run vim in command line I get Python errors
There is no simple way to disable all of the pre-defined Mac-style keyboard shortcuts, but you can definitely change/disable any of them. The important command is :macmenu (see :help :macmenu); it lets you set the Mac-specific properties of any Vim menu item (mostly Mac-specific keyboard shortcuts and Mac-specific actions (e.g. open/save dialog boxes, window manipulations, etc.)).
macmenu File.Save key=<nop>
macmenu File.Save\ All key=<nop>
macmenu File.Save\ As\.\.\. key=<nop>
The thing is that :macmenu commands are only effective if they are in your .gvimrc file.
If you do :e $VIMRUNTIME/menu.vim and search for macm, you will find the list of pre-defined shortcuts and actions. Copy the desired lines to you .gvimrc and replace key=<whatever> with key=<nop>. You can also wrap them in if has("gui_macvim") / endif if you need your .gvimrc to work on multiple platforms.
MacVim has only one "advantage" over plain Vim: it supports native Mac OS X shortcuts. If you don't want those shortcuts you might as well simply use plain Vim.
FWIW, when I switched from TextMate I, too, found after a while that these native shortcuts were an obstacle on my way to learning Vim. My solution was to focus my efforts on plain Vim. After a week in the terminal you should be able to completely disregard those shortcuts.
I'd advise you to take a little pause and think about doing things in a more appropriate order:
In the terminal, do $ vimtutor as many times as needed.
In the terminal again, use $ vim for simple tasks first then more complex tasks. There's a predictable productivity hit at the beginning but it will last only a few days/weeks.
Once you have reached your previous level of productivity, you can start to fly Vim full-time. At that point, using MacVim or GVim or plain $ vim should make no difference whatsoever.
Bonus points for not relying too much on plugins, other people's vimrcs or "distributions" like janus or spf13…
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.
A keyboard shortcut to comment/uncomment out a piece of code is common in other programming IDE's for languages like Java, .Net. I find it a very useful technique when experimenting through trial and error to temporarily comment out and uncomment lines, words and parts of the code to find out what is and isn't working.
I cannot find any such keyboard shortcut on the Mathematica front end in version 7. I know that it is possible to comment out code by selecting the code, right mouse click and select Un/Comment from the menu that appears but this is too slow while coding.
I tried to access this using the menu key Menu on the keyboard but Mathematica frontend doesn't respond to or recognise this key unlike other applications, this could have allowed a key combination for commenting. Can someone else verify that this isn't unique to my machine and that the key isn't recognised by mathematica. I looked at this question and looked in the KeyEventTranslations.tr file but I don't think there is any way to create a shortcut to do this(?). Should I just live with it?
Any other suggestions?
(I have seen there is an Emacs version of mathematica, I have never tried Emacs or this Mma version and imagine that it would have this ability but would prefer not to go to the trouble and uncertainty of installing it. Also I would guess that the Wolfram Workbench could do this, but that may not be worth the investment just for this.)
You can install the shortcut in Mathematica 7.0.x if you are willing to edit the Mathematica system file MenuSetup.tr. You can find it in the same location as the KeyEventTranslations.tr file (i.e. in the installation under "SystemFiles/FrontEnd/TextResources/platform"). In MenuSetup.tr, locate the following line under the definition of the Edit menu:
MenuItem["Check &Balance", "Balance", MenuKey["B", Modifiers->{"Control", "Shift"}]],
Immediately below that line, insert the following:
MenuItem["Un/C&omment Selection", KernelExecute[FE`toggleComment[]], MenuKey["/", Modifiers->{"Command"}], MenuEvaluator -> Automatic, Method -> "Queued"],
The Un/Comment Selection command is now available under the Edit menu, with the keyboard shortcut Cmd-/ or Alt-/ depending on your platform -- just like in Mathematica 8 where this command comes pre-installed.
Please take as read the usual disclaimers about hacking the Mathematica installation files -- no warranty is offered :)
I do not know of any way to map this function to some shortcut involving the Menu key.
Shortcut Key, No Menu
The preceding steps mimic what Mathematica 8 does by installing a new menu item. If you prefer to leave the menus unchanged, then you can install the shortcut in KeyEventTranslations.tr instead. Add the following line:
Item[KeyEvent["/", Modifiers->{Command}], KernelExecute[ToExpression["FE`toggleComment[]"]], MenuEvaluator -> Automatic, Method -> "Queued"]
You'll need a comma on the end of that line if it is not the last item in the list.
Select the code and press one of the following:
Alt+/
Alt-E-O
Alt+E+O
Notes:
Tested only on Windows, using Mathematica 8.
On my non-US keyboard (ABNT Brazil), the shortcut Alt+/ doesn't work, instead I use Alt+E+O.
Here is code for your KeyEventTranslations.tr file that will comment out code. I am still working on the other half.
Item[KeyEvent["/", Modifiers -> {Command}],
FrontEndExecute[{
NotebookApply[FrontEnd`InputNotebook[],
"(*\[SelectionPlaceholder]*)"
]
}]
],
This binds it to Alt+/ as it is in Mathematica 8.