[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash-5.1-rc1 available

From: dancol
Subject: Re: Bash-5.1-rc1 available
Date: Tue, 20 Oct 2020 14:01:26 -0700
User-agent: Roundcube Webmail/1.2.3

On 2020-10-20 13:44, Bob Proulx wrote:
Chet Ramey wrote:
This release fixes several outstanding bugs in bash-5.0 and introduces
several new features.

An unlisted change (I couldn't locate it in the changes) is that
'reverse-search-history (C-r)' now highlights the search pattern.  Is
that because it is the search pattern or because it now sets the region?

    'reverse-search-history (C-r)'
         Search backward starting at the current line and moving 'up'
         through the history as necessary.  This is an incremental search.
This command sets the region to the matched text and activates the

f. New active mark and face feature: when enabled, it will highlight the text inserted by a bracketed paste (the `active region') and the text found by
   incremental and non-incremental history searches.

I find the reverse video highlight to be very difficult to read.  For
me it is extreme eye strain.  Is there a way to disable the reverse
video?  For both the paste text and the search text?

This is so bad for me that for the moment I had to revert to the
previous version of bash to avoid it.  (Note that disabling bracketed
paste mode avoids it for the paste but doesn't address the reverse
video of search.)

The problem right now is that the "face" mechanism is very primitive compared to Emacs'. In Emacs, you can define the attributes of a face to be whatever you want: if you want to make readline highlight things in underlined red, more power to you. Bash's highlight face is hardcoded to use the terminal "standout" mode, which can mean whatever the terminal wants it to mean. Normally that's fine, but it seems like your terminal defines standout to be something ugly. It seems reasonable to add a knob to make bash's FACE_STANDOUT mean the same as FACE_NORMAL, but I think a better solution is to add an Emacs-like ability to define at runtime what each face actually means.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]