[konsole] [Bug 196998] Konsole should reflow the text when resizing

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=196998

--- Comment #28 from Egmont Koblinger  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 365893] Clear scrollback and reset leaves the terminal screen completely blank.

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365893

--- Comment #3 from Egmont Koblinger  ---
> I don't quite understand what you mean by "app running inside the terminal".

In this case I'm afraid you lack the very basic knowledge about what happens
when you open a terminal emulator. There are at least two applications that
start and co-operate, one is the terminal emulator itself, and the other one is
the shell running inside (there could easily be more applications nested
running inside). The shell is the command line interpreter which instructs the
terminal emulator to display the prompt, and the terminal emulator obeys this
instruction and does display the prompt.

Then you ask the terminal emulator to clear its contents, and again, it obeys
your instruction, and clears the screen. So everything's fine.

There is no way the terminal emulator could potentially know which parts of the
screen to retain, and there is no way the terminal emulator could notify the
app running inside (e.g. your shell) that it cleared the screen.

Also, there could be other apps running inside, maybe a text editor (e.g. vim),
a file manager (e.g. mc), a non-interactive tool (e.g. gcc), or a whole lot
more. What should the clear action do then?

The only sane way I can see to "fix" this issue would be to remove this menu
entry, I really don't think it's needed. For the time being, you could just
personally not use it.

> This problem did not occur in KDE4. [...] I currently do not use KDE

I don't use KDE either, I'm a developer of another terminal emulator (that does
the same on clear) lurking around in other forums. I have absolutely no clue
what KDE4 did and I won't install that to find it out.

> Leaving the screen with no prompt definitely gives the user the impression 
> that the OS is broken & full of bugs.

In my opinion, complaining about this gives the impression that you don't
understand how the world of terminal emulation works. Unlike browsers, popular
homepages, mobile phone UIs etc. where it's pretty much expected that you
should be able to use them without prior knowledge, terminal emulators are
mostly for power users and developers. I think it's a reasonable expectation
that you first try to understand how and why it behaves, before coming up with
expectations.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 368005] konsole clears all the screen when I execute clear command even if the scrollbar is infinite.

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368005

--- Comment #2 from Egmont Koblinger  ---
See also:
https://gitlab.com/gnachman/iterm2/issues/5058
https://bugzilla.gnome.org/show_bug.cgi?id=771953

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 365893] Clear scrollback and reset leaves the terminal screen completely blank.

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365893

Egmont Koblinger  changed:

   What|Removed |Added

 CC||egm...@gmail.com

--- Comment #1 from Egmont Koblinger  ---
Works as intended.

There's no way the app running inside the terminal could possibly know that the
terminal's contents have been tampered with by some other means, not initiated
by the app (that is, the shell in this case).

Workarounds (such as injecting a Ctrl-L or Enter keypress) are bound to cause
much more severe problems in other situations.

If this really bothers you, you can execute the "clear" command instead, or
manually press Enter or Ctrl-L after clearing the screen.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 368005] konsole clears all the screen when I execute clear command even if the scrollbar is infinite.

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368005

Egmont Koblinger  changed:

   What|Removed |Added

 CC||egm...@gmail.com

--- Comment #1 from Egmont Koblinger  ---
The escape sequence '\e[3J' is intended to (and indeed does) clear the entire
scrollback. The "clear" command issues this sequence (among others).

So I see two questions:

- Why does such an escape sequence exist at all? Is it good to have it, is it
good that konsole supports this? Wouldn't it be better if no escape sequence
was allowed to wipe out the scrollback? Should konsole (and perhaps other
terminal emulators) deliberately refuse to implement this?

- Why does the "clear" command emit this sequence?

As for the first, this is an interesting design question. As for the second,
you're free to change your terminfo database, or come up with an alternate
implementation of "clear" (maybe as simple as a shell alias) that does not wipe
out the scrollback.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 367899] Please consider sanitizing middle-click-pasted text control characters for security reasons

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=367899

Egmont Koblinger  changed:

   What|Removed |Added

 CC||egm...@gmail.com

--- Comment #1 from Egmont Koblinger  ---
gnome-terminal fixed this only about a year ago. Tracking bug (with hopefully
some additional useful information):
https://bugzilla.gnome.org/show_bug.cgi?id=753197

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 196998] Konsole should reflow the text when resizing

[Egmont Koblinger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=196998

--- Comment #26 from Egmont Koblinger  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.