How do you 'jump to definition' in a fresh install of LightTable, without setting your hair on fire - lighttable

I tried ctrl- which was suggested somewhere online, but that makes the font smaller. (ctrl+ though does not undo that, so I had to restart LightTable to get back to normal).
Pressing ctrl enter I can manage to write and use "jump to definition", but obviously I will not be going through that every time....
If this should have helped, it is rather confusing what the period and comma here mean:
So do the built-in default keyboard shortcuts allow that, and how do they allow increasing font size?

Hit cmd/ctrl + enter
in the pane that this brought in: type "jump to" to see the command "jump to...", plus its keyboard shortcut. you can select the command from there but that would suck if it were the only way to invoke commands, so observer the keyboard binding you get there: (in the blue circles below)
notice that keys are separated by dashes in the display of the keyboard shortcut, so do not actually enter a dash because it is not part of the command and you will be doing crazy stuff if you assume otherwise
same thing for finding out how to zoom: enter "zoom" in that pane
unset you hair on fire
Courtesy of #rundis from the gitter channel...

Related

With Qt Creator FakeVim mode, key-combination CTRL+U seem to interfere with "Select the current block"

I'm starting to use QT creator and FakeVim mode. Inside VIM I use CTRL+U (Scroll window Upwards in the buffer) and CTRL+D (Scroll window Downwards in the buffer) the whole time.
Problem: CTRL+D works as expected inside QT creator, but unfortunately the key-combination CTRL+U seem to interfere with some other setting (maybe "Select the current block") and begins marking a lot of text at the same time it's scrolling upwards.
So: CTRL+D = scrolls down, no "block selecting"-stuff going on.
CTRL+U scrolls up and at the same time it begins highlighting (block selection), which is really annoying.
Attempted: Among other things, I tried googling and found: https://doc.qt.io/qtcreator/creator-keyboard-shortcuts.html - and tried both combinations of the value "Enable smart selection changing" - but it ditn't help on my CTRL+U-issue...
Question: Anyone knows how I can make CTRL+U only scroll up, instead of selecting/highlighting a block while it scrolls up?
Just for the record (it seems we're not many qtcreator/fakevim users but hopefully it can help someone else that) I found the solution and will answer myself:
First: Related to the issue is: In the "Options -> FakeVim -> General" dialog, under "Vim Behaviour" disable "Use search dialog" will get rid of (a similar) annoying vim-search "begin highlighting after search"-problem which is triggered when using "/" to search...
For the CTRL+U highlighting issue: The issue is resolved by disabling the option "Pass control keys" in the same option setting dialogue.

How to edit jupyter notebook shortcuts

Jupyter notebooks have a convenient means to edit shortcuts - by pressing H for help there is a button for it:
And here is the dialog to make the updates:
The question here is: when pressing add shortcut we apparently have a free form text field to enter the shortcut:
But whatever combination I put in actually causes some _system_wide_ kind of behavior to kick-in e.g. Command-R causes Jupyter to do something wacky, and I tried a couple of others. Is there another way to enter these?
Have you tried clicking on that link: details of defining keyboard shortcuts?
That gives some general tips on creating new shortcuts.
Your example might not work because you would want to use "Cmd-R" instead of "Command-R". Though, in my operating system, "Cmd-r" already does something(reloads the page). So whatever combination or sequence you choose, I'd make sure it doesn't already do something before using it as a shortcut.
Once you type into the field, are you clicking the "+" button to the right? If you click on that, it should then show if it's been set, and you can verify it set it to what you wanted. If you don't click the "+" button, it will have no effect.
Good luck!

Tmux: Clipboard selection behaves strangely in MobaXTerm

I'm running a Tmux session inside a MobaXTerm SSH connection. Now if I want to select some text to be copied to the system clipboard (by holding shift pressed while dragging the mouse over the text) the selection does not work as expected.
Assume I select one word. I press and hold shift, press and hold the mouse button over the first character of the word, move the mouse to the end of the word and release the mouse button. The word gets highlighted and copied to the clipboard. This works fine.
However, now I change my mind, or discover that I selected the wrong word, and want to select a different word. Again I do the same sequence as before, but on the other word. Strangely, when I press and hold the mouse on the new word, the highlighting is not reset, but continued from the initial highlighting of the previous selection.
This is extremely annoying. I can only reset the selection by temporarily switching to a different window. It seems this problem only occurs with MobaXTerm. If I use Putty instead, the selection works fine. I checked all settings of MobaXterm, but can't find anything related to mouse events.
To clear a selected region (after selecting with shift + drag) you can either:
Right click anywhere, then left click anywhere
Shift + right click anywhere, then left click (without shift) anywhere
I think (1) sometimes does not work when I have vim in my tmux pane, but (2) works regardless.
After clearing the selection, you should be able to start another from a new location.

Tmux current pane indicator when focus regained

I'm trying to create a visual indicator of which pane is currently focused in tmux when my terminal (iterm2, OSX) window gains focus. I have found that iterm2 sends a focus gained escape sequence (^[[I) so now I am trying to find how I can capture that and fire the prefix q command which shows pane numbers with the active pane in red.
Any ideas on how to capture the escape sequence in tmux OR in iterm2?
I have a partial solution to my issue which takes a different approach. Since I usually have vim and one terminal pane open, dimming vim when it is not focussed is a good indicator which pane is active. In order to achieve this I have modified the vim-diminactive plugin to react to focus events (https://github.com/blueyed/vim-diminactive/pull/8), this requires the Vitality.vim plugin as well as enabling (focus-events) in tmux options.
In order to completely solve my issue I am working on changing the background colour of terminal panes when they lose focus. I use zsh so I can capture the focus event with bindkey (I have verified this works) to issue a background colour change escape code to iterm2, however this seems to have no effect in tmux.

How to commit build settings in popover on Xcode

In Xcode 4.3.1, I am having extreme difficulty whenever I try to change a build setting such as "Other Linker Flags".
If I double-click, a pop-up shows which ostensibly allows you to add/remove values. However, there is no "done" button and all key combinations I've tried (enter/command-enter/etc...) fail to commit the values I've entered.
It is possible to enter a value without the pop-up by /slow/-double-clicking (WTF, Apple?!?) the edit line. This works, but why the heck does is the pop-up the default double-click result when it seems to be totally useless, misleading and annoying?!?!
A similar question is Editing Build Settings in xcode 4 but bugloaf's question of what to do when there is no "done button" remained unanswered.
This is more to do with how to interact with popovers in OS X in general. "Transient" popovers force you to click outside them to dismiss. Whatever changes you make inside them should always be "committed" by the time the popover is dismissed. This is standard Mac behavior.
So to answer the unanswered question: Click outside the popover to dismiss/commit.
As you ssuggested, you can slow-double-click (once to select, pause, once to begin editing cell) to edit text cells inline without the popover. This is also standard Mac behavior.
The double-click action is a secondary effect and can be taken to mean "give me a bigger editor for this field" - this seems to be just Xcode behavior. File bug reports if you think there should be a better mechanism. Be prepared to describe a better mechanism.

Resources