bugGNU Octave - Bugs: bug #37401, Multi-line command recall is weird...


bug #37401: Multi-line command recall is weird in GUI editor; non-GUI is OK.

Submitter:  Arun Giridhar <arungiridhar>
Submitted:  Wed 19 Sep 2012 09:12:37 PM UTC
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Sun 08 Mar 2015 04:36:59 PM UTC, comment #12: 

I don't see any issues in the 4.0.0-rc1 release candidate, so I'm just going to close this one as fixed. If there are still problems please correct me and demonstrate the problems, or just open a new bug report.

I tested on both Debian and Windows XP, with command window made narrower and wider, and typing long lines and recalling them seems to work fine for me.

In Windows, a long line is shown as a single long line with continuation markers "<" and ">" at the start and end of the line, but scrolling back and forward allows the cursor to traverse the entire line. Making the command window wider redisplays the input line to show the entire line.

In Linux, long lines wrap to the following line instead, and resizing the command window correctly wraps and unwraps the current text input, nothing is overwritten or lost.

Mike Miller <mtmiller>
Project Administrator
Mon 20 Jan 2014 04:20:01 AM UTC, comment #11: 

Most of the issues that were reported earlier in this bug report seem to have been resolved by the 3.8.0 release. Can someone summarize what the remaining issues are with the terminal and resize events?

Mike Miller <mtmiller>
Project Administrator
Thu 11 Apr 2013 04:11:04 PM UTC, comment #10: 

I think you just need to arrange to call command_editor::reset_screen_size when the window size changes.  That function should get the new terminal size and set the internal readline variables that track terminal size.

I checked in a not-quite-right fix here:


It's not quite right because it only updates the size of the terminal just prior to displaying the prompt.  But in the absense of resize events at startup, at least the terminal size should be correct then, and if there are resize events after that, the terminal size will be correct again after one prompt cycle.  That's better than before, so I checked in the change.

I'm not sure of the best way to hook this function call into QTerminal.  Whatever you do, it needs to be done so that it works for both the Unix and Windows implementations.

John W. Eaton <jwe>
Project Administrator
Thu 11 Apr 2013 02:01:04 PM UTC, comment #9: 

I'm not a big GUI coder, but I think we're in the right place.

I noticed that there seem to be two wraps going on.  One is provided by the Qt window and the second is provided, maybe, by the terminal.

If I shrink the terminal window to something less than 80 characters and then press and hold a key I get the following behavior:

1) The characters up to the window width are entered correctly
2) When the cursor hits the right window edge, it is correctly
moved to the next line and more characters are entered.
3) When the total number of characters reaches 80 the cursor is re-positioned to the start of the line without a linefeed.

All of that is easy to see if you make your terminal window small (say 30 characters).

Conversely, If I make the window very large I never see the Qt window wrap.  Instead I only get the terminal wrap at 80 characters which means the current line is always overwritten.

So, it looks like we do need to do what you suggest and connect the resize notification from Qt to set the Terminal's size.

Rik <rik5>
Project Administrator
Thu 11 Apr 2013 01:49:53 PM UTC, comment #8: 

Crosslinking this issue with bug #37625 which is also about history and visuals being corrupted.

Rik <rik5>
Project Administrator
Thu 11 Apr 2013 03:28:31 AM UTC, comment #7: 

The file Screen.cpp has a lot of FIXMEs in it.  clearImage might be the routine that clears or moves the cursor around.  Seems like the whole thing became a bit unwieldy.  I've placed an fprintf(stderr,"CLR") inside this clearImage routine and there definitely is a lot of activity with that routine when it comes to the up arrow.

Dan Sebald <sebald>
Thu 11 Apr 2013 02:52:13 AM UTC, comment #6: 

If you'd like to see something really odd, adjust the width of the Command Window to something less than 80 characters, say 75.  Type in a really long line of text, say 150 or 200 characters by holding down a key.  Hit return.  Hit the up arrow and notice that the line comes back and adjusts vertical space.  Hit up arrow a few times to recall history.  It seems to function well.

Now, adjust the Command Window so that it is greater than 80 characters, way 90.  You can see the size label pop up when adjusting.  Press the up arrow to recall history.  Whenever there is a long line that goes past a couple lines, the text erases a couple lines.  It will keep doing this until the command line drifts up to the top of the windows and the model becomes empty.  (The "model" in Qt parlance is the part holding the data I think.  The "view" is the object that displays the data model.)

Something with that size between view and emulator doesn't seem correct.

Dan Sebald <sebald>
Thu 11 Apr 2013 02:37:05 AM UTC, comment #5: 

