Default behavior change ( AUTOCOMPLETE, COLORIZE )

[log69]

Dear Devs, I'd like to suggest to turn off autocomplete and colorization by default for the following reasons:

1. The autocomplete list is shown in color and cannot be read at all if the environment and desktop colors are set in a different way
2. The colorization has the same problem, because the terminal colors are preset and if the highlight scheme is not good then the text cannot be red (too bright yellow on white etc)

It would be the safest and sanest way to provide the most robust settings by default that has the smallest problem set. Thank You.

[olleolleolle]

The NO_COLOR environment varaible, could that help this use-case?
https://github.com/ruby/irb/search?q=NO_COLOR

See also:
https://no-color.org/

[log69]

The problem is not the setting. I can do that by creating a file called .irbrc in $HOME as the following:

IRB.conf[:USE_AUTOCOMPLETE] = false
IRB.conf[:USE_COLORIZE] = false

The problem is having to create this file all the time on all servers and client nodes initially everytime a quick work needs to be done.

Thanks for the suggestion anyway because it may be good as a workaround.

[sshock]

This is an issue for me as well. The colorization often slows everything to a crawl, which can be especially painful when it happens in the middle of a paste. And the autocomplete is a bright cyan bg color that is completely unreadable.

These are both awesome features to be sure, but I have to agree they should be off by default! I manage a lot of servers and now I have to go configure .irbrc in the way @log69 described on each one of them to disable these.

[kaiquekandykoga]

Perhaps already known, but I would like to complement saying that it is also possible to initialize IRB disabling autocomplete and colorize with options.

irb --noautocomplete --nocolorize

[wlipa]

Definitely agree. The autocomplete UI is invasive and distracting. It should be something you opt into rather than something turned on for you.

[csutter]

Yes please – really struggling with this when using IRB through the Rails console on deployed applications.

It's also incredibly slow and inaccurate in the context of a large codebase...

[DanielLemky]

Agreed. The autocomplete suggestions often cause the terminal window to scroll up so that the current line jumps to the top of of the terminal window due to the number of suggestions that appear, particularly when using the terminal in the bottom of an IDE where the window height is limited. This becomes a nuisance when reading from a previous line and all of a sudden the window jumps up due to numerous suggestions being shown.

[yvasilkov]

Agree. The autocomplete considerably slows down typing, while options list is updating the 'Delete' (on Mac, same as Backspace) keystrokes are not captured.

[st0012]

irb could be run on multiple platforms and any environment (dev, test, and prod), so I think following the convention to introduce the NO_COLOR env is important. The problem is, irb's coloring control is scattered and there's no standard API for that.

I've taken a first step on tackling the issue in #362. I'll introduce the NO_COLOR env after all refactoring is done.

Sorry that I misread the comment! The NO_COLOR env var has been supported in irb.
I also opened a PR to no-color.org to update the table: jcs/no_color#180

[vatosarmat]

Instead of annoying auto trigger, how about show completion window in response to Tab keypress?

[st0012]

@vatosarmat That's a great idea! But the dialog triggering logic seems to be buried deep in reline. So it may be harder to change compare to other improvements.

Based on the user feedback I have seen, I think the priorities are:

1. Improve the background color
2. Suggestion improvements (number limit, accuracy...etc.)
3. Support different triggering mechanisms as you suggested

[st0012]

FYI, this is the reline API proposal that'll allow irb to configure the completion colors.

[touretzkyds]

I agree with the other commenters here. The autocomplete feature is intrusive and annoying, and it causes unwanted scrolling. It should never have been enabled by default.

[deepakmahakale]

Does anyone know how to disable it on the Heroku console 😐

[slimdave]

Does anyone know how to disable it on the Heroku console 😐

You can pass nomultiline as an argument, but need to wrap the rails command and funky argument passing in dobule-quotes.

heroku run "rails console -- --nomultiline" -a my-app-name

[st0012]

