Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: gentoo_eshoes@tutanota.com
Newsgroups: gnu.bash.bug
Subject: Re: [PATCH] Add active mark, face support; activate mark on paste
Date: Sun, 12 Apr 2020 20:15:42 +0200 (CEST)
Lines: 62
Approved: bug-bash@gnu.org
Message-ID: <mailman.110.1586715349.3066.bug-bash@gnu.org>
References: <M4dFweU--3-2@tutanota.com> <875c423e-0420-78d2-af4b-dfb168432e2d@case.edu> <M4dz8wC--3-2@tutanota.com> <902c38ef-7534-8f6d-51b7-daa0843b8440@case.edu> <M4glUEn--3-2@tutanota.com> <4b6878e3-adb3-50e2-d2b3-c66fe96f57bb@case.edu> <M4jafDF--3-2@tutanota.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: chet.ramey@case.edu, bug-bash@gnu.org
To: Chet Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <4b6878e3-adb3-50e2-d2b3-c66fe96f57bb@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:16126




Apr 12, 2020, 19:30 by chet.ramey@case.edu:

>
> I'm glad it worked, but I think this is a more correct version:
>
> *** ../bash-20200408/lib/readline/display.c	2020-04-07 14:55:15.000000000 -0400
> --- lib/readline/display.c	2020-04-12 12:01:22.000000000 -0400
> ***************
> *** 1759,1762 ****
> --- 1759,1765 ----
>  nd = newbytes;
>  nfd = new + nd;
> + 		  ofdf = old_face + oldbytes;
> + 		  nfdf = new_face + newbytes;
> +
>  goto dumb_update;
>  }
>

tested it to (also) work.

There is one more/different 'face' issue: if I paste a line and then press Enter (as opposed to any alphanumeric key or arrow keys) then the highlight remains(highlighted), possibly because the ^M is echoed and thus moves the cursor one line up(?) before the highlight is attempted to be removed. But I'm just guessing.




>>>
>>>
>
> It may be the case that this is called from a signal handler context, where
> the terminating signal is blocked. This patch should fix that:
>
> *** ../bash-20200408/sig.c	2020-04-07 16:41:19.000000000 -0400
> --- sig.c	2020-04-12 13:26:50.000000000 -0400
> ***************
> *** 609,613 ****
>  /* We don't change the set of blocked signals. If a user starts the shell
>  with a terminating signal blocked, we won't get here (and if by some
> !      magic chance we do, we'll exit below). */
>  set_signal_handler (sig, SIG_DFL);
>
> --- 609,617 ----
>  /* We don't change the set of blocked signals. If a user starts the shell
>  with a terminating signal blocked, we won't get here (and if by some
> !      magic chance we do, we'll exit below). What we do is to restore the
> !      top-level signal mask, in case this is called from a terminating signal
> !      handler context, in which case the signal is blocked. */
> !   restore_sigmask ();
> !
>  set_signal_handler (sig, SIG_DFL);
>
>
Confirmed working, much appreciated. Cheers!
That's an intriguing patch format, may I inquire as to how it was generated (some unusual 'diff' args?) ?