bugGNU Octave - Bugs: bug #59483, GUI terminal emits...

 
 

bug #59483: GUI terminal emits "undecodable token:" warning with readline bracketed paste setting

Submitted by:  Lars Kindermann <larskindermann>
Submitted on:  Thu 19 Nov 2020 09:24:31 AM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  6.0.92 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 23 Nov 2020 05:13:58 PM UTC, comment #23: 

The fact that 5.2 is now affected is just another reason why the 6.1 release should not be delayed.  As the bug seems to have been fixed on the stable branch I'm closing the report.

Rik <rik5>
Project Administrator
Sun 22 Nov 2020 11:02:24 PM UTC, comment #22: 

Behaviour is back to "normal".

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

Lars Kindermann <larskindermann>
Fri 20 Nov 2020 12:02:08 AM UTC, comment #21: 

I think we should just remove the warning in the qterminal code.  It's not really helpful, could happen for things other than bracketed paste escape sequences, and we may have no way to disable it if it happens other than to fix a broken termcap entry. Longer term, of course, we need to either take on real maintenance of the existing qterminal code or replace it.  I pushed the following change on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/90a8e6fd85c3

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2020 10:57:26 PM UTC, comment #20: 

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.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Nov 2020 10:55:12 PM UTC, comment #19: 

Looks like cmd-edit.cc in the constructor for gnu_readline would be the place to make a call.  If we want to mimic what is done for blink-matching-paren then we would have to add a function in liboctave/util/oct-rl-edit.[h,cc].

Rik <rik5>
Project Administrator
Thu 19 Nov 2020 10:46:16 PM UTC, comment #18: 

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.

Rik <rik5>
Project Administrator
Thu 19 Nov 2020 10:23:11 PM UTC, comment #17: 

Ok, that fixes the GUI prompt message.

But it will disable bracketed paste in the terminal, too?
Is there a way to individually initialize both modes?

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 10:08:29 PM UTC, comment #16: 

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.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Nov 2020 09:57:55 PM UTC, comment #15: 

I added

set enable-bracketed-paste off

to the file scripts/startup/inputrc in the Octave sources and did "make install". However, nothing changed.

Where is inputrc installed to and in case of multiple versions on my system, in which order are they read at startup?

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 09:21:10 PM UTC, comment #14: 

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.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Nov 2020 09:19:23 PM UTC, comment #13: 

Octave has its own inputrc file that is read when Octave starts.  That is done from the version-rcfile.  So probably the best thing is to add

set enable-bracketed-paste off

to the file scripts/startup/inputrc in the Octave sources.  Does that work?

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2020 08:44:26 PM UTC, comment #12: 

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.

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 08:30:21 PM UTC, comment #11: 

@ Mike: I got your comment and I can fix it in .inputrc. But my point is, when readline 8.1 will finally be rolled out, ALL users of Octave GUI suddenly will have to apply that fix, even on a fresh installed system. So I think, 6.1 should already be prepared for this...

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 08:15:24 PM UTC, comment #10: 

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.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Nov 2020 08:14:56 PM UTC, comment #9: 

Here is the answer from the readline developer:

On 11/19/20 2:42 PM, Lars Kindermann wrote:
> Hi,
>
> Debian testing yesterday updated libreadline8 to 8.1~rc2-2
> Since then the GUI of GNU Octave (all versions) throws the error message
>
> "undecodable token: \001b(hex)[?2004l"
>
> See: https://savannah.gnu.org/bugs/?59483
>
> Any idea what the cause may be?

This is the termination sequence for bracketed paste mode, which is
enabled by default in readline-8.1:

rlprivate.h:#define BRACK_PASTE_INIT    "\033[?2004h"
rlprivate.h:#define BRACK_PASTE_FINI    "\033[?2004l\r"


You can either require the user to disable it, disable it from inside
octave:

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

or set the terminal to "dumb"

rl_terminal_name = "dumb";

in which case it's turned off.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
         ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

8.1 enables bracketed paste mode by default now. This means from the moment when libreadline will be finally upgraded to 8.1, all Octave installations on clean systems suddenly will be affected and have to disable the 'enable-bracketed-paste' manually.

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 08:00:11 PM UTC, comment #8: 

$ 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

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 07:42:53 PM UTC, comment #7: 

In recent versions, --no-line-editing and --gui can't be used together.

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2020 07:38:51 PM UTC, comment #6: 

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.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Nov 2020 07:28:35 PM UTC, comment #5: 

A way of testing for sure whether readline is the problem would be to invoke Octave with the '--no-line-editing' option.  This will disable using readline for the session an anything in .inputrc or in /etc/inputrc will be skipped.

Try

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

Rik <rik5>
Project Administrator
Thu 19 Nov 2020 06:32:37 PM UTC, comment #4: 

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?

John W. Eaton <jwe>
Project Administrator
Thu 19 Nov 2020 04:58:44 PM UTC, comment #3: 

It happens regardless of .inputrc

I just checked /var/log/apt/history.log, the problem started right after libreadline8 was upgraded from version 8.0-4 to 8.1~rc2-2

So it is upstream...

Lars Kindermann <larskindermann>
Thu 19 Nov 2020 04:35:47 PM UTC, comment #2: 

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.

Rik <rik5>
Project Administrator
Thu 19 Nov 2020 10:32:53 AM UTC, comment #1: 

Searching for "undecodable token" leads to bug #56757 and a few others related to readline configuration. Do you have some fancy configaration in your .input_rc that could trigger this?

Pantxo Diribarne <pantxo>
Project Member
Thu 19 Nov 2020 09:24:31 AM UTC, original submission:  

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

Lars Kindermann <larskindermann>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by larskindermann (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-23 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2020-11-19 mtmiller StatusDuplicate => Confirmed
        Open/ClosedClosed => Open
        SummaryGUI prints "undecodable token:" on every prompt => GUI terminal emits "undecodable token:" warning with readline bracketed paste setting
    2020-11-19 mtmiller StatusNeed Info => Duplicate
        Open/ClosedOpen => Closed
        Dependencies- => Depends on bugs #54335
    2020-11-19 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5