Fish-shell: improve the experience of using fish over mosh

[henrikbjorn]

Is there a way to turn off autosuggest? I find it really disturbing when using fish.

Please note

The original request, disabling autosuggestions, is being handled in issue #102. This issue has morphed into a request for improving the experience of using fish over a mosh connection.

[siteshwar]

There is no way to turn auto suggestions off. Auto suggestions are meant to help you writing commands more quickly. Is there any specific reason you don't find them useful ?

[henrikbjorn]

They dont provide any more information or make me faster in the command line. I keep thinking about what it shows me and that actually makes me slower and stops my current thought pattern.

[siteshwar]

One workaround is to make color of autosuggestion same as background color of terminal, although it would still show first character of the autosuggestion under cursor.

Is there any way we can improve auto suggestions so that they suit your usage pattern ?

[henrikbjorn]

Thinking briefly i dont think so. I like the minimalistic feeling of working in a "shell" where i get stuff that helps me but stays out of the way like syntax highligting and the searching by writing a part of a previous command and using the up keys. Also some part of my brain think that it must be costly to do autosuggest.

[ridiculousfish]

The hope for this feature is that it is not intrusive on either your attention or compute resources. Maybe the autosuggestion color contrasts too strongly against your terminal background? You might find it less objectionable to tweak the color to reduce that contrast.

[qjcg]

Just want to add my vote for an autosuggestions disable.

[zanchey]

Could you give us some idea of why?

[qjcg]

I mostly find autosuggestions distracting, and my use of the following features makes autosuggestions redundant much of the time:

• custom functions, fish_user_abbreviations ---> for typing less
• history-{,token}-search-{backward,forward} ---> for getting commands / arguments from history

[jovaha]

I also think this should be optional. I think i would be less intrusive if it didn't change the case of what the user has entered.

For example:
If i type
set $p
fish changes it to
set $P|AGER

where | denotes what is highlighted as autosuggested. this is confusing because what is displayed as already entered is not what would be executed.

[mzmm70000]

I'd also vote to add an option to disable autosuggest. In fact, I reinstalled fish recently and looked for this option for quite a while before I realized that auto suggestions can not be disabled. henrikbjorn's comment summarized my feelings about this feature quite well, I too find the suggestions highly distracting. I am confident enough in my environment not to need them, and the suggestions disturb my "mental flow", so to speak. When typing in my regular shell, I type blindly most of the time, only focussing on the input line of the terminal after pressing ENTER. Each time an autosuggestion is displayed, it forces me to unwillingly redirect my attention away from whatever I was looking at previously (be it some previous terminal output, or any one of my other windows / monitors) to focus on something that signals it requires my attention through visual change, i.e. the auto suggestions. In fact, this is a major reason which has prevented me from adapting fish as my main shell so far.

[ocharles]

I would like to add my vote for this feature. My reason is a little different, but I'm doing some screen recording at the moment to provide tutorials, and all of my history ends up leaking into these recordings. At best, that is distracting for users, at worst that is leaking private information. All I can do for now is move my history aside before starting screen recording, where it would be easier if I could just turn history based autosuggestions off.

[gitkalz]

I would vote to have an option to Disable autosuggest too .. +1

[faho]

@kalzi: The important thing is not a vote - on its own that's rather meaningless.

The important thing is: Why would you like to disable it?

[krader1961]

I'm ambivalent about the feature. Sometimes it's helpful but most of the time I too find it distracting; albeit not so much that I'd bother to disable it. But the one aspect that drives me crazy is the case-insensitivity as noted by @jovaha. That annoys me enough that I've been tempted to maintain my own completion function that leaves the character case alone.

[pickfire]

@kalzi, I have a vote that is against you. Why turn off a feature?

An option will be nice, but it shouldn't be the default.

[ghost]

Autosuggestion out of the box is one of fish distinctive features, but I agree with @ocharles:

I'm doing some screen recording at the moment to provide tutorials, and all of my history ends up leaking into these recordings. At best, that is distracting for users, at worst that is leaking private information.

One possible soultion to that could be implemented in userland and consists in creating a _do not track me_ function that makes a backup of the history file and clears the history. Call it again would restore the history file. Here is my naive implementation:

function nohist
    set -l prefix $HOME/.config
    set -l path fish/fish_history

    if set -q XDG_CONFIG_HOME
        set prefix $XDG_CONFIG_HOME
    end

    if test -f $prefix/$path.copy
        mv $prefix/$path.copy $prefix/$path
    else
        cp -f $prefix/$path $prefix/$path.copy
        echo y | history --clear > /dev/null
    end
end

You need to reset the session after restoring the history file so that fish can read the file.

[gitkalz]

Don't get me wrong everyone. Auto suggest is very handy at most times, I just prefer to see an option to turnoff at times due to privacy concerns when sharing my screen with someone. @bucaran solution seem smart enough.. BTW, I don't want to see it disabled by default. After all having an option is not bad in my opinion. Just me?

[ghost]

@kalzi If it can be done in userland, why bloat the core?

There is _technical debt_, _software entropy_, _software bloat_, etc., but I am not the dev/s making decisions here.

Maybe one day? ¯_(ツ)_/¯

[henrikbjorn]

@bucaran that is a - sorry in advance - stupid reasoning. Everything can be done in userland, so why have any feature at all?

[ghost]

@henrikbjorn If I had said:

I didn't say:

If it can be done in userland, why implement it in core?

I am talking about not _bloating_ core, which certainly is opinionated on my side.

tl;dr I think this feature is not inside the scope of fish.

[ocharles]

While the snippet above is nice, it can ultimately be forgotten. If I'm in
a sensitive environment its likely I'll only remember to turn the feature
off once it has already started doing damage. With a more stable option
though I can have it permanently off.

On Sun, 17 Jan 2016 3:47 pm Jorge Bucaran [email protected] wrote:

@henrikbjorn https://github.com/henrikbjorn

I had said:

If it can be done in userland, why implement it in core?

Then you would be right and my reasoning would be too extreme, but really
that depends on the scope of _your_ project.

Now, I didn't say that. I said _bloat_, which indicates my opinionated
view that implementing this feature in core would be excess.

In other words, that comment translates to saying, this feature is not in
the scope of the minimal feature set fish should provide.

However... I am not the leader of this project, so I can't really say
whether this feature _is_ or not inside the scope of fish.

—
Reply to this email directly or view it on GitHub
https://github.com/fish-shell/fish-shell/issues/1363#issuecomment-172342750
.

[iomintz]

If running fish on an abstracted "network filesystem" like GVFS-mounted FTP, autocompletion speed is mostly dependent on network speed.

My use-case where it's annoying and unhelpful is where fish is trying to auto-suggest for each keystroke as I type within an FTP server.

fish will end up making _tons_ of network requests, and in my case, by the time it finds the file it's looking for, I'm already on the next keystroke.

Now, I understand the law of leaky abstractions. I get that fish doesn't know this is FTP. I just find it unhelpful and intrusive in _this_ instance, and that's why I want a way to turn it off.

[ghost]

@bmintz Basically what @siteshwar said.

set fish_color_autosuggestion black # or your terminal background color

[ridiculousfish]

Note that even if autosuggestions are disabled, there will still be IO requests for syntax highlighting.

[Juerd]

Since this request for a simple feature appears to be rejected, I have resorted to patching the feature out. The simplest patch was to simply replace "flag" with "false", so that parts of fish that enable the feature, don't actually get to enable it:

diff -ur a/src/reader.cpp b/src/reader.cpp
--- a/src/reader.cpp    2016-05-21 00:48:00.000000000 +0200
+++ b/src/reader.cpp    2016-05-28 12:34:46.012964324 +0200
@@ -2594,7 +2594,7 @@

 void reader_set_allow_autosuggesting(bool flag)
 {
-    data->allow_autosuggestion = flag;
+    data->allow_autosuggestion = false;
 }

It's an ugly workaround for a missing feature, and I hope that at some point, a simple configuration option will be introduced to disable the autosuggest feature.

Autosuggest breaks my train of thought and makes me lose concentration to the extent that I find it hard to get work done. It is a privacy/security concern when other people are around. Changing the colours to brighter, dimmer, or even black, did not solve the issue for me.

