Help wanted adding paste-delay, a bracketed-paste feature

[Karl O. Pinc]

Hello,

I'm looking for guidance and help developing a patch.  Here is the
NEWS entry describing the feature I'm trying to implement:

k. There is a new option: `enable-paste-delay'.  This controls the
   interpretation of newlines in pasted text when bracketed-paste mode
   is on.  The default is off, newlines are interpreted in pasted text
   in the same manner as when typed at the keyboard.  In this case
   pasting does not enable the active region.  Users can turn this
   option on to allow editing and review of pasted text, in which case
   the newline key on the keyboard must be pressed to submit the
   pasted text to the running application.

The "plumbing", i.e. the configuration settings, documentation, etc.,
all seem to work.  But the feature does not.  (And, there may be an
existing readline bug when using `bind' in bash to adjust settings.  Or
not.  See below.)  I may not be understanding how to use the variables
and functions of readline. And I'm definitely making other mistakes,
but am presenting what I have so far for review.  It seemed time to
stop bumbling around and ask for help.  I could also use some guidance
on the mechanics and conventions of texinfo.  Details follow.

Attached: paste-delay_v1.patch
Apply to "devel" branch.

The attached patch is only to "source" files.  Generated files are not
included.  No changes were made to the CHANGELOG or CHANGES file but I
did add a NEWS entry.


Regarding the code in the patch:

The code that's failing is in _rl_bracketed_text() of kill.c.  This is
clearly the wrong place to make changes because it's called and then
the input is "unwound" in multiple places.  So anything that's done to
feed lines of pasted text to the application might be erroneously
redone multiple times. I'm thinking that _rl_bracketed_paste_begin()
might be the right place to make changes.  Notwithstanding the poor
choice of function to patch, _rl_bracketed_paste_begin() calls
_rl_bracketed_text() so I expect to see the same sort of behavior if I
move my changes into _rl_bracketed_paste_begin().  But I see 3 (?)
problems when testing the existing patch, with enable-bracketed-paste
on and enable-paste-delay off (the defaults).

1) The pasted text is not echoed to the terminal.

2) Calling rl_newline() does not seem to be delivering what I have
inserted into rl_line_buffer to the application.

3) An extra newline seems to be appended to the pasted text.
(Testing with examples/rlcat.)

Maybe I should understand what the return value of
_rl_bracketed_paste_begin() means, given that I think my code is
making it return 1 instead of 0.  Without the patch I'm just not
seeing how the return value is ever anything other than 0.

Or perhaps I'm fundamentally mis-understanding something.

Is _rl_bracketed_paste_begin() the place to work?  It seems feasible
to have _rl_bracketed_paste_begin() (conditionally, on
_rl_enable_paste_delay) look through the result of
_rl_bracketed_text() for newlines, stick them in rl_line_buffer, and
call rl_newline() (?) to deliver each line to the application.

If the code is to look through the result of _rl_bracketed_text() for
newlines, the multibyte encodings supported by readline are
significant.  What Unicode encodings are supported for multibyte
support?  UTF-8 is easy to look through for newlines, but other
encodings not-so-much.  I didn't find anything in the docs.
(Maybe the docs need improving?)

I don't really get the internal bracketed paste API and code paths.
(Sorry.)  There's a lot in the comments about being able to call the
bracketed paste related functions instead of the "stock" functions,
but is that something that is done?  Are code changes needed in more
than one bracketed paste function?  (Like my commented out code at the
bottom of _rl_bracketed_read_key(), which does not seem to do anything
when un-commented.  Although I don't know that my testing is adequate.)


Random questions and observations about the (devel branch) code:

Given the existing calls to _rl_bracketed_paste_begin(), it seems to
me that the condition in the last "if" in the function will always be
true.  The "lenp" argument is always passed an address. (?)

I suspect (without testing) that there is a bug in that if, in
inputrc, enable-active-region is set before enable-bracketed-paste or
enable-paste-delay that the enable-active-region setting will be
ignored.  It seems odd to be order-dependent like that.  Similar
considerations would apply when adjusting settings with `bind' in bash.
But, if there is such a problem, then I believe it already existed
before this patch, as regards setting enable-bracketed-paste and
enable-active-region with `bind' in bash.  (Not my problem! ;-)

I'm unclear on the active region.  There's code that seems to imply
that it is used only in the case of bracketed-paste, but then it also
seems to be used in other situations (search & ??).  So I don't know
how to think about fixing whatever problem there may be with the
ordering of inputrc lines and use of `bind'.

I am unclear on the interactions involving macro callbacks and
bracketed paste mode.  My use of RL_STATE_MOREINPUT in kill.c may be
incorrect.  This is probably irrelevant if I move the patched code out
of _rl_bracketed_text() so maybe I don't care.

It seems kind of wonky to include generated files (doc files and even
./configure) in the git repo.  No need to comment or justify this, but
I am curious if anyone wants to respond.

It is also awkward that "necessary" files (./configure, doc/texi2dvi,
doc/texi2html) are not executable.  Again, no need to comment or
justify this, but I am curious if anyone wants to respond.

FYI, on my Debian stable (Debian 11, bullseye) (cd doc; make) fails
with:

/texi2html -menu -monolithic -I . ./rlman.texi
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at 
./texi2html line 4858.
make: *** [Makefile:157: readline.html] Error 2


Questions about texinfo:

I don't like the output in the info pages where I use @var{} on
configuration setting names.  What is the right way to do this?

I'd like to include cross references between the various inputrc
settings in the documentation changes, but don't like embedding them
in sentences.  They break the flow of the sentence.  Any suggestions?
I'm happy enough to leave well enough alone.


All comments and help appreciated.

Apologies, but I may not have a lot of time to work on this right now
and may not respond in a timely matter.

Regards,

Karl <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

paste-delay_v1.patch
Description: Text Data