Would you hope Rails to disable autocompletion in production? Usability issues aside (as listed in #445), autocompletion also increases data transfer (sometimes, a lot), which could make using it on a remote server slower. Therefore, it's safer to disable it in production.

[deepakmahakale]

I think disabling it on production makes sense.

[st0012]

Some updates:

• From the next IRB release (and Ruby 3.2), you'll be able to disable autocompletion with IRB_USE_AUTOCOMPLETE=false - Allow disabling autocompletion with IRB_USE_AUTOCOMPLETE=false  #469
• Rails 7.0+ will disable rails console's IRB autocompletion in production by default if the IRB supports the above flag - Disable Rails console IRB's autocompletion in production by default. rails/rails#46656

[DougPuchalski]

Features like this should not be enabled by default. This causes a huge productivity hit, and it's hard in large environments to schedule changes to get rid of this sort of thing

[dbackeus]

Just to voice the other side of the argument here...

While performance was unbelievable bad, to the point of making autocomplete/color unusable in early iterations. With the latest Ruby / irb version it performs perfectly fine (even on large Rails applications) in my experience and vastly enhances the REPL experience.

While I think it's reasonable for Rails to disable it in production consoles by default, I also think it's worth stating that autocomplete can work perfectly fine in remote settings as well. The main issue here is that cloud providers like Heroku have abysmal performance on their one-off dynos. When running on decent hardware there is no problem whatsoever using autocomplete on a remote console.

At the end of the day I think the IRB team should focus on improving the user experience of autocomplete (by further improving performance) and colors (by ensuring sufficient customisability and a good default color scheme - which may already be in place) rather than hide these features behind an explicit flag (which will most likely kill both usage and progress since few people will even realize these flags exist and useful feedback won't propagate).

[Joseph-D-Bradshaw]

Can the default colour of irb for autocomplete be something readable? It is really hard to read white on cyan. It seems if I want to configure it I must go through adding the reline gem, installing it and setting some reline specific settings. Where I would vastly prefer being able to set directly through .irbrc out the box

[st0012]

If you install the latest irb and reline, the default color is now black and white

[st0012]

Over the last 2 years, we shipped a lot of improvements in IRB and Reline to address autocompletion related issues. And major problems like coloring and the dropdown UI's behaviour have both been fixed in the latest releases. Therefore, I'm closing this issue as completed.

If you still see autocompletion related issues after upgrading to the latest IRB, please open new issues describing the problem in detail and with screenshot. It'll really help us investigate and fix the issue 😄

[jedrekdomanski]

I opened a PR #1020 to disable the the annoying and intrusive autocomplete by default but they said people don't complain about it anymore :D I have no more questions...

[wlipa]

I'm using the latest. My problem with it is that I just don't want ASCII pop up menus appearing in my terminal at all without explicitly summoning them. It's very intrusive and annoying. You can't type anything without a distracting slab of options appearing. I don't have any other command line tools that do this.

If it was invoked by a tab or esc or something, it'd probably be something I could tolerate, and even get some benefit from. But not from typing any letter.

[st0012]

I'm not arguing that this feature is perfect and should be used by everyone. If you go up to see earlier comments, I'm very aware of the problems and even made disabling it easier.

But it's also a feature that has been released and used for almost 3 years, which is even before I became a maintainer of this project. So as I have explained in #1020:

Unless you can prove or convince us that most of the Ruby developers using the latest IRB and Reline are still suffering the problem and actively seeking a way to disable autocompletion, turning it off by default is a massive breaking change that'd require many users to enable it manually. Therefore, we will not make this decision lightly.

Turning it off by default is not a decision we can easily do without strong justification.

[jedrekdomanski]

Turning it off by default is not a decision we can easily do without strong justification.

If you read this and many other posts on the internet (on Stackoverflow and Reddit to take the least) you will understand why people are not happy with the autocomplete feature. I feel disappointed that despite clearly explaining my arguments for disabling this functionality by default, it seems like you didn't take them into consideration at all, nor allowed any discussion on the matter. Instead, you closed the PR and this issue without any dialogue. It feels as though you've dismissed my concerns as if people don't have a problem, and ignored my input entirely.

[wlipa]

Turning it off by default is not a decision we can easily do without strong justification.

From my point of view it was turned on without strong justification, although of course it's the developers' right to do so. But where does the belief that most people like this feature come from? Is there any more evidence for that than the reverse? I suggest that there isn't. And in that case, the tool should use the least surprising and invasive behavior.

[tompng]

Deciding the default behavior a design decision. It's a matter of taste, so choosing whichever, someone will be dissatisfied.

I can see many people wanted to disable autocompletion, often by performance/appearance reason. I also hear many voice from people I met directly that they like the latest autocompletion.
We're mostly talking about fixable problems of performance and appearance in this issue. These are already significantly improved.
I think thats enough reason to close this issue. The situation has fundamentally changed since this issue was filed.

Which is the future?

VSCode and Chrome developer tool enables autocompletion by default. Autocomplete by default is generally considered more beneficial if it works perfectly. Same for syntax highlighting.
Completion accuracy will improve in Ruby 3.4. Even numbers.map(&:chr).each{_1. can autocomplete String methods. The benefit of enabling autocompletion by default is increasing.

Even if autocompletion is problematic and not good enough (I don't think so), this can be a reason to enable it by default and move forward.

[slimdave]

Even if autocompletion is problematic and not good enough (I don't think so), this can be a reason to enable it by default and move forward.

As long as it can still be disabled using --nomultiline etc on the command line then the choice of default is moot.

[amomchilov]

Is there any more evidence for that than the reverse? I suggest that there isn't

We have a selection bias here. People who like a run-of-the-mill auto-completion feature don't have any reason to open issues about how great it is.

[DougPuchalski]

It doesn't matter how many people like it. It doesn't scale. Just because a mistake was made doesn't mean it should remain in place forever.

[amomchilov]

@DougPuchalski You brought it up, I'm just responding to that:

But where does the belief that most people like this feature come from?

[jedrekdomanski]

I'm not arguing that this feature is perfect and should be used by everyone. If you go up to see earlier comments, I'm very aware of the problems and even made disabling it easier.

But it's also a feature that has been released and used for almost 3 years, which is even before I became a maintainer of this project. So as I have explained in #1020:

Unless you can prove or convince us that most of the Ruby developers using the latest IRB and Reline are still suffering the problem and actively seeking a way to disable autocompletion, turning it off by default is a massive breaking change that'd require many users to enable it manually. Therefore, we will not make this decision lightly.

Turning it off by default is not a decision we can easily do without strong justification.

You are saying that irb was improved but I'm not sure if you are aware that IRB does a new search with EVERY key press so when I press a backspace button to delete a single character in a line the autocomplete completely blocks typing and typing becomes a nightmare. So we have a different opinion about the performance. In my opinion this is a strong justification to disable it by default.

[tompng]

IRB does a new search with EVERY key press

This is not a problem if the performance is not bad.
Even if autocompletion is turned off, syntax highlighting also blocks typing. IRB parses the whole input on every keystroke. In most case, this is SLOWER than the latest IRB's autocompletion with Ruby 3.3.
Even if syntax highlighting is turned off, Reline re-calculates text wrap on every keystroke. This could be SLOWER than calculating autocompletion in some case.

Please provide a detailed situation of slow autocompletion in a separate issue if you are using the latest IRB. It will help us fix the problem. (Example: completion of symbol is slow in rails console)