History searching is a useful feature, but I'd like to only get it when I indicate that I want to use it. For this, I'm using fzf (https://github.com/junegunn/fzf), which allows history searching after an explicit key press (by default, ^R, like reverse-i-search in readline/bash). See also the (open) feature request #602. If you have fzf, autosuggest is redundant.

[BinaryBen]

This needs to be implemented in some form. I am using fish with mosh. It can get a little hectic when mosh is trying to predict what would come up, and fish is trying to suggest every option.

I don't mind if it isn't a core feature, but is it possible to create custom features and enable them by default? I am new to fish sorry.

[galbacarys]

Another reason to allow this to be disabled: My primary editor is spacemacs, and fish is _completely_ broken within the emacs ansi-term due to autosuggestion. It looks like emacs can't handle the control codes used to render the autocompletion prompt, and the output is completely garbled and unintelligible. I've spent a couple of months now using fish exclusively outside of emacs, and I love every minute of it, but I hate having to drop to bash or zsh within emacs because fish won't let me disable the autosuggestion.

I'm aware that this is technically an emacs bug rather than a fish bug, technically, but the option to disable _one feature_ in fish is much less burdensome for me than digging into the emacs ansi-term code to figure out what the hell is going on.

+1 for adding disable flag.

[faho]

@galbacarys: Are you running emacs inside of a terminal? If so, $fish_term24bit might be set (we enable 24-bit color mode for select terminals, and we do that based on exported variables, which might not be entirely correct). Try set -e fish_term24bit, that makes colors in ansi-term, including suggestions, work for me.

[galbacarys]

The problem for me isn't colors, it's the control codes that (I presume) are used to jump ahead and redraw the suggestions as you type. They aren't properly hidden by ansi-term, and I'm a little wary of jumping into the code for ansi-term. I'm using Emacs 24.5.1 on the latest OS X.

[faho]

I don't have any issues there. What does it look like?

There's also an issue related to the title, so you might want to do function fish_title; end in ansi-term (yes, that thing is seriously limited - it's got 8 colors).

[galbacarys]

Very common example:

I type cd .. and I see cd .4m. (newline) ., which makes me think fish is outputting characters ansi-term can't handle. It happens most often with cd though; it looks like argument completion works worse than command completion, as I investigate it more.

[faho]

@galbacarys: Please try set -e fish_term24bit or #3279.

[galbacarys]

No dice. Additionally, it seems that that option wasn't on by default, in a fresh session fish_term24bit is not set in ansi-term, which seems to indicate that something deeper is busted. Once again, it's _very_ probably emacs' fault (as you said, ansi-term is limited to put it kindly), but it's precisely cases like this (weird situations that are too much trouble to debug) that turning off autocomplete would make easier.

[krader1961]

I can reproduce the problem described by @galbacarys using emacs ansi-term mode in iTerm2 on macOS. I'll open a new issue to track this specific discussion since it should "just work" given a valid terminfo config for ansi-term. I don't view this specific problem as a compelling argument for making auto-suggestions configurable. It's also a very different type of argument from the others in this issue.

[BinaryBen]

Respectfully, how is the amount of data this would use over SSH not enough reason to provide an _option_? No one here is asking for it to be turned off by default.

This issue is two years old. Some further explanation as to why it won't be implemented would be appreciated. Even if it is, "we as the developers don't have time and just don't want to work on this" would be better than "please give us a reason" when perfectly valid reasons have been given (I.e., security and bandwidth usage).

This is literally the one thing stopping me from looking any further into switching to fish as my default shell. I can make other shells work similar to fish in many ways, with a little elbow grease, but I can't set a simple config option to turn _off_ one feature. It's very counterintuitive.

[krader1961]

@BinaryBen, how did you get the idea that your argument is being ignored?

Some further explanation as to why it won't be implemented would be appreciated.

The fish shell developers try very hard not to turn it into a zsh or bash clone by piling config options on top of config options. We strive to incorporate features that are useful to the vast majority of users and make them "just work" without needing lots of knobs that need to be tweaked.

perfectly valid reasons have been given (I.e., security and bandwidth usage)

The security argument will be addressed if I ever get back to working on the configurable history file issue (I have it half implemented). Once that is implemented you'll be able to start fish with an empty history perfectly suited for creating demonstrations.

