Just in case someone looks here, I pushed the following changesets so that the GUI terminal now handles bracketed paste mode and to improve handling of multi-line pasted input:

http://hg.savannah.gnu.org/hgweb/octave/rev/3180f830d396
http://hg.savannah.gnu.org/hgweb/octave/rev/036079c9ee12
http://hg.savannah.gnu.org/hgweb/octave/rev/cabb840fc3f6

Behaviour is back to "normal".

But Octave 5.2, the current version in the Debian testing repository, is still affected by the new libreadline...

IMHO the simplest solution would be to disable bracketed paste in Octave's standard inputrc file. It will annoy terminal users who want to use bracketed paste mode, but it won't be a regression from older versions because bracketed paste had already been disabled by default, and users needed to enable it explicitly in ~/.inputrc. That still works, the user's own ~/.inputrc will override whatever setting is made in Octave's inputrc. I don't see any large downsides.

Any automatic way to selectively enable or disable this setting depending on whether the GUI is active is going to be complex and invasive, either by loading multiple inputrc files or by doing it entirely in new code in liboctave and liboctinterp.

One might be able to have two inputrc for Octave available in the share/ directory.  On entering the GUI one would use

readline_read_init_file (GUI_INPUTRC)

to load the file which turns enable-bracketed-paste.

BUT, that sounds pretty complicated.

I would probably just find a place to call

rl_variable_bind ("enable-bracketed-paste", "off");

when it had been determined that the GUI was started.

That specific file is not overwritten by 'make install' if the target already exists. You'll want to manually delete the file under «PREFIX»/share/octave/«VERSION»/m/startup/inputrc, then try 'make install' again.

Ok, reopening assuming this bug is about simply trying to suppress the annoying warning message, while bug #54335 remains about actually implementing bracketed paste mode in the GUI terminal widget.

I assume you would want to do something similar to the 'blink-matching-paren' readline setting, which is similarly enabled by default, but disabled under certain conditions.

Or maybe just add it to the config file globally, which would annoy terminal users that do want to use bracketed paste, but they can again enable it in their own ~/.inputrc.

Chet suggested to disable it from inside octave:

rl_variable_bind ("enable-bracketed-paste", "off");

Can you point me to a location in the sources where to include this? So also the old bug reports could be closed.

Hmm, maybe you missed my comment. This is a known incompatibility with the readline setting 'enable-bracketed-paste', has been around for a long time. It appears that the latest versions of readline may enable this setting by default now.

More info and history at bug #54335.

$ octave --norc --no-line-editing --gui

error: --gui and --no-line-editing are mutually exclusive options

The commandline version is not affected.

Removing /etc/inputrc did not change anything.

The problem started with readline 8.1-RC2 and there seems to be ongoing development, RC3 was released just yesterday...

As also Octave 5.2 suffers from this, a fix probably has to be provided upstream in libreadline. I reported the problem to the readline guys at
https://tiswww.case.edu/php/chet/readline/rltop.html#Bugs

This is a duplicate of bug #54335, known compatibility issue for a couple years now.

I regularly edit my ~/.inputrc to disable the 'enable-bracketed-paste' setting whenever I need to use the GUI.

Some systems load /etc/inputrc or similar system-wide config files, so maybe that is the problem.

The message itself comes from the terminal emulator in Octave:

http://hg.savannah.gnu.org/hgweb/octave/file/f39e75f35e48/libgui/qterminal/libqterminal/unix/Vt102Emulation.cpp#l1264

I suppose we could silence that warning?

Just to clarify, the file name for Readline is ".inputrc" without an underscore.  Easiest way to test is to move it to a new name temporarily, such as .inputrc.orig, and then start Octave and see if the problem has gone away.

Starting any version of octave with

octave --gui
or
octave --norc --gui

prints

undecodable token: \001b(hex)[?2004l

at every prompt

Built on latest Debian testing. I suspect a problem with updated qt libs version 5.15.1-x