irb icon indicating copy to clipboard operation
irb copied to clipboard

Default behavior change ( AUTOCOMPLETE, COLORIZE )

Open log69 opened this issue 2 years ago • 22 comments

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.

log69 avatar Mar 03 '22 15:03 log69

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/

olleolleolle avatar Mar 03 '22 16:03 olleolleolle

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.

log69 avatar Mar 03 '22 16:03 log69

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.

sshock avatar Mar 05 '22 07:03 sshock

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

kaiquekandykoga avatar Mar 08 '22 15:03 kaiquekandykoga

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

wlipa avatar Mar 09 '22 20:03 wlipa

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...

csutter avatar Mar 10 '22 10:03 csutter

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.

DanielLemky avatar Apr 30 '22 03:04 DanielLemky

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

yvasilkov avatar May 04 '22 11:05 yvasilkov

~~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: https://github.com/jcs/no_color/pull/180

st0012 avatar May 16 '22 20:05 st0012

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

vatosarmat avatar Jun 20 '22 12:06 vatosarmat

@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 avatar Jun 28 '22 10:06 st0012

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

st0012 avatar Nov 06 '22 21:11 st0012

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.

touretzkyds avatar Nov 06 '22 22:11 touretzkyds

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

Screenshot 2022-11-15 at 15 30 00

deepakmahakale avatar Nov 15 '22 10:11 deepakmahakale

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

Screenshot 2022-11-15 at 15 30 00

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

slimdave avatar Nov 30 '22 11:11 slimdave

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.

st0012 avatar Nov 30 '22 12:11 st0012

I think disabling it on production makes sense.

deepakmahakale avatar Nov 30 '22 12:11 deepakmahakale

Some updates:

  • From the next IRB release (and Ruby 3.2), you'll be able to disable 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 - https://github.com/rails/rails/pull/46656

st0012 avatar Dec 06 '22 15:12 st0012

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

DougPuchalski avatar Mar 09 '23 20:03 DougPuchalski

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).

dbackeus avatar Mar 14 '24 13:03 dbackeus

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

Joseph-D-Bradshaw avatar Aug 06 '24 15:08 Joseph-D-Bradshaw

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

Screenshot 2024-08-06 at 16 45 21

st0012 avatar Aug 06 '24 15:08 st0012