BACKGROUND
When running sbt, I must press a "dead" key after each press of <ENTER>; meaning that pressing <ENTER> appears to do nothing... until I press another key -- any key -- when sbt ignores the follow-up key (i.e., "dead key") but behaves as if <ENTER> had been pressed.
After looking into the issue, I discovered that a system property ("jline.terminal") affects this behavior. This property can be one of {"auto", "unix", "win", "windows", "none", "off", "false", xxx} where xxx refers to a class implementing jline.Terminal.
When I set jline.terminal to be one of {"off", "false", "none"}, the problem with "broken <ENTER>" goes away. However, this mode drops support for the linux Readline library (i.e., up-arrow yields "^[[A" instead of recalling a line from the input history buffer).
So, I have 2 options:
Use "unix" as my jline.terminal and press <ENTER> + at the end of each input line; or
Use "none"|"off"|"false" as my jline.terminal and lose my command history support
How can I have both: a working <ENTER> key AND support for the Readline library?
ENVIRONMENT
OS: Ubuntu 17.10
Java: 1.8.0_161
sbt: 1.1.2
Related
I am using jupyter-lab, and was wondering if there is a plugin that allows me to work without switching between command and edit modes?
I'm constantly cutting, pasting, and undoing cells because I accidentally switch into Command mode when I mean to be typing the characters 'x', 'y', or 'z' in Edit mode.
Some context: the concept of modes is integral to Jupyter notebooks. You are either in Command mode (Esc) or Edit mode (Enter), but I would like to use Jupyter Notebooks with a single set of shortcuts, as if I was editing a single document. #nomodes.
Aside from the default shortcuts, there is actually very little that's mode-specific in JupyterLab. Most commands that are run in command mode can be run without first exiting edit mode.
We can get pretty close to modeless editing in Jupyter by using a shortcut that's independent of the current mode. There are instructions on how to customize the keyboard shortcuts here.
As an example, the default shortcut for the cut-cell command is x. This could be replaced with the shortcut Accel Ctrl X. That can be used in either mode without interfering with editing. Just add the following into the User Preferences panel:
{"shortcuts": [
{
"command": "notebook:cut-cell",
"disabled": true,
"keys": ["X"],
"selector": ".jp-Notebook:focus"
},
{
"command": "notebook:cut-cell",
"keys": ["Accel Ctrl X"],
"selector": "body"},
}
]}
Each default command mode shortcut should be modified as follows:
Prefix a universal modifier to the shortcut (e.g. Accel Ctrl).
Accel is just the Jupyter term for the Super/Command/Windows key on your keyboard.
Maintain the same shortcut keys for edit mode. The key insight is to use a "selector": "body". That selector can target both modes.
As with any default shortcut override, make sure to mark the original as "disabled: true".
Alternatively you could duplicate the same shortcut twice:
one for edit mode with "selector": ".jp-Notebook.jp-mod-editMode".
one for command mode with "selector": ".jp-Notebook:focus".
The default shortcuts for notebook:run-cell are set up this way actually.
But I have not run into trouble with using "body" as the selector.
Just a note: this is a fairly tedious and error-prone exercise. There are dozens of default shortcuts that need to be modified.
I'm using the Windows Subsystem for Linux Bash in Atom via Platformio - and none of the arrow keys work.
There was an ongoing bug in WSL Bash with the arrow keys that should've been fixed, so I opened system32\bash.exe to test, and indeed the arrow keys work there; the problem happens only in Atom.
Does anyone know of a workaround/solution?
Thanks!
I've had this problem myself but I haven't found a full solution. It looks like there's a bug lurking upstream.
Until it's patched, here's a list of alternative commands courtesy of CherryDT in this thread:
Ctrl+P: Previous command (like up arrow)
Ctrl+N: Next command (like down arrow)
Ctrl+B: One character backwards (like left arrow)
Ctrl+F: One character forwards (like right arrow)
Ctrl+A: Start of line (like home key)
Ctrl+E: End of line (like end key)
Ctrl+D: Delete character (like delete key)
i'm using zsh on my mac (oh-my-zsh) and i don't understand why at the end of my output there is always this character: "%"
If i don't put export TERM="xterm-256color" in my ~/.zshrc i haven't that character:
Usually a bold % (or # for root) with reversed colors is used to signify a "partial" line in the output. That is a line, which is not terminated with a newline character.
As it seems to depend on the value of TERM I suspect an incompatibility between that value and the settings of terminal emulator. Contrary to the warning shown in your second screenshot, you actually should not set TERM in your ~/.zshrc (or anywhere inside the shell session). TERM should always be set by the terminal emulator itself. Its value (in conjunction with the terminfo terminal capability data base) tells the shell and other programs, which features a terminal emulator supports and how to use them. If the value is changed in the shell, the terminal emulator will not know about it. This may lead to programs sending control codes the terminal emulator does not understand correctly or at all.
In order to change the value of TERM you should change it in the terminal emulator settings. According to the iTerm 2 FAQ the settings is to be found at Preferences->Profiles->Terminal->Report Terminal Type.
I personally placed export PROMPT_EOL_MARK='' inside my ~/.zprofile and hide the character.
I've removed and added a few times now the following line to ~/.tmux.conf:
set -ga terminal-overrides ',xterm*:smcup#:rmcup#'
Which according to the person who provided it does the following:
to fool the multiplexers into thinking that the terminal has no "alternate screen" mode (such as that used by pico, mutt, etc). This is accomplished by setting termcap commands for the session.
The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as.
The end result is that the overflow ends up in the terminal's scrollback buffer instead of disappearing. Of course, since this is one static buffer, things will get messy as you switch between screen or tmux windows, but this is handy for quickly flicking up to see the output of an ls command or the such.
I don't quite understand the bolded section (emphasis added), but guess this is the source of what I'm seeing. It's causing some weird sort of unicode overspill upon exiting tmux.
Pasted as plaintext this text won't show up, but the symbol [001B]112 appears alongside the usual [exited]:
]112[exited]
(FWIW I think it has pasted in that line, but isn't displaying)
I followed this advice ("Use terminal scrollbar with tmux"), and while it does work, this is just ugly/annoying to see that upon exiting. Can anyone advise how to fix or avoid the output message?
Offhand, I would get the unwanted "message" is some hard-coded application (or script) which is helpfully resetting the xterm dynamic text cursor color. See XTerm Control Sequences in the description of Operating System Controls:
The dynamic colors can also be reset to their default
(resource) values:
...
Ps = 1 1 2 -> Reset text cursor color.
So... somewhere there is some script doing the equivalent of
echo -n -e '\e]112\a
The results probably depend most on what particular terminal emulator you are using. Both screen and tmux filter out escape sequences that their developers did not care to implement, and pass through those that the terminal "should" handle.
Just take a look at sentence you provided: "The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as."
In my case, the $TERM has value xterm-256color and the corresponding line in ~/.tmux.conf looks like:
set -g terminal-overrides "xterm-color256:smcup#:rmcup#"
Here's what happens. I'm using Vim + LaTeX-Suite to edit TeX files in Vim. This could be in the Terminal or in MacVim.
I happily
Insert lots of $\LaTeX \commands$ etc. I love using the $\backslash$.
TeX works great. No problem.
Then I go and open up a .R file in the same window (different tab). R-Plugin for Vim uses the <Leader> key (mapped to \ as per usual) to execute commands, e.g. I type \sa to send the selection to R and execute and move the window down. Life is nice.
Problem: even though while editing an R file, Vim is nice enough not to bug me in insert mode when I type \, for some reason when I switch back to the tab to edit the TeX file, then type \ in insert mode, it moves the cursor left of the \ and pauses as though waiting for the rest of the command, before then re-moving to the right of the \ and moving on as I type.
Below shows what happens just from typing \ in insert mode; obviously I could reproduce this by moving the cursor to the left with the arrow keys, but that's not how this happened--the cursor just moves left for a split second as though waiting for the R command to finish being input.
So: how can I stop the annoying behavior in the TeX file insert mode, without sacrificing other functionality? Note, (a) I don't expect mapping <Leader> to a different key to help since then that key will just have the same left-cursor-move problem in TeX; (b), I like the leader as \ anyway so I don't want to change it.
Put this line in your vimrc (requires Vim-R-plugin >= 0.9.9.2):
let g:vimrplugin_insert_mode_cmds = 0
If the problem persists, you can do the following in Normal mode to know what are the keyboard shortcuts in Insert mode:
:imap