Bug 253142 - devel/readline: Add option for bracketed paste feature
Summary: devel/readline: Add option for bracketed paste feature
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Po-Chuan Hsieh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-31 22:09 UTC by ice
Modified: 2021-08-08 22:34 UTC (History)
9 users (show)

See Also:
ice: maintainer-feedback-


Attachments
Rough patch to make this behavior configurable (737 bytes, patch)
2021-07-02 16:41 UTC, j.david.lists
no flags Details | Diff
ports tree patch for bracketed paste as default-off option (627 bytes, patch)
2021-07-02 19:56 UTC, Michael Büker
no flags Details | Diff
ports tree patch for bracketed paste as default-on option (711 bytes, patch)
2021-08-06 17:26 UTC, Michael Büker
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ice 2021-01-31 22:09:30 UTC
Readline 8.1 by default enables bracketed paste (by having introduced a new configure option, --enable-bracketed-paste-default, which is on by default).

This seems like quite the behaviour change to chuck on unsuspecting people, so I'm suggesting to add --disable-bracketed-paste-default to CONFIGURE_ARGS.

On the off chance I am not the only one ticked off by this, adding 'set enable-bracketed-paste off' is the way to turn it off[*]. Since now there is a(nother) publicly documented way people may find, feel free to WONTFIX.

* as helpfully shown on https://www.garyshood.com/bash-highlight/
Comment 1 Chris Hutchinson 2021-02-02 19:26:25 UTC
Can I request that if the proposed option:
'set enable-bracketed-paste off'
is incorporated. That it be on by DEFAULT?
I too feel this is an astonishment. That can
cause too much unexpected outcome for no
*immediately* apparent reason.

Thanks
Comment 2 Michael Büker 2021-06-07 07:20:53 UTC
Quite a number of users appear to be irritated by this, myself included. These forum threads are fruther evidence:
https://forums.freebsd.org/threads/freebsd-13-annoyances.79815/post-505975
https://forums.freebsd.org/threads/pasting-into-bash-changed-recently.80783/

POLA would suggest restoring the previous behaviour, and offering the new upstream default as an off-by-default option. The relevant ./configure option appears to be --disable-bracketed-paste-default.
Comment 3 Michael Osipov 2021-06-15 10:28:43 UTC
I would support this request. I had to bisect readline source code to understand where this bug -- feature -- comes from.
Comment 4 j.david.lists 2021-07-02 16:41:18 UTC
Created attachment 226173 [details]
Rough patch to make this behavior configurable

I, too, find this new behavior maddening.

Here's a rough swing at a patch adding a port option to make it configurable.

The patch probably needs some cleanup; I'm not very familiar with the complex style guidelines used by the FreeBSD ports tree.  

Perhaps it will serve as a useful starting point for someone who better knows what they're doing.
Comment 5 j.david.lists 2021-07-02 16:44:34 UTC
Also, could someone with privileges to do so (@freebsd.org or the original reporter) please update "Importance" from "Affects Only Me" to "Affects Many People?"
Comment 6 Michael Büker 2021-07-02 19:56:23 UTC
Created attachment 226180 [details]
ports tree patch for bracketed paste as default-off option

Thank you for your work, j.david -- I've taken your patch and brought it (hopefully) in line with the guidelines of the Porter's Handbook.

I tested this and found it to work as expected with `poudriere testport` on 13.0-RELEASE-p3.
Comment 7 j.david.lists 2021-07-03 01:33:49 UTC
That's great, thank you, Michael!

And I fully agree with you about the POLA here, especially since FreeBSD's official implementation of the readline interface is libedit, which does not exhibit this functionality.