Bandwidth usage does not appear to be a legitimate argument. Nor is that the argument you made earlier. I haven't carefully measured it but feel confident in saying (based on reviewing numerous script captures of fish's behavior) the extra data is inconsequential. Having said that I'm not surprised if the behavior of this feature reduces the effectiveness of mosh's predictive heuristics to reduce latency. And that alone might be a compelling reason to allow this to be configurable. I keep meaning to try mosh but simply haven't had the time.

I can't speak for the other developers but I'm still unconvinced by the other arguments which boil down to "I don't like it".

[krader1961]

P.S., In looking at the mosh home page I can't help but notice this line:

But mosh was designed from scratch and supports just one character set: UTF-8.

The sooner we implement my proposal to stop supporting non-UTF-8 locales and use UTF-8 internally rather than wide chars the better.

[BinaryBen]

Hi @krader1961, I didn't feel like my idea was specifically being ignored, but rather the whole idea of a new option.

Sorry, I've also conflated mosh and bandwidth together. I've used mosh due to being on bandwidth constrained networks. Every extra character the shell tries to send to my client can be hard. But, I am happy to believe you when you say it is inconsequential. It probably is. Happy to hear that mosh is being considered as a reason to make this optional (and yes please to UTF8!)

On the flip side though, I think arguments that boils down to "I don't like it" should be given more weight than technical reasons. It's supposed to be (as far as my, admittedly limited understanding goes) a Friendly shell, so if features that are supposed to be helping are getting in the way and slowing users down, then the software isn't working right from a user experience point of view (assuming that one of the goals is to make it friendly?).

I am wonder if it might be more appropriate to have different "levels" or "types" of autosuggestion depending on the users needs? New comers will no doubt appreciate autosuggest everything being on by default. The pros who like Fish's defaults but find autosuggestion is distracting and slows them down would want it off (it is unfriendly for them). And users like me may want a "suggest on pause" type option that hints if I type and wait a second or two (remember a package that starts with a letter but not what it's called, or same with a path in my history).

I don't think that anyone would confuse an option that _can_ be tweaked for an option that _needs_ to be tweaked to make it usable though. Especially when this is such a major part of interacting with fish. The option really should be there imho.

Just ideas. I'm also glad to hear that history will hopefully be configurable in the future. I'm also hoping to screencast eventually as well, so I can confirm it will be used! :)

[krader1961]

On the flip side though, I think arguments that boils down to "I don't like it" should be given more weight than technical reasons.

The problem with that line of reasoning is that if 1% of the user base dislikes a behavior (or wants something slightly different) the conclusion is it should be configurable. Down that road lies zsh. I switched from zsh (after using it for ~6 years) precisely because that level of configurability causes more problems than it solves. In particular I found things breaking because the behavior depended on whether or not a particular option was set. And given the lack of namespaces that is a major problem. This particular feature is probably not an example of that problem but the point remains that any configurable behavior needs to carefully weigh the pros and cons, with the conclusion being overwhelmingly in favor of the pro arguments, before implementing the configurable option. And it's not clear that has been shown for this issue.

Your idea to improve the autosuggestion behavior by introducing a short delay before showing the suggestion is the sort of thing more likely to be implemented rather than adding an option to turn it on or off. That's because we want these features to "just work" for 99% of users. Having said that the delay should definitely be shorter than two seconds. Something closer to 300ms is likely to be closer to an optimal value. Assuming, of course, that user testing shows a short delay before showing the suggestion is better than showing it immediately for most users.

[floam]

It is pretty bad over mosh [and a less than great connection]. I wonder if there is anything clever we could do to to paint the autosuggestions in a way that is more friendly with local echo and/or mosh heuristics.

[krader1961]

I wonder if there is anything clever we could do to to paint the autosuggestions in a way that is more friendly with local echo and/or mosh heuristics.

I have no idea but that solution is preferable to adding an option to disable autosuggestions. And if the only practical solution is to disable the autosuggestion feature when running over mosh it would be preferable to auto-detect that environment and do so automatically. Much like we do for terminals that don't correctly report their terminfo names. I have objections to disabling this feature because it interacts badly with a technology like mosh because doing so produces a wildly inconsistent user experience. But doing so seems preferable to adding another "knob" that can be tweaked and has to be tweaked by the user.

[galbacarys]

