fish-shell
fish-shell copied to clipboard
fish-shell
Suggested feature: Mouse tracking
When editing a long command in the command line it would be very convenient and natural to be able to click on a character and have the edit cursor moved to this character. I have seen this already working on Mac with Option+Click, but it doesn’t seem to work on my Linux machine. I am using Ubuntu and Gnome-Terminal, fish version is 2.7.1 and the $TERM is xterm-256color. It doesn’t work without customizations either.
I assume for this to work the shell should support mouse tracking but I am new to this and not 100% sure. Kind people in the gitter channel told me about Alt+V to start the default editor, and this is a definitely useful feature, but it seems an overkill for that particular task.
Steps to reproduce:
- Start gnome-terminal with fish shell
- Type a few characters in the prompt
- Click one of these characters with the mouse
Actual: the editing cursor stays in its position Expected: the editing cursor moves to the character clicked
Would you consider support for this feature?
I have seen this already working on Mac with Option+Click
Does it? It does! I didn't know that!
On Terminal.app and iTerm, this is implemented by sending cursor movement keys until the correct position is reached, so fish is oblivious.
Making this work under XTerm mouse reporting is certainly possible, though may require a lot of work.
+1
mouse tracking in curses: http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/mouse.html
DomTerm also supports moving the cursor with a mouse click, by sending arrow key sequences. You can always do Alt-click. With an appropriate escape sequence in your prompt, it also works for plain click. Here are instructions for bash. I'm new to zsh, but this seems to work:
if [ -n "$DOMTERM" ]
then
ZSHPID=`sh -c 'echo $PPID'`
PS1=$'%{\e]119;zsh'$ZSHPID$'\a\e[14u\e[16u%}▼%{\e[17u%}'$PS1$'%{\e[15u\e]75;> \a%}'
fi
These escape sequence also add a show/hide (fold) "button" (the triangle) and create appropriate structure in the DOM, which supports styling and other features. (The use of $ZSHPID helps make the separation between commands more robust in the presence of nested interactive programs.)
Oops my apologies. I've been trying out both zsh and fish, and got confused about all my tabs :-)
I'll look for a suitable prompt for fish.
This seems to work for Fish:
function fish_prompt --description 'Write out the prompt'
# generic prompt used for non-DomTerm terminals and as base for DomTerm
set -l suffix '$ '
set -l prompt (prompt_pwd)"$suffix"
if test -n "$DOMTERM"
set prompt '\e]119;fish\a\e[14u\e[16u▼\e[17u'$prompt'\e[15u\e]75;> \a'
end
echo -nes "$prompt"
end
This enables moving the cursor with a (plain) mouse click; show/hide (fold) button; and structure/styling for each "command" (separate element attributes for prompt, input, and output, as well as a "command group").
@PerBothner: For the zsh version, I'm quite sure this piece is unnecessary:
ZSHPID=`sh -c 'echo $PPID'`
That executes sh (which is probably a different shell) and asks it about its parent pid - which is of course zsh's.
Instead, use ZSHPID=$$.
That executes sh (which is probably a different shell) and asks it about its parent pid - which is of course zsh's.
Right - which is what I wanted. Is there something wrong with it (besides being over-complicated)?
Instead, use ZSHPID=$$.
Ah - thanks. I Googled for the zsh equivalent of $BASHPID, and found an article suggesting there was none, but one could use the expression I used. But for the current purpose (an identifier for the current interactive shell) $$ is as good (and possibly better).
For Fish, I will try out %self, as fish helpfully suggested when I tried $$.
Also: mouse support in SSH sessions, regardless of mouse support at the console. Probably handled via the same API, though.
I don't see any reason ssh should be a problem with mouse support. Both traditional xterm mouse support (as used by emacs), as well as how DomTerm translates a mouse-click to arrow-key sequences should work fine.
Where ssh could be an issue is integrating the (primary) selection and the clipboard. If DomTerm is running in a regular browser accessing the clipboard may be prohibited except from an event handler. This prevents (for example) fish sending a command to DomTerm to read or write the clipboard. An alternative would be to use a program like xclip, but that doesn't work when using ssh (unless X forwarding) and has other security problems.
The best solution probably is for the fish input editor to notify DomTerm which key sequences cause reading or writing the clipboard. This requires some non-trivial coordination between them.
@PerBothner I've completely worked around all clipboard-related concerns in fish by defining my own pbcopy/pbpaste (which fish should use automatically) wherein I take appropriate measures to handle copying remotely. Here's my pbcopy:
https://github.com/mqudsi/fish-config/blob/master/functions/pbcopy.fish
@mcarans "I'm looking for a terminal emulator with this feature"
Please try DomTerm and follow these instructions. Let me know if you have any problems. A recent version of fish built from github HEAD works best.
This article discusses the functionality, and has some Fish screenshots.
@PerBothner Thank you for the instructions. I successfully built fish and domterm, but when I launch domterm, all I get is a blank white screen with no shell. I also tried: qtdomterm /usr/local/bin/fish but the result was the same. Fish works when I launch it from the Linux Mint default terminal window (by typing fish at the bash prompt). domterm --chrome works. Also, is it better to use the QT frontend or the electron one on Linux (Mint)? I've reported this issue against domterm here: https://github.com/PerBothner/DomTerm/issues/69
https://github.com/PerBothner/DomTerm/blob/master/tools/shell-integration.fish works for fish in Konsole.
I would love this, I frequently wanna add some quotes at the beginning of a long prompt and then its frustrating to jump to the right position just with the various jump and arrow keys.
