Version: (using KDE 4.2.90) Installed from: Ubuntu Packages When resizing the window, Konsole does not reflow the text. Per example, if you resize your window to have less characters, the lines already printed are going to be cut. It would be better in this condition to reflow the text and to have the characters going on the next line. Even more important is the opposite scenario when the window is getting larger. In this condition, it is really important to have lines that where cutted on two lines revert in one line. The reason for that is that, first of all, if the person is getting is terminal larger, it's probably because a line he didn't want cutted was... If an example is needed, then look at the default MacOSX terminal who just does that.
Konsole does wrap lines but only if the terminal application asks it to. The bash/zsh command lines are wrapped for example and will reflow when the window is resized. Perhaps the mac terminal defaults to wrapping lines and requires the application to turn this off. In the meantime, if you know that you are going to browse the output of a command and may want to resize the output you can pipe it into less which will handle this automatically in any terminal.
Yeah, it works with the command line on bash but does not with the text on stdout which are not handled in the same way at all. I think that Konsole should reflow the text on stdout when resizing. It would be a lot more convenient. And it's possible to work it out since the mac guys did it. Though I would understand that the feature is not added if it means a lot of redesigning in Konsole... Whatever, I created this bug because I didn't found an entry for it on the tracker and that I heard a lot of people saying that the terminal on MacOS was better than Konsole, if only for that. Today was the one that made the trick and had me asking for the feature ^^. It is a nice one, so... Hope it is possible to add that. Thanks a lot in advance for considering this...
> I would understand that the feature is not added > if it means a lot of redesigning in Konsole... I don't think it is technically difficult to do - the risk is breaking terminal applications which depend on the current default behavior. More importantly - is this desired behavior? Should it be on or off by default and should it be configurable? There is another bug report which has a lot of attention asking that long lines should not be wrapped but instead a horizontal scrollbar should be displayed. For reading log information that might be much more convenient.
I don't think oit is possible to break anything by doing that. Let explain myself. I'm talking about reflowing on text on stdout. Those lines are already printed and are not reversible. I'm not talking about trying to tweak lines when printed by ncurse. ncurse does its job and there's no reason to get in its way. As of what should be the default behavior. Since when you resize the window you expect the text to be refloxed, it should obviously be the default behaviour. As of the question "should it be configurable?", I want to answer "yes" since some people might prefer the old behavior even if it's not likely. I personnaly think that an horizontal scrollbar would be more annoying than helping there. And it won't solve the most problematic issue which is when you resize to get your windows bigger to get printed lines fitting on the width of your window and avoid uncessary line breaks (that often makes things impossible to read). Hope I'm clear enough... My english could be better ;).
> Those lines are already printed and are not reversible. That's not quite true. The current visible area of the terminal is effectively a canvas and applications can 'move' to any point on it and 'draw' whatever they like. Konsole isn't able to tell the difference between such an application and a 'dumb' one which is just printing plain or styled text to stdout.
(In reply to comment #5) > Konsole isn't able to tell the difference between such an > application and a 'dumb' one which is just printing plain or styled text to > stdout. In that case, I'm thinking, tell me if I'm wrong... When resizing the window, applications that are using ncurse (or something similar) are probably using a callback to be registered and handle the resize by themselves... So, if there is such a callback, we should obviously not change the lines it has printed. But if there is no, we can assume it is safe to do so? Or am I missing something there?
> Or am I missing something there? There are no callbacks between Konsole and the terminal application. The 'window size' is a property of the pty connection between the terminal app and Konsole. When Konsole changes this a signal will be sent to the terminal app which the application may or may not respond to. This conversation reminds me that I did actually write a 'word wrap' patch for Konsole some while back which allowed word wrap to be enabled/disabled via a checkbox in the UI. This is not quite what the report asks for but it would be a good starting point - http://reviewboard.kde.org/r/296/
Yeah I see. The only way I can still think off is to use the fact that ncurses based softwares are not writing more characters wide than the console is. Then, it's probably safe to assume that if the line is wider than the screen, we can wrap it. Then, to know if we can unwrap or no, I think that it's simply that if we added ourselves a line break on a line, then we can as well remove it later or change its position at window resize. That seems to be a correct way of handling that. A way of implementing it would be to put the lines printed by softwares in a buffer without adding line breaks in it. It's only at printing time that we take the buffer and print it with line breaks at the correct positions. That would mean to use more RAM but would do the trick quite well. Or at least it seems to do the trick there.
rxvt-unicode has this sort of behaviour on by default, I believe; perhaps it would be a good example to look to? From what I've observed it doesn't work on everything (the default behaviour of ls, for example, does not (because of the added formatting from sorting, it seems)), but it does for enough that it would be nice to have. I haven't looked at the code for rxvt, but maybe they spoof SIGWINCH or otherwise use tput or export $COLUMNS for arbitrarily large widths and pass it though an intermediate stage for formatting before display? (Yeah, it's clearly going to be more clever than that by a lot). As for Konsole, why not make it a first-run option like background colour? Radio buttons with: [ ] Unflowed text [ ] rxvt text flowing [ ] Horizontal scroll bar ...and small illustrative images would be a good compromise, no? Cheers, Wyatt
Yeah, that would be a great way to implement this.
It would be good to implement this in conjunction with bug 62380. I also had suggested an implementation method on Brainstorm ( http://forum.kde.org/viewtopic.php?f=83&t=110643 ). Namely, that firstly there is a check item under the View menu of "Enable word wrap" (as per bug 62380). Then this specific feature would be enabled by having an additional "Dynamically rewrap scrollback" check item under the View menu. If "Word Wrap" and "Dynamically rewrap scrollback" are both checked then the width of historical scrollback output dynamically adjusts to correspond to the width of the Konsole window. If "Word Wrap" is disabled and "Dynamically rewrap scrollback" is then toggled from disabled to enabled, then all wrapped lines in the historical scrollback buffer will instead now flow beyond the width of the Konsole window and horizontal scroll bars will appear if necessary. I also understand that other KDE applications like Kate use terminology such as "Static word wrap" and "Dynamic word wrap" (e.g. bug 191028 ), so maybe a good idea to also align the terminology used between KDE applications.
http://finalterm.org has it, too. I’m sure there is no reason to keep old behavior since reflowing simply superseeds it.
Just FYI: I'm currently implementing this feature in VTE (gnome-terminal and friends). I'd be glad if anyone interested in this feature could give it a try with their favorite applications, so that we can all benefit from our shared experiences (e.g. I'd be curious to hear about applications that this feature breaks, if any). See the patch at https://bugzilla.gnome.org/show_bug.cgi?id=336238 Half of the patch is the rewrapping code. I didn't touch the scrollback's internals, what I'm doing is I'm building up a brand new scrollback buffer with the new width and then throw away the old one. This is far from ideal: it uses double memory during its operation, and is also a bit slow as it individually copies all the cells (although <1s wall clock time on an average laptop for an insanely large scrollback buffer of 100'000 lines is okay I think). One day the internals of the scrollback buffer can be re-written so that it's more convenient and faster to rewrap (no copying of cells, just adjusting pointers to lines, or something like this). The only essential pre-requisite I'm building on is that for each terminal row, VTE already keeps the information whether it was terminated with a soft wrap (overflow to next line) or hard wrap (explicit newline). The other, boring but important half of my patch is to figure out the desired offsets (scroll position and such) after the resize. I hope my work gives you new inspiration on implementing this great feature in Konsole, too :)
It's been implemented in Gnome 3.12 and looks very nice :-) See http://blogs.gnome.org/mclasen/2013/12/09/a-terminal-surprise/
*** Bug 328545 has been marked as a duplicate of this bug. ***
Is there any technical reason this is not getting implemented? Or maybe just lack of /dev/hands ?
Speaking of gnome-terminal experience, it's a really time consuming and complex task. You can see that bug yourself for the time span, amount of discussions (e.g. see two separate design docs linked there), number of linked issues that had to be resolved first, size and complexity of the final patch. Tons of tricky cases (CJK, combining chars, TAB characters; maybe even RTL for konsole (not sure about this)), figuring out the desired scrolling offset, cursor position etc. after rewrapping, maintaining the mouse selection etc., there's no clear definition how it should behave, you just think really hard and try until it all seems to make sense and users don't complain. Performance issues: how do you make it as fast as you can, even with giant scrollbacks; what to do if it's very slow (e.g. infinite scrollback already containing millions of lines), what kinds of optimizations or compromises can you make, e.g. can you defer rewrapping, are you okay with the scrollbar position being only approximate then? How do you manage it in memory or in the scrollback's file, etc... I hope konsole developers or an enthusiastic contributor will find time to implement this. It's doable (and I'm happy to help with my g-t experience) but it's definitely not a quick or easy task.
I'm not sure if you're just over-engineering this... It surely looks quite simple in other terminals (terminology, for example). I think you're actually thinking about the entire terminal-concept the wrong way. A terminal shouldn't be anything more than a TextView widget that receives data from the shell and displays it. And I'm pretty sure a TextView can handle text reflow perfectly :)
Text reflow itself is the easiest part, all the chrome around it are the real hard bits. E.g. you make the terminal taller or shorter (you haven't changed the width yet, no need for reflow), should it add/drop lines at the top or at the bottom? It's really not trivial. With bash-4.3 (that doesn't redraw its prompt on resize) type a long command that wraps to the next line and move the cursor back to its first line, then resize the terminal vertically - notice that terminology cuts the 2nd line of the command and misplaces the cursor, whereas g-t and konsole are correct. How much more complicated will it get if you can even change the width? Terminology allows up to 128k lines of scrollback. My favorite test case file contains about half of that. After cat'ing that, gnome-terminal rewraps/resizes almost immediately, you can see a very small delay, like maybe 0.1 seconds. Terminology starts to print "Big problem. Can't allocate backscroll compress buffer" endlessly to its stderr, even if I'm redirecting it to /dev/null it's still spinning my CPU at 100% after about a minute and it's unusable. Let's go 10-fold in g-t, 1.28M lines of scrollback fully filled up; rewraps for me in about a sec. Terminology doesn't draw a vertical scrollbar. I could have significantly further improved g-t's rewrap performance if we hadn't needed a scrollbar, using delayed ondemand rewrapping. It was the scrollbar that made us need to rewrap everything immediately, to know the scrollbar's new position. Terminology wraps CJK incorrectly: it's totally fine with displaying the left half and cropping the right part. I can't read any CJK scripts, but I bet even those who can would have serious troubles reading these half characters. I easily managed to get Terminology into a state when the cursor (shell prompt) was consistently one line below its actual viewport. I don't know how I did it and whether I could reproduce it, but I got there in just a few minutes, whereas I've been stressing g-t's rewrap for about a year without any problems. By the way, let me mention that it's been in g-t for a year and the only bugreport I got was that I forgot to maintain the mouse selection. No reports about any crash, lockup or malfunction, even though it probably has a much larger user base than Terminology. I don't think any TextView widget is prepared to handle content backed up by a file (let alone compressed and encrypted file as gnome-terminal will have very soon), and to handle content of tens of megabytes or even much more. Just a very simple question: how would you do the memory management (without long term memory fragmentation) of a let's say 10,000 or 100,000 line scrollback buffer, continuously appending at the end and purging data from its tail? Of course, life was so much simpler if we were limited to 500 scrollback lines, then it would all be soooooo easy. But alas, terminals are much harder than simple TextView widgets ;)
my naive ad-hoc approach: you start from the last line on screen and dynamically reflow everything above that until the screen is filled, with that last line still being the last line on screen. then you maintain a “reflow buffer” at a comfortable size that holds the reflowed content of as many screens of scrollback above and below where you are as fit into the reflow buffer.
You can't flow the text backwards; but indeed you can walk backwards to find the beginning of a paragraph (an explicit newine) and flow forward from that point. It might become slow with overlong paragraphs though. Yup maybe g-t's design is a bit overengineered and maybe a simpler one could also work. You inspired me to at least file a ticket that lets us remember: https://bugzilla.gnome.org/show_bug.cgi?id=741520 When implementing such a nontrivial feature, other interesting factors come to the game, e.g. the existing design of the terminal, and my close-to-zero knowledge about vte's code then. So I went for the approach that needed probably the smallest amount of changes to the existing bits. Maybe I'd do it differently if I started it today with 1 year of experience with the code, maybe I'd be braver to do bigger changes and go for this approach. So I'm not saying gnome-terminal's way is the best or the only way to solve this problem. :)
*** Bug 362107 has been marked as a duplicate of this bug. ***
*** Bug 358115 has been marked as a duplicate of this bug. ***
What I would like is a checkbox to toggle between reflowing text, and having a horizontal scrollbar. In particular, qDebug messages are often quite long, and usually some part of the line is the most interesting, so I'd rather be able to scroll horizontally to that part. Likewise, output from make: sometimes you want to see all the options to gcc, sometimes you just want one line per file that's being compiled. I'd want to assign it a checkbox and then I'd probably be toggling it back and forth fairly frequently. The Windows command window is a lousy example in general, but it does have horizontal scrolling, and the result that when running make, you get one line per compilation, is quite useful. If urxvt can wrap text in so little code, wrapping can't be that hard. I often use urxvt instead of konsole just for that feature, and for its speed and low memory footprint... but then I miss the wonderful search and highlighting features from konsole, mainly. From what I understand of terminals so far (from trying to understand and work on yat), you need multiple text models. The actual width is mainly important in the mode that vi and ncurses-based programs use (but I forgot which escape code switches "pages" or whatever they are called): such programs don't expect or know how to deal with wrapping, and when you exit, you want the previous text to be restored. So that mode probably shouldn't be mixed with the usual scrollable mode at all: it would even be OK to hide or disable the scrollbars whenever you are running vi or an ncurses program, if that simplifies things. (Or, just save a snapshot of those lines into the main model, whenever you exit from such a program.) But otherwise, you can use a model (or a view, or something between) which does know how to do the wrapping, and can either do it optionally, or give you the whole unwrapped line length. So I think that means the model should be a set of lines, a line is composed of spans of text that have the same attributes, and this wrapping-or-not would be taken care of at a higher layer. You don't wrap or truncate lines in the model itself, unless you are in that single-page mode for ncurses or vi: then it can be a different model which enforces its current size. In that case when the window is resized, there is some escape code which tells the program to re-output everything, right? Whereas in the usual mode which accommodates dynamic wrapping, that refresh code doesn't seem to me to even be necessary.
(assign a hotkey to the checkbox, I meant to say)
I've just found this, you might find useful (iTerm's author explains how it's implemented): https://gitlab.com/gnachman/iterm2/issues/3480 vte docs (or rather a dump of random thoughts :)) is at https://git.gnome.org/browse/vte/tree/doc/rewrap.txt
*** Bug 370231 has been marked as a duplicate of this bug. ***
(In reply to Shawn Rutledge from comment #24) > What I would like is a checkbox to toggle between reflowing text, and having > a horizontal scrollbar. For my basic thoughts on horizontal scrollbar see https://bugzilla.gnome.org/show_bug.cgi?id=769440. In addition: your model/view idea is a nice one and is implementable, but some apps will sure seem to be quite broken or at least behave in ways it's hard to justify. E.g. you press the Up arrow and expect the cursor to go up, whereas actually it goes to the left by 80 columns (because it moved up in the model, but it's flattened to the same row in the view). > If urxvt can wrap text in so little code, wrapping can't be that hard. urxvt only rewraps on resize if you've already reached a screenful of text -- I have absolutely no idea what could have been the rationale behind that. In urxvt if you switch to the alternate screen (e.g. vim, mc), resize and then quit, the contents will not be properly rewrapped. Gnome Terminal (VTE) gets this right. I'm afraid there might easily be other issues with urxvt's rewrapping. I haven't tested it any further than these, I'm just assuming this based on seeing how complex it was to get it right, and seeing the just-mentioned problems with urxvt as well as the ones I've mentioned earlier with terminology. The amount of code and the complexity are not strongly correlated. In VTE I implemented rewrapping with a reasonably small(ish) amount of code, but trying to get all the details right it was one of the most complicated ones I've ever written in my life.
*** Bug 398214 has been marked as a duplicate of this bug. ***
(In reply to Egmont Koblinger from comment #26) > I've just found this, you might find useful (iTerm's author explains how > it's implemented): > https://gitlab.com/gnachman/iterm2/issues/3480 > > vte docs (or rather a dump of random thoughts :)) is at > https://git.gnome.org/browse/vte/tree/doc/rewrap.txt Interesting, the iTerm author seems really excited about this sort of thing. Would be great if we can have some sort of collaboration here. Having this is a real plus point for programmers working with large outputs.
(In reply to Egmont Koblinger from comment #28) > (In reply to Shawn Rutledge from comment #24) > > > What I would like is a checkbox to toggle between reflowing text, and having > > a horizontal scrollbar. > > For my basic thoughts on horizontal scrollbar see > https://bugzilla.gnome.org/show_bug.cgi?id=769440. In addition: your > model/view idea is a nice one and is implementable, but some apps will sure > seem to be quite broken or at least behave in ways it's hard to justify. > E.g. you press the Up arrow and expect the cursor to go up, whereas actually > it goes to the left by 80 columns (because it moved up in the model, but > it's flattened to the same row in the view). > > > If urxvt can wrap text in so little code, wrapping can't be that hard. > > urxvt only rewraps on resize if you've already reached a screenful of text > -- I have absolutely no idea what could have been the rationale behind that. > > In urxvt if you switch to the alternate screen (e.g. vim, mc), resize and > then quit, the contents will not be properly rewrapped. Gnome Terminal (VTE) > gets this right. > > I'm afraid there might easily be other issues with urxvt's rewrapping. I > haven't tested it any further than these, I'm just assuming this based on > seeing how complex it was to get it right, and seeing the just-mentioned > problems with urxvt as well as the ones I've mentioned earlier with > terminology. > > The amount of code and the complexity are not strongly correlated. In VTE I > implemented rewrapping with a reasonably small(ish) amount of code, but > trying to get all the details right it was one of the most complicated ones > I've ever written in my life. I have also experienced uvrxt not wrapping stuff properly with large amounts of text.
I have started to use the awesome Konsole implementation of vertical/horizontal terminal splitting and now I can see how automatic text reflow is a really nice thing to have. For example it is quite common to maximiize/restore terminals and without text reflowing some times I find myself re-executing commands.
*** Bug 418503 has been marked as a duplicate of this bug. ***
I want to add that the concerns in #3 are real and valid. The fact that konsole does _not_ currently reflow is an advantage to me, because zsh doesn't play well with reflow. My point is just that reflow is not _strictly_ better than truncation, and if it's added, I would appreciate the ability to disable it. Here are some references for reflow vs zsh: https://github.com/romkatv/powerlevel10k/blob/master/README.md#horrific-mess-when-resizing-terminal-window https://github.com/romkatv/powerlevel10k/issues/175 https://www.zsh.org/mla/workers//2019/msg00561.html
In my opinion this is a very neccesary feature already present in others terminal applications like GNOME Terminal. And according to some Internet sites, it's also very solicited. In my case I make a strong use of the terminal and with some commands like "docker ps" the output width is quite large and, in short terminal size, the output get messed. Simply resizing the window can solve the problem in GNOME but with KDE I need to resize and execute the command again, which is not very pleasant nor productive.
everybody agrees that this is an important feature to have, but does anyone have time to start implementing it? I tried to implement it twice and I failed, I do appreciate some help here. :)
(In reply to Monkiki from comment #36) [...] > In my case I make a strong use of the terminal and with some commands like > "docker ps" the output width is quite large and, in short terminal size, the > output get messed. Simply resizing the window can solve the problem in GNOME > but with KDE I need to resize and execute the command again, which is not > very pleasant nor productive. I'd pipe the output to less or any other pager...
(In reply to Ahmad Samir from comment #38) > (In reply to Monkiki from comment #36) > [...] > > In my case I make a strong use of the terminal and with some commands like > > "docker ps" the output width is quite large and, in short terminal size, the > > output get messed. Simply resizing the window can solve the problem in GNOME > > but with KDE I need to resize and execute the command again, which is not > > very pleasant nor productive. > > I'd pipe the output to less or any other pager... I've tried with "docker ps | less -S" and may be a temporal workaround, but piping all commands output to less is not very pleasant.
I’d like to collaborate on this issue with you. While I’m experienced in C++, I had no time to work on neither KDE nor Qt. If you prefer to collaborate with a Qt & KDE noob, I’d happily do my best. Regards, Hakan > On 10 Jun 2020, at 11:04, bugzilla_noreply@kde.org wrote: > > https://bugs.kde.org/show_bug.cgi?id=196998 > > tcanabrava@kde.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |tcanabrava@kde.org > > --- Comment #37 from tcanabrava@kde.org --- > everybody agrees that this is an important feature to have, but does anyone > have time to start implementing it? I tried to implement it twice and I failed, > I do appreciate some help here. :) > > -- > You are receiving this mail because: > You are on the CC list for the bug.
*** Bug 424028 has been marked as a duplicate of this bug. ***
I want to develop this feature, and try modify this control: qtermwidget, which is a child fork of Konsole(https://github.com/lxqt/qtermwidget)
I find it difficult to use another component inside konsole, even though it is a fork, because in the current version, in addition to everything being very different from the fork in KDE4, there is also the issue of the display terminal is an extremely complex component in the current Konsole. What could be done and what we are already doing is decoupling the TerminalDisplay from the konsole, but such decoupling is very complex and time consuming, there is a lot to be done, of course you can get ideas from qtermwidget, but using it I think it is impossible .
This has been implemented by Carlos Alves with the commits in https://invent.kde.org/utilities/konsole/-/merge_requests/321, to be released in Konsole 21.04! Happy new year everyone. :)
Bloody awesome!
Great! I can't wait to get it running in my computer :P
The new re-wrapping feature is awesome! I was delighted when it showed up on Arch a few weeks ago. Thanks Carlos for getting this done.
Created attachment 167686 [details] attachment-1085019-0.html this already happens On Sun, 24 Mar 2024 at 05:34 Bug Janitor Service <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=196998 > > Bug Janitor Service <bug-janitor@kde.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Priority|NOR |HI > > -- > You are receiving this mail because: > You are the assignee for the bug.