@krader1961 while I agree with you in principle, the fact remains that autodetection doesn't work for at least two different cases (those being ansi-term and mosh). I would treat that as a bug, and I understand your want to deal with this as a software issue; but at the end of the day, you're not going to be able to cover every esoteric configuration and idiosyncrasy of every terminal that has ever existed. I mean, what if someone comes on here tomorrow and starts ranting about how fish is totally broken on his VT-100? Obviously, you're not going to put the effort in to support that, and that's reasonable. But where do you draw the line?

The shell is a terrible environment to work with; it's loaded with 40-odd years of history, tradition, and conventions that don't make any goddamn sense. Fish does a great job (generally speaking) of smoothing over many of those rough edges, but ultimately covering _every possible_ screwed up terminfo/$TERM/color profile and combination thereof is just about impossible.

As much as I would love to find a software engineer's problem to this, I think that from a usability perspective (and, ultimately, from a software design perspective), a clean switch is much better than a messy hack. Neither is ideal, but unless the autodetection system is absolutely perfect, people will continue to complain.

[krader1961]

The shell is a terrible environment to work with; it's loaded with 40-odd years of history, tradition, and conventions that don't make any goddamn sense.

You make a lot of good points but you're wrong about that. My opinion is no doubt colored by my experiences starting with programming on a Teletype Model 33 as a 16 year old teenager in 1977 and then Hollerith punched cards before going to college where I had access to such marvels as the Hazeltine CRT that predated the DEC VT-100 but was substantially similar to it. Nonetheless, those conventions were, for the most part, carefully thought out and made sense for their time and quite a long time thereafter; even up to today.

You're correct that we can't possibly hope to handle every screwed up legacy environment in an optimal manner. Or for that matter current environments such as Linux on IBM mainframes where EBCDIC is the character encoding standard. That does not mean we should add options to support such environments. It might make more sense to just say "sorry, please use another shell like /bin/sh" rather than complicate fish.

[Juerd]

The patch mentioned above no longer works with the current version because the code for setters has been reformatted. Here's a new version of the hack to disable autosuggest:

diff -ur fish-2.3.1-orig/src/reader.cpp fish-2.3.1/src/reader.cpp
--- fish-2.3.1-orig/src/reader.cpp  2016-07-03 14:15:45.000000000 +0200
+++ fish-2.3.1/src/reader.cpp   2016-08-03 15:19:37.612228454 +0200
@@ -2588,7 +2588,7 @@

 void reader_set_allow_autosuggesting(bool flag)
 {
-    data->allow_autosuggestion = flag;
+    data->allow_autosuggestion = false;
 }

 void reader_set_expand_abbreviations(bool flag)

[BinaryBen]

The problem with that line of reasoning is that if 1% of the user base dislikes a behavior (or wants something slightly different) the conclusion is it should be configurable. Down that road lies zsh. I switched from zsh (after using it for ~6 years) precisely because that level of configurability causes more problems than it solves.

I agree with you, I don't want fish to become zsh either. I am fairly new to the world of terminals and Linux in general, and in looking into the different options available - I liked that fish "just worked" for most cases out of the box. I didn't want to spend too long setting up every config option for a shell.

That said, I think it may be better to read "I don't like it" as "I don't like it because it interferes with my workflow/is distracting/slows me down." These are user experience problems, and for many, the easiest option may be to just turn them off (or have a shortcut key toggle to turn them on and off?). Ideally, it would be appreciated to have different "levels" of auto suggestions (+/- time delay, +/- history, +/- autosuggest software flags, etc.), but I would be just as happy to have a simple on and off switch from a UX point of view.

Surely this would be simpler than trying to code for every edge case as well? Surely it makes sense to allow users to have this option available to themselves if it is there for edge cases? I do get what you mean by this level of config causes compatibility problems essentially, but is there anything that actually relies on fish having autosuggest functionality? And is autosuggest considered absolutely core and vital to the experience for fish? If it is, that's fine. But it would be nice to have that sort of clarification so users can decide if Fish is for them. Maybe it is the case that Fish is mainly targeted at new shell users and not for experienced users (to be clear, this is not me currently; I would like to keep the autosuggest on some of the time while I learn new tools) who don't mind having at least some options?

I'm not attacking by the way - just looking to find a suitable "home" when it comes to the shell. For me, autosuggest 100% of the time doesn't feel like home. It just feels like it's nagging me. That's not friendly in my experience.