I see that resizeRequest isn't connected to anything.

[qterminal]$ grep -r resizeRequest *
libqterminal/unix/TerminalModel.h:  void resizeRequest(const QSize& size);
libqterminal/unix/TerminalModel.cpp:    emit resizeRequest(size);

It seems that should be connected to something that configures the _emulation console so that moving the Qt window changes the size of the _emulation window.  The emulation is using lines/columns:

  /** Change the size of the emulation's image */
  virtual void setImageSize(int lines, int columns);

but Jacob put some code in the TerminalView

void TerminalView::showResizeNotification()

that computes those values.  So there is at least something partially there to address that issue.

Are you seeing how when the window is narrowed that the text wraps?  (That's a Qt window effect, I'm guessing.)  It's odd though.  The keyboard input that is typed will wrap, but not the text that has already been entered, i.e., up higher in the window.  Those lines of text will extend past the end of the screen as through there is no line wrap.

Anyway, as for the missing linefeed, there is a function "receiveData".

void Emulation::receiveData(const char* text, int length)
        emit stateSet(NOTIFYACTIVITY);


        QString unicodeText = _decoder->toUnicode(text,length);

I wonder about that unicode translation.


But I took that out and the problem still exists.

Dan Sebald <sebald>
Thu 11 Apr 2013 01:09:40 AM UTC, comment #4: 

Actually, I think there is an even easier way to show up the problems in the terminal window with long lines.  If I type more than 70 characters then the cursor jumps to column 1, but it does not advance down a row (linefeed).  Subsequent characters then overwrite the prompt and whatever else is on the line.  This is with today's tip (4/10/13).

I just held down a key and let the keyboard repeat prove this.

Rik <rik5>
Project Administrator
Thu 11 Apr 2013 12:35:46 AM UTC, comment #3: 

I've confirmed this too.  I think the terminal has become a little more stable to say there is a definitely a particular bug here.

I think I see a source of confusion about this too.  Inside the terminal is the end of command line.  But also the window that is holding the terminal has a wrapping effect of its own.  When I had the terminal window shrunk to be fairly narrow, the line would wrap, go a while and then start overwriting the second line.  That just seem too strange to me because it created all kinds of effects when cutting and pasting.

But a couple days ago I think I dragged the terminal window to be really wide and I now see that when typing a really long line I see a carriage return, but not a line feed.


Dan Sebald <sebald>
Thu 11 Apr 2013 12:09:06 AM UTC, comment #2: 

Confirmed.  This is still a problem with a recent tip 16488:d4ce14c19c2c.

Rik <rik5>
Project Administrator
Thu 20 Sep 2012 09:29:15 AM UTC, comment #1: 

Just a few comments, as I'm seeing this as well.

1) Having pager output is what I noticed as a source for this behavior.

2) I also notice that for the GUI it appears the first line of the startup messages gets put into the history buffer.

3) Although this bug is annoying enough to push it to the front of the list, I'd say hold off for a bit in attempting a fix (whomever that might be) until a few more underlying issues are resolved with the GUI startup, the editor windows and command-line window.  I think it might be easier to debug at that point.

Dan Sebald <sebald>
Wed 19 Sep 2012 09:12:37 PM UTC, original submission:  

Data: Ubuntu 12.04 32bit, running on Intel Core i5.

Steps to reproduce:

1. Start "octave --no-gui" and type a long multi-line command such as this one:

clear all; clc; tic; n = 8; arr = textread("/usr/share/dict/words", "%s"); toc, arr = char(arr); whos, toc, arr = arr(arr(:,n)~=' ' & arr(:,n+1)==' ',1:n); whos, toc

You should get some output about the number of words and 8-letter words.

2. Now type "cl" at the prompt and press up arrow. It should recall the long command just typed, and it will be formatted as before. Hitting return will execute it normally.

3. Quit Octave and restart it with the GUI. Type "cl" and press up arrow. I see very weird formatting on screen, where the cursor has gone to the previous line and only the tail end of the command is visible. Hitting return executes the command properly however.

This is reproducible for me with any long multi-line command, so if you have something in your Octave history please try it out.

For further information, searching the history with Ctrl-R works in the non-GUI mode but not in GUI; I suppose that the GNU readline library was consciously suppressed in the GUI?

Arun Giridhar <arungiridhar>
Project Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-08 mtmiller StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2014-01-20 mtmiller StatusConfirmed Need Info
    2013-04-11 rik5 Dependencies- bugs #37625 is dependent
    2013-04-11 rik5 Item GroupInaccurate Result Other
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.9