It seems very valuable for the two to behave as similarly as possible by default while still allowing people who want the other behavior to obtain it through the option.
Comment 8 j.david.lists 2021-07-12 14:45:36 UTC
What needs to happen now to make further progress on this issue?
Comment 9 Robert Clausecker freebsd_committer freebsd_triage 2021-08-01 16:00:42 UTC
If the maintainer does not respond, eventually (after two weeks) set maintainer-feedback to "-" with comment “maintainer timeout.”
Comment 10 ice 2021-08-01 17:06:24 UTC
maintainer timeout
Comment 11 Po-Chuan Hsieh freebsd_committer freebsd_triage 2021-08-02 16:18:35 UTC
I could add BRACKETPASTE option but it would be on by default. You could disable it if you do not want this feature.
Comment 12 Kurt Jaeger freebsd_committer freebsd_triage 2021-08-02 17:01:10 UTC
(In reply to Po-Chuan Hsieh from comment #11)
While having it default-off would be preferrable, at least there would
be an option 8-}
Comment 13 j.david.lists 2021-08-02 17:04:34 UTC
(In reply to Kurt Jaeger from comment #12)

It really needs to be off by default.

Libedit, the official FreeBSD equivalent of this, does not have the behavior.  Conformity with that is of primary importance.

It is simply not reasonable to expect the user to know/check what shared library a program links against before running it to know what line-pasting behavior to expect.
Comment 14 Michael Osipov 2021-08-02 17:24:31 UTC
(In reply to Po-Chuan Hsieh from comment #11)

I don't think that this option needs a port OPTION. It's just too specific. inputrc in LOCALBASE or $HOME are enough. Most people won't care anyway.
Comment 15 Michael Büker 2021-08-02 19:00:36 UTC
(In reply to Michael Osipov from comment #14)

I urge you to reconsider that opinion, given that bracketed-paste has been the topic of at least 3 FreeBSD Forums threads, and at least 30 postings therein, in little more than three months.

- https://forums.freebsd.org/threads/freebsd-13-annoyances.79815/post-505975
- https://forums.freebsd.org/threads/pasting-into-bash-changed-recently.80783/
- https://forums.freebsd.org/threads/bracketed-paste.81314/#post-522802

This is also being discussed in the wider *nix sphere:

- https://utcc.utoronto.ca/~cks/space/blog/unix/BracketedPasteWhyNot
- https://bugzilla.redhat.com/show_bug.cgi?id=1954366
- https://discuss.getsol.us/d/6524-noticed-bash-recently-started-highlighting-pasted-text-youre-not-going-crazy

I would also like to reiterate that POLA dictates that this fundamental aspect of terminal behaviour should not change without a good reason.
Comment 16 Michael Osipov 2021-08-02 19:24:01 UTC
(In reply to Michael Büker from comment #15)

Yepp, it must be disabled by default.
Comment 17 Fernando Apesteguía freebsd_committer freebsd_triage 2021-08-03 16:56:13 UTC
(In reply to Michael Osipov from comment #16)
Would adding

set enable-bracketed-paste off

to ~/.inputrc work?
Comment 18 j.david.lists 2021-08-03 18:33:24 UTC
(In reply to Fernando Apesteguía from comment #17)

The patch addresses an issue for a confirmed nontrivial number of people and does not close off any paths that are currently available.

This is a compile-time flag provided by the developers of the deadline library for this specific purpose, and OPTIONS is how compile-time flags are supported in ports.

It's not like the readline port is drowning in a confusing number of complicated options already.

And while the choice of "default off" or "default on" might be subject to debate,* given the number of people clearly frustrated by this new, undocumented behavior, including the ability for people to set the option that best fits their use case doesn't seem like it should be as controversial as it appears to be.

What is the specific objection to moving ahead here, and what's needed to address that objection?
Comment 19 ice 2021-08-03 21:56:23 UTC
IMNSHO the "behaviour parity with base libedit" argument should trump anything and everything else, no questions asked. This surely can't be hard to comprehend.

(I don't have an egg in this basket anymore - config management will sort it out for me, regardless of the outcome of this bug.)
Comment 20 Michael Osipov 2021-08-04 07:32:19 UTC
(In reply to Fernando Apesteguía from comment #17)

Yes, or in /usr/local/etc/inputrc.
Comment 21 Fernando Apesteguía freebsd_committer freebsd_triage 2021-08-04 09:05:32 UTC
(In reply to Michael Osipov from comment #20)

While I understand the frustration by many people here and in some of the URLs posted in this PR, I do not see this as a big deal if it can be disabled in .inputrc. But take into account that I do not handle hundreds of servers! I don't have the burden of changing 100 .inputrc files.

So our options are:

1) Leave things as they are: libreadline will behave differently from libedit. Some people will prefer the new behavior (yes, some people find the new behavior safer), some people the old one.

2) Create a BRACKETPASTE ON by default: This will be inconvenient for some people because the behavior will be different from that in libedit. Those people will need to rebuild the port if they want the other behavior. On the other hand, someone that just pkg installs readline will get the upstream behavior. This might be desirable too.

3) Create a BRACKETPASTE OFF by default. libedit and libreadline will behave the same way. Some people will like it, some won't. We do not get upstream behavior by default. People who want that need to rebuild the port.

If the annoying thing here is the new behavior itself, I would rather disable it at runtime in inputrc and have the port built with it. I think we could go with 2). But this is just my personal preference.
Comment 22 Michael Osipov 2021-08-04 09:32:53 UTC
(In reply to Fernando Apesteguía from comment #21)

I don't think that the port OPTION makes any sense. This can also be achieved via /usr/local/etc/inputrc. Where is the difference between maintaining the inputrc or /var/db/ports? I don't see any.
Comment 23 Fernando Apesteguía freebsd_committer freebsd_triage 2021-08-04 10:01:00 UTC
(In reply to Michael Osipov from comment #22)

I agree. Anyway, I trust in sunpoet's criteria :-)
Comment 24 j.david.lists 2021-08-04 17:10:20 UTC
(In reply to Michael Osipov from comment #22)

It sounds like you're saying that inputrc is (at least) as good a solution as the compile-time option for your use case.  So you don't personally benefit from this patch.  Is that accurate?

If so, that seems perfectly reasonable.

In our case, the compile-time option saves us a lot of hassle. It has a much lower configuration management burden than trying to come up with a way to adjust a global inputrc across systems in different administrative domains that may have or not have existing custom content in that file, may or may not have that file at all, and may or may not be using their own config management to manage it.

But here's where I get confused: the feature is literally called "OPTIONS," and it exists because one size doesn't fit all.  So if a specific option doesn't benefit someone, that seems like a reason for them not to care one way or the other, not a reason to oppose it.

Could you (and/or Fernando) clarify what specific harm or defect this patch would introduce that you feel outweighs the benefit it provides to those who do need it and for whom inputrc is either not an option or a substantially less palatable one?
Comment 25 Robert Clausecker freebsd_committer freebsd_triage 2021-08-04 17:23:55 UTC
(In reply to Michael Osipov from comment #22)

The OPTION basically sets a global default.  That's one of the things OPTIONs are used for.  There's clearly demand and adding one is kind of a no brainer.

Whether it is set by default is another question.
Comment 26 Fernando Apesteguía freebsd_committer freebsd_triage 2021-08-04 17:24:52 UTC
(In reply to j.david.lists from comment #24)

Yes, for my case, inputrc is good enough. But I understand other people need a configurable option in the port so they can deploy packages with the option already disabled.

The only thing is that I am not convinced that the default should have BRACKETPASTE disable. I rather stick to the behavior upstream provides and have it enabled.

But if MAINTAINER thinks otherwise, it is OK with me too. I will not get in your way :-)
Comment 27 Michael Osipov 2021-08-05 06:15:20 UTC
(In reply to j.david.lists from comment #24)

The difference between OPTIONS in this port and others is that you still can configure libreadline at runtime while other ports really are compile time cannot be changed afterwards. Given that readline has a million of options people might ask: Hey, I need another OPTION for X.
Not making an OPTION and disable it at compile time is an opinionated view to achieve system consistency.
Comment 28 Michael Büker 2021-08-05 07:43:11 UTC
This discussion is going in circles. What's next? An authoritative decision, a vote, a review on the phabricator …?

To summarize the options again:

1) leave everything as is
--> bracketed-paste is on unless inputrc overrides ($HOME or /usr/local/etc/)
--> ports libreadline and base libedit inconsistent

2) introduce default-on OPTION
--> bracketed-paste is on unless custom-compiled or inputrc overrides
--> ports libreadline and base libedit inconsistent

3) introduce default-off OPTION
--> bracketed-paste is off unless custom-compiled or inputrc overrides
--> ports libreadline and base libedit consistent

4) deploy port with "set enable-bracketed-paste off" in /usr/local/etc/inputrc
--> bracketed-paste is off unless inputrc is changed (or overridden in $HOME)
--> ports libreadline and base libedit consistent

The maintainer has indicated a preference for 2).
Comment 29 Michael Osipov 2021-08-05 12:23:12 UTC
(In reply to Michael Büker from comment #28)

Please consider that option 2) implies for pkg users that this will be on and can only be turned of by a config file.

I am against option 4) personally.
Comment 30 j.david.lists 2021-08-05 16:35:49 UTC
(In reply to Michael Büker from comment #28)
As far as I can tell, the port maintainer has the unilateral ability to make this decision.

However, the port maintainer's one comment after a month of requests for them to review it was that they could
Comment 31 j.david.lists 2021-08-05 16:37:51 UTC
I apologize for the previous comment fragment.  I added it in error when I removed myself from the cc list for this bug.

I wish you all the best of luck with this issue.
Comment 32 Michael Büker 2021-08-06 17:26:26 UTC
Created attachment 226997 [details]
ports tree patch for bracketed paste as default-on option

While we're at it, here's a patch for option 2).
Comment 33 commit-hook freebsd_committer freebsd_triage 2021-08-08 22:11:54 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=a3abb6ed787917d0b8ef9da6837c25e414763efa

commit a3abb6ed787917d0b8ef9da6837c25e414763efa
Author:     Po-Chuan Hsieh <sunpoet@FreeBSD.org>
AuthorDate: 2021-08-08 21:42:06 +0000
Commit:     Po-Chuan Hsieh <sunpoet@FreeBSD.org>
CommitDate: 2021-08-08 21:46:39 +0000

    devel/readline: Add BRACKETEDPASTE option

    PR:             253142

 devel/readline/Makefile | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
Comment 34 Po-Chuan Hsieh freebsd_committer freebsd_triage 2021-08-08 22:33:41 UTC
At the begining, IMHO, this PR could be closed as "Works As Intended". This is upstream behavior/feature and it is tunable via /usr/local/etc/inputrc or ~/.inputrc.

After a second thought, I decided to add this option. It's just another path for people who want to build package w/ bracketed paste disabled.

BTW, I'm not convinced that readline should behave like libedit. It is not a drop-in replacement of libedit. They're different things. Do you expect Safari to work in the same way as Chrome?