[ridiculousfish]

There's two questions:

1: How should fish approach compatibility with weird/broken/esoteric environments?

There's a lot of weird stuff that fish does, like the PROMPT_SP hack, fish_title, color, etc. each of which is incompatible with some environments. Our approach has been to try to detect these environments and use whitelisting/blacklisting to selectively enable the feature. This is a better experience than putting the onus on the user to set an obscure option, and it reduces our testing matrix: we only have to test with the environments as they exist, not all of those environments multiplied by the number of configuration combinations.

2: How much configurability should fish build into its UI?

We're sensitive to the fact that shells are highly personal. fish allows customization in some areas (font, prompt, key bindings) but not others. The line is subjective and there's close calls, but as a general principle we don't have "disable the feature entirely" as a configuration option. If a feature isn't good enough to be on by default, it shouldn't be in the shell; a weaker form is that if you have to introduce the feature with an option to disable it, it probably shouldn't be in the shell.

In the case of autosuggestions, the feature is designed to be very non-intrusive. It uses a low-contrast color, it does not block your typing, it requires manual acceptance. Objectively it's hard to see how it could "get in the way;" I'll wager that most negative reactions are due to not-what-I'm-used-to, or suspicion of its implementation. (If you really find it distracting, maybe try changing the color to fit your terminal background.)

That said, the mosh stuff is real and we should definitely try to make it better. But let's exhaust conventional bug-fixing before we contemplating giving up and disable it.

[krader1961]

I'll wager that most negative reactions are due to not-what-I'm-used-to...

Bingo. You'll find that my first comment on this issue was in support of being able to disable the feature. Why? Because at the time I had only been using fish for a couple of months and this feature wasn't what I was used to given 20+ years using other shells like ksh93 and zsh. A couple of weeks after making that comment I changed my mind because the feature no longer seemed weird.

[krader1961]

If I ever make the investment to switch to mosh I'll have incentive to fix this. In the meantime, if someone like @floam or @BinaryBen who is currently using fish over mosh wants to take a stab at improving the experience I'll be happy to provide feedback and do code reviews.

[whyrusleeping]

I'd like to be able to turn this off temporarily for recording asciicasts. Having fish ghost complete something i'm about to demo kinda makes things a bit weird.

[krader1961]

@whyrusleeping: Disabling autosuggestions per-se will probably not be implemented. What we do intend to support is disabling command history or switching to a different history file. See issue #102. That will address the "I don't want my history showing up when I do demos" aspect of this issue.

I was going to close this as a duplicate of #102 but after rereading it I see that the other reason people want to disable autosuggestions is to get a better experience using mosh. Since we don't already have another open issue addressing that I'm going to change the title of this issue to make it clearer what this issue is meant to address.

[iomintz]

Hey @ghost what prompt do you use? Offtopic but it's really cool.

[laughedelic]

@bmintz here are some similar ones: nitro, metro, bobthefish.

[timrossback]

+1 for an option to disable autocomplete/suggestions.

[cgull]

Mosh master has a new --predict-overwrite option that will likely behave better with fish-- it doesn't shift text to the right of the cursor, which matches better with fish's autocomplete.

[nickmaine]

Short story: After reading a few threads, there is still no way to disable auto suggestions?

[BinaryBen]

Correct. Well I don't use fish now due to this, so maybe something has changed. But I am reasonably confident.

[juho-p]

I would also like to see less intrusive autosuggest system that wouldn't change what I've already typed, as @jovaha said few years ago here.

[mqudsi]

A new feature has just been added to master slated for inclusion in fish 3.0 that addresses a number of the issues (rightly) raised in this thread.

Fish 3.0 features a private mode that can be started with fish --private (or fish -P) which starts up with the history file disabled. In this mode, fish has no access to prior session history (so ghosted suggestions will not potentially leak sensitive/personal information) and history from this session will not be persisted (it is memory-resident only).

Within a private mode session, automatic suggestions are available only from the current (private) session history, reflecting commands entered since the session started.

Additionally, fish announces private mode via the $fish_private_mode read-only variable that is set if fish was started in private mode. The fish team encourages script developers to query for and respect the presence of this variable if there are actions their scripts can take to improve privacy or refrain from persisting data.