Re: [PATCH] Add active mark, face support; activate mark on paste

> On 3/25/20 4:18 PM, Daniel Colascione wrote:> > >> I haven't touched the face > code in display.c. I'd like to find a simpler> >> way to do it: the patch > seems to have a lot of overhead and adds more> >> complexity than I'd like at > a time when I'm trying to make the redisplay> >> code si

Re: [PATCH] Add active mark, face support; activate mark on paste

Apr 11, 2020, 17:19 by chet.ra...@case.edu: > On 4/11/20 8:43 AM, gentoo_esh...@tutanota.com wrote: > >> It silently segfaults when pasting a line of text twice(or a long enough >> line once), seems to be length dependent, unsure. >> >> Removing commit ea31c00845c858098d232bd014bf27b5a63a668b

Re: [PATCH] Add active mark, face support; activate mark on paste

Apr 11, 2020, 23:11 by chet.ra...@case.edu: > On 4/11/20 12:04 PM, gentoo_esh...@tutanota.com wrote: > >>> >>> What's your $PS1? >>> >> $ echo $PS1 >> \ ---\n\ \[\a\]\ \[\e[1;37m\e[42m\]\u@\H\[\e[0m\] \ >> \[\033[1;30m\]$(date "+%Y/%m/%d %H:%M:%S")\[\033[0m\] \ \[\e[0;37m\]\s\V >> t:\

Re: [PATCH] Add active mark, face support; activate mark on paste

Apr 12, 2020, 19:30 by chet.ra...@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.0 > -0400 > --- lib/readline/display.c2020-04-12 12:01:22.0 -0400 > *** > *** 1

Re: [PATCH] Add active mark, face support; activate mark on paste

Apr 13, 2020, 05:04 by dan...@dancol.org: > > > FWIW, for debugging the kinds of issues we're discussing here, rr(1) is > _incredibly_ helpful. > I can't use 'rr' due to system requirements: https://github.com/mozilla/rr#system-requirements $ sudo sysctl kernel.perf_event_paranoid=1; rr rec

Re: [PATCH] Add active mark, face support; activate mark on paste

Apr 14, 2020, 22:53 by chet.ra...@case.edu: > On 4/14/20 4:46 PM, gentoo_esh...@tutanota.com wrote: > >> Another 'face' issue(the 3rd?) I just noticed now: >> if I paste something that has "\n" inside it, like these 3 lines(only the >> first 2 lines have \n, but doesn't matter): >> -bash: mk_add_

looking for consistent C-c trap behavior

I've noticed that if I trap SIGINT in a bash script, the behavior when encountering C-c depends on whether an external command (eg. 'sleep 100') or a builtin command (like 'read -p') was encountered. I attach an example script which requires me to press C-c twice to interrupt the builtin 'read

Re: How can redirection operator aka ">" open output in append instead of ordinary write mode?

the only issue I've encountered with this so far is that 'dd' will fail some of its tests because it's not using of=  but instead using the redir operator and then it assumes it's NOT open in append mode ;)) so then it tries to seek past EOF (which doesn't work in append mode) to make holes(of z

Re: looking for consistent C-c trap behavior

Apr 17, 2020, 22:02 by dual...@gmail.com: > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for > the GNU Bourne Again SHell wrote: > >> >> I've noticed that if I trap SIGINT in a bash script, the behavior when >> encountering C-c depends on

Re: looking for consistent C-c trap behavior

Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com: > > > > Apr 17, 2020, 22:02 by dual...@gmail.com: > >> On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for >> the GNU Bourne Again SHell wrote: >> >>> >>> I've noti

Re: looking for consistent C-c trap behavior

Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com: > > > > Apr 17, 2020, 22:02 by dual...@gmail.com: > >> On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for >> the GNU Bourne Again SHell wrote: >> >>> >>> I've noti

Re: looking for consistent C-c trap behavior

Apr 18, 2020, 22:03 by chet.ra...@case.edu: > On 4/17/20 3:59 PM, gentoo_eshoes--- via Bug reports for the GNU Bourne > Again SHell wrote: > >> I've noticed that if I trap SIGINT in a bash script, the behavior when >> encountering C-c depends on whether an extern

Re: looking for consistent C-c trap behavior

Apr 18, 2020, 23:41 by gentoo_esh...@tutanota.com: > > On another note, I naively tried to patch out the POSIX requirement, for my > own/local_use puposes but had no effect: > in this code > +  /* posix mode SIGINT during read -e. We only get here if SIGINT is > trapped. */ > +  if (posixly_

Re: looking for consistent C-c trap behavior

Apr 19, 2020, 21:20 by chet.ra...@case.edu: > On 4/18/20 6:45 PM, gentoo_esh...@tutanota.com wrote: > >> >> >> The code that allows 'read -p' to be interrupted when posixly_correct, must >> then be somewhere else, I shall keep lookin', yet I fear I might not find it >> :-" >> > > Look in read

pasting in bracketed-paste mode breaks reverse-i-search

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -pipe -march=native -Wno-trigraphs -fno-schedule-insns2 -fno-delete-null-pointer-checks -mtune=native -fomit-frame-pointer -O2 -D_FORTIFY_SOURCE=2 -DQT_FORCE_ASSERTS

Re: pasting in bracketed-paste mode breaks reverse-i-search

Apr 21, 2020, 16:14 by chet.ra...@case.edu: > On 4/20/20 9:32 PM, gentoo_eshoes--- via Bug reports for the GNU Bourne > Again SHell wrote: > >> pasting while in reverse-i-search undoes it >> Repeat-By: >> $ bind 'set enable-bracketed-paste on' >> sel