Bug#1068492: gnome-terminal: $TERM values not documented
Hello, > I checked the value of $TERM and realized I had no idea what would BE a > correct value gnome-terminal sets $TERM to xterm-256color by default. This is the value the software's developers think is best suited. There should be no reason for you to tamper with it. > tmux requires $TERM to be set correctly _Inside_ tmux you'll need a different value for $TERM. But this has hardly anything (if at all) to do with gnome-terminal. You need to consult tmux's documentation for the details. (But I'm fairly certain that tmux also sets the correct value by default, the best you can do is probably again not to touch it. What is the _actual_ problem you're having that does not work out of the box for you and you suspect requires fiddling with $TERM?) > To be honest, that outcome is pretty much as I expected. Nobody ever > documents anything. But what I had HOPED to find was full reference > documentation for gnome-terminal. Rants like this, unfortunately, won't take you anywhere. Like many software projects out there, gnome-terminal is also developed by a few volunteers in their scarce free time. These developers writing excessive documentation (including things like "hey this is set up for you correctly by default, please don't touch it) would take away a significant amount of time from actually making the software function better, which a lot more people are interested in. (Let alone the fact that writing good user-facing documentation requires quite different skills than writing good quality software, you can't just 1:1 trade one for the other.) I'm not saying that it's good that there's no such documentation, nor that your report is invalid. It is indeed a valid issue. I'm just saying that given the scarce resources, and given the skills of the volunteers this project has, it's probably the best compromise the project could make, and therefore it's unlikely to be addressed in the foreseeable future. That being said, high quality contributions (e.g. a "full reference documentation" from a new volunteer technical writer) would surely be highly welcome! e.
Bug#1068407: xfce4-terminal: processes sleep after a while when switching to a different workspace
See https://bugs.debian.org/1068339 . e.
Bug#1068339: gnome-terminal: Regression - long running process will eventually block when terminal is not visible
On Wed, 03 Apr 2024 16:58:35 +0200 Detlev Zundel wrote: > With the latest gnome-terminal, this long-running process gets stopped when > the > terminal is not visible. > > ii libvte-2.91-0 0.75.91-2 This bug sounds the same as upstream report https://gitlab.gnome.org/GNOME/vte/-/issues/2742 which is fixed in libvte 0.75.92. e.
Bug#1067679: libvte-2.91-0: backspace character (code 8) output at the end of a line goes 2 columns backward
Hi, For me, xterm behaves exactly like vte, it prints "ac". Could you please share your xterm version, configuration, and anything printed to the terminal prior to this test that might be relevant? Unfortunately, it seems like this is the expected behavior. Printing a letter to the last column shouldn't advance the cursor, it should only set an "about to wrap" flag. The cursor, as seen in xterm, remains in the last visible column (although vte decides to hide the cursor instead). Backspace, unfortunately, does not take this "about to wrap" flag into account. Most of the terminals that behave like you wish to, i.e. print "abc", suffer from bug https://bugzilla.gnome.org/show_bug.cgi?id=731155, the test ncurses app there incorrectly prints "50" instead of the expected "50%". See also https://gitlab.gnome.org/GNOME/vte/-/issues/62. e.
Bug#1063941: libvte-2.91-common: /etc/profile.d/vte-2.91.sh dereferences undefined PS0
Thanks for the report! I've applied the fix upstream, it'll be in the next version. (The script _is_ upstream, in src/vte.sh.in). e.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hi, > It's a bit weird, I can *no* longer reproduce it. VTE's emulation behavior didn't change recently. Bash/Readline could have changed, I don't know (might be interesting to check their Ubuntu packages' changelogs). Or you're executing somewhat different steps. If the printed prompt is exactly the same (including all the bells and whistles that it prints, like the username, hostname, working directory, previous command's exit value, background job stuff), and the terminal width is exactly the same (is it?), and you're pressing the same keys to invoke the same previous commands or editing the current command in the exact same way, then you should see the exact same behavior. Any difference in any of these could make the bug appear or vanish. Also make sure that the previous command's output ended with a newline, that is, the prompt begins in the first column. Otherwise it's common to see misbehavior while editing. > @Samuel, could you please also try whether you can still reproduce it? > If not, I'd say we might close the issue. By now we are sure that we're talking about two separate issues. The line editing misbehavior is surely independent from Samuel's patch. You casually mentioned that you saw a crash, that one is probably caused by that patch, but there's no stack trace here, and we already have two other bugreports that focus on that crash and contain way more information. > That's interesting... why do you think so? The command substitution > should also be bash, and I'd have thus expected \[ and \] inside it > have therefore the same representation as outside and should thus be > identical? Vague memories from things I saw multiple times, maybe in bash's doc, maybe on forums, I can't recall. I might be wrong. Actually, I might mistake it with the prompt string you pass to readline if you're programming against that library. In that case your prompt looks good to me. Sorry, it's too late here and I'm too tired to look it up or investigate right now. cheers, e.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hi Chris, > Interestingly, I've just been able to reproduce it even with 0.73.99-1: This makes sense. I was wondering how a patch that supposedly only touches a11y (how the contents are read out loud) could have an effect on the actual emulation behavior. Can you try under xterm or other non-VTE-based terminals? I suspect you'll see the same behavior there. It could be a bash issue, or a misconfigured prompt. In fact, I _think_ the culprit is that inside command substitution stuff, a.k.a.. $(...), nonprintable characters need to be enclosed within the raw bytes 0x01 and 0x02, rather than the two-character sequences \[ and \]. Not entirely sure, though. If you can't locate the problem, and if it's specific to VTE, then you should record the traffic using `script` and it should be manually, step-by-step verified what the terminal does for that, e.g. compared against xterm to see where it goes different. But I'm almost entirely certain that it'll be a bash issue rather than a VTE one. Nevertheless, the crash you encountered might be the same caused by the currently debated a11y patch. e.
Bug#1052172: libvte-2.91-0: swallowed characters on libreadline editing
I sent the previous comment to the wrong bug, apologies!
Bug#1052172: libvte-2.91-0: swallowed characters on libreadline editing
Hi Chris, > Interestingly, I've just been able to reproduce it even with 0.73.99-1: This makes sense. I was wondering how a patch that supposedly only touches a11y (how the contents are read out loud) could have an effect on the actual emulation behavior. Can you try under xterm or other non-VTE-based terminals? I suspect you'll see the same behavior there. It could be a bash issue, or a misconfigured prompt. In fact, I _think_ the culprit is that inside command substitution stuff, a.k.a.. $(...), nonprintable characters need to be enclosed within the raw bytes 0x01 and 0x02, rather than the two-character sequences \[ and \]. Not entirely sure, though. If you can't locate the problem, and if it's specific to VTE, then you should record the traffic using `script` and it should be manually, step-by-step verified what the terminal does for that, e.g. compared against xterm to see where it goes different. But I'm almost entirely certain that it'll be a bash issue rather than a VTE one. Nevertheless, the crash you encountered might be the same caused by the currently debated a11y patch. e.
Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing
Hi, It's apparently the same as Debian bug #1052172, caused by Debian backporting an untested patch that just made it to upstream's development branch and apparently hasn't received proper testing. Upstream discussion begins at https://gitlab.gnome.org/GNOME/vte/-/issues/88#note_1849187 . Jeremy, I recommend you to revert that patch and hold it off until it gets fixed and receives a fair amount of testing. cheers, e.
Bug#1052172: gnome-terminal: crash during scroll-up
I've asked about it upstream at https://gitlab.gnome.org/GNOME/vte/-/issues/88#note_1849187 .
Bug#1052172: gnome-terminal: crash during scroll-up
Hi all, I can't recall seeing a similar track trace before. This makes me suspect that the culprit could perhaps be this change: vte2.91 (0.74.0-1) unstable; urgency=medium * Add Samuel Thibault's a11y patch to add missing text changes on scrolling with modifications Note: It's part of vte's master (post 0-74), but not of its 0-74 branch. cheers, e.
Bug#1040049: gnome-terminal: assert hit on mouseover, all open terminal windows are lost
Hi, FYI: upstream issue https://gitlab.gnome.org/GNOME/vte/-/issues/2577 is related, but did not fix this very problem. The current problem is tracked upstream at https://gitlab.gnome.org/GNOME/vte/-/issues/2636. e.
Bug#1024603: gnome-terminal: dose not show combining characters right
Hi, As you've also noted, gnome-terminal is not the only app misbehaving here. See also some of the followup comments (not the original report) in https://gitlab.gnome.org/GNOME/vte/-/issues/2624 , same story. It's a problem with some of the fonts, or some font rendering component of the system. The bug should be triaged accordingly, it's not gnome-terminal or libvte that needs fixing. Unfortunately I cannot help any further (I'm not a Debian developer, just a random commenter.) cheers, egmont
Bug#1031865: gnome-terminal: all themes not applying, including 'custom' and 'use colors from system theme'
Hi, In VTE, colors defined via OSC 4 / 10 / 11 take precedence over the ones set in the preferences dialog. Please double check that you don't emit these OSC codes, or reset them via their corresponding OSC 104 / 110 / 111. Does this fix your problem? cheers, egmont
Bug#978986: invisible cursor when on column 1 after wrapping from final column
Hi, In this scenario that you describe, when running `cat`, the cursor is _not_ in column 1. xterm (and apparently konsole too) think of it as the cursor being in the last column, with a special "about to wrap" (can't recall the exact term, sorry) property set. VTE seems to more think about it as the cursor being one more column further to the right, in a column that's outside of the viewable area. This is important for the correct behavior of apps that when you reach the last cell of the bottom row, the terminal does not yet scroll. If the cursor would move to column 1, it would just as well need to move to the row just below the viewport, and again it would be invisible. You can also confirm that the cursor haven't yet moved to the next row by pressing backspace (which results in an utterly broken experience, sigh), noting that reverse wraparound (e.g. backspace across linebreaks) is disabled by default; or sending other escape sequences to move the cursor left or move it to a certain column within its current row. There's just no good solution for this problem, and indeed, VTE chose a slightly different graphical representation than xterm, one that's not necessarily better or worse. > This does not happen when doing the same kind of wrapping on the bash > prompt, but I imagine bash might be doing its own cursor positioning, > and so avoid the bug. You are absolutely correct here. Also, note that if you're typing the command in the terminal's bottom row, it scrolls the contents upwards as soon as you type a character into the last column. This way it can show the cursor in the new empty last line, column 1. Bash is free to do it by using its own cursor positioning. The default behavior of the terminal mustn't scroll yet. cheers, egmont
Bug#1012046: gnome-terminal-server writes on disk data when a program output data on term
Hi, You don't need to worry about leaking confidential data. VTE stores the scrollback data in encrypted files, and erases the encryption key from memory as soon as the given terminal tab is closed. That is, if support for encryption is compiled in (it is in Debian), which you can double check by looking for "+GNUTLS" in gnome-terminal's About dialog, or in the output of gnome-terminal --version. Should you be interested in juicy technical details, see: https://bugzilla.gnome.org/show_bug.cgi?id=664611 https://bugzilla.gnome.org/show_bug.cgi?id=738601 and the comments at the top of vtestream-file.h, a file which you have already found and looked at. > It uses deleted files in /tmp instead of no files or files in RAM in /run. > [...] For me everything should be in RAM as xterm does. VTE supports infinite scrollback, due to popular demand. Consuming arbitrarily large amount of RAM, potentially even more than the physical amount you have, plays very badly with the kernel's swapping and OOM killer, it's basically unviable as opposed to storing it on disk which works fine. That's the reason (in a nutshell) behind this solution. cheers, egmont
Bug#958502: gnome-terminal: Parent environment variables not not passed to new tabs
Hi, Thanks, I've created this upstream report: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 egmont
Bug#954652: Opening new tab or window from terminal opened with -x opens the same application again
Hi, Thanks for this report! Upstream gnome-terminal 3.36.1 fixes this issue. Now you only need to wait for Debian to ship this version, which hopefully won't take long. e. On Sun, Mar 22, 2020 at 10:44 PM Egmont Koblinger wrote: > > Upstream: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/236
Bug#954652: Opening new tab or window from terminal opened with -x opens the same application again
Upstream: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/236
Bug#941479: text in a new split panel doesn't fill all the vertical space
Hi, Is this behavior fully reproducible for you? (I cannot reproduce it.) Could you please try a few things for me? - What does "stty size" report in the faulty pane? (I'm wondering if it matches the screen size shown in the red bar, or if it's the default 80x24, or perhaps something else.) - What does "echo $LINES $COLUMNS" say? - Does slightly resizing the window, or slightly dragging the separator between the two terminals fix the issue? - Does this command (clearing the scroll region) fix the issue: printf '\e[r' - How does a fullscreen application (e.g. "mc") look like in that panel? - If you start selecting with the mouse, can you select row-by-row over the large unused area? - Could you test with VTE master? I particularly suspect that https://gitlab.gnome.org/GNOME/vte/commit/07aad3e0d5 (a partial fix for https://gitlab.gnome.org/GNOME/vte/issues/188) could be relevant, although it's not clear to me how an intermittent problem with the initial size could get permanently stuck. - Do you have anything special in your shell startup, e.g. automatically launching screen/tmux/byobu, or some weird 3rd party hacks? If so, can you try with the default shell configs? thanks, egmont
Bug#939929: terminator: crash when trying to start
Hi, Could you please share your terminator config file (/home/benoit/.config/terminator/config)? If you move that file away, does terminator 1.91-4 start up? thanks, e.
Bug#940233: sakura: Solarized dark palette no longer different than Solarized light
Hi, Sorry, I mixed it up. I meant to say: The old Light palette, where indices 0 and 8 were *bright*, 7 and 15 were *dark*, and the rest of the gray entries were also reversed, was incorrect [...] e.
Bug#940233: sakura: Solarized dark palette no longer different than Solarized light
Hi, When it comes to Solarized, there are 18 color slots of interest: - the default background and foreground, - and the 16 palette colors. The Solarized homepage clearly defines the 16 palette colors, including their mapping to the 0-15 indices. It does _not_ define two different mappings, it does _not_ define a Dark and a Light color palette. (It defines two different recommended ways of picking colors from that one palette.) In this regard, as per the linked upstream bug, the new behavior is the correct. The old Light palette, where indices 0 and 8 were dark, 7 and 15 were bright, and the rest of the gray entries were also reversed, was incorrect, something nowhere defined on the Solarized homepage. (I downgraded to now 3.5 to test it. It comes directly from Sakura, not some underlying library.) The default background and foreground colors aren't defined by the standard, since Solarized defines 16 colors only (and their mapping to the 16 numbered color slots) and doesn't know anything about the concept of "default fg and bg color" in terminals. Most terminal emulators offer two of the 16 Solarized colors for these purposes, as it's implicitly suggested by Solarized's homepage, and this is where the Dark and Light variants differ. So the question, and accordingly the bug is: Does Sakura's Options -> More -> Set palette menu intend to set the default background and foreground colors? - If yes then it's a bug that it doesn't do so. - If no then it's really unfortunate (read: bug) that it offer two equivalent schemes named "Solarized dark" and "Solarized light" rather than just simply one called "Solarized". cheers, e.
Bug#941425: Doesn't start up due to missing image
Package: termonad Version: 0.2.1.0-2 As I attempt to start up termonad, it prints this error message and quits: termonad: Failed to open file “/usr/share/termonad/img/termonad-lambda.png”: No such file or directory (4) Placing any picture there makes it start up. A picture of this name is available in its git repo. I haven't tampered with this software, haven't tried to create any config file or anything like that. The missing file is not shipped by any Debian package. [On a side note: Unless I'm really missing something, it looks like it's been unusably broken for 9 months and not a single bugreport arrived. Could this mean that the package has zero users, apart from the packager person (for whom it might work due to a manually installed file)? If so, shouldn't it be dropped from the distro?] cheers, egmont
Bug#941283: libvte: terminal crashes after a VTE error
Hello, This bug has already been reported upstream at https://gitlab.gnome.org/GNOME/vte/issues/176 and fixed by VTE's developers. The fix will be released in VTE 0.58.1. cheers, egmont
Bug#940857: Zoom Percentage Display Stays at 100%
Hi, This has already been brought to upstream developers' attention, there's been some discussion about it at: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/140 cheers, e.
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
I don't intent do revive that discussion where we disagreed. We probably still disagree on those things the exact same way, and still nothing changed on VTE's side. As for less's mouse support, you might want to be aware of https://github.com/gwsw/less/issues/24 (tl;dr: it's broken). On Wed, Sep 18, 2019 at 10:41 AM Vincent Lefevre wrote: > > On 2019-09-18 10:29:12 +0200, Egmont Koblinger wrote: > > Based on these, users can pick their favorite mode of operation. > > But there's still no way to disable the general mouse behavior, > e.g. when using GNU Screen. > > -- > Vincent Lefèvre - Web: <https://www.vinc17.net/> > 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
Hi! > FYI, a version of "less" with mouse support is now in Debian/unstable. Thanks for the update! Unfortunately, using this option results either in a much slower scroll, or if "--wheel-lines=n" is specified then a more rough scrolling experience than the synthesized up/down keypresses generated from a touchpad. This is due to the limitation of mouse protocol, see the first bullet point at https://bugzilla.gnome.org/show_bug.cgi?id=755183. Terminal developers should introduce an extension to overcome this limitation, which then "less" could also implement. On the other hand, the new "--mouse" option of "less" certainly has advantages too, e.g. only jumping back by one entry in the search field, even when "--wheel-lines=n" is specified; this, as discussed in this bug, can't be automatically "fixed" when the terminal emulator synthesizes keypresses from a mouse wheel. Based on these, users can pick their favorite mode of operation. e.
Bug#940239: Wrapper script uses old project name
Package: tilix Version: 1.8.9-1+b1 This package was renamed a while ago from Terminix to Tilix. Yet, the wrapper script /usr/bin/tilix.wrapper, added by Debian, still prints the old name in error messages. It should be updated to say Tilix, not Terminix. e.
Bug#848134: xfce4-terminal: Weird buffering problem
A very similar (perhaps the same, perhaps not) problem has been reported at https://unix.stackexchange.com/q/509773 . As per the answer given there, it might be a video card driver problem recently fixed at https://bugs.freedesktop.org/show_bug.cgi?id=110214 .
Bug#848134: xfce4-terminal: Weird buffering problem
VTE (libvte-2.91-0) recently received lots of changes to its drawing component. There were bugfixes around rendering, especially in non-compositing mode [1] and many simplifications and cleanups [2] released in version 0.56; followed by even more simplifications and cleanups [3] for version 0.58. I'm pretty certain that 0.58, if not 0.56 already, fixes the issue. [1] https://gitlab.gnome.org/GNOME/vte/issues/4 [2] https://gitlab.gnome.org/GNOME/vte/issues/26 [3] https://gitlab.gnome.org/GNOME/vte/issues/56 e.
Bug#822231: xfce4-terminal: Fira Code font not displayed correctly
This was fixed in libvte-2.91-0 version 0.52 (combined with xfce4-terminal 0.8.x). (Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=793391.) e.
Bug#824534: mate-terminal: does not display bidirectional text correctly
Hi, > Wow, nice draft / document. Nice work! Thanks a lot! > So, we just have to make sure, mate-terminal gets rebuilt when that > latest libvte enters unstable? No rebuild is necessary. Just a fresh libvte. > If that is so, can I ask you to monitor > this and once mate-terminal works nicely regarding BiDi, you close > this bug? Sorry, no. I just found this bugreport and thought I'd share some info with you. I'm neither a Debian nor a mate-terminal user and I normally don't follow the package upgrades in Debian. cheers, egmont
Bug#824534: mate-terminal: does not display bidirectional text correctly
Hi, > do you know if simply upgrading to this libvte version fixes > the issue of this bug report? Yes, all you need is a newer libvte. It's already in Debian's experimental repo. > (What is BiDi support in a terminal at all, anyway? What locale uses > it? Or for what context is it used? How can one enable it?) It's enabled by default, can be disabled using escape sequences. (Can also be disabled using an API, but that's meant to be a last resort kill switch, and needs small work in mate-terminal if you want to do it. It's not important to have it.) The locale does not matter. BiDi was implemented based on the proposal at https://terminal-wg.pages.freedesktop.org/bidi/ , see there for further details. e.
Bug#824534: mate-terminal: does not display bidirectional text correctly
BiDi support is available beginning with libvte-2.91-0 version 0.57.3. e.
Bug#931744: gnome-terminal: "Show bold text in bright colours" has no effect
Hi, The changes in color handling were intentional. There are two things two talk about: Bold variant of the default color. This used to be an autogenerated brighter color using a hardwired formula (which in case of Solarized was accidentally almost the same as another color of this palette), but now it's the same color by default (with a bolder font weight). You can still pick any color under "Bold color" in the Preferences. Bold variant of the first eight palette colors. The config option "Show bold text in bright colors" corresponds to these, as it's suggested by this option being indented, under the "Palette" section. I agree it's not absolutely clear that it doesn't correspond to the default color. I'm not sure how to phrase it better, though. See these for more context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910078 https://bugzilla.gnome.org/show_bug.cgi?id=762247 https://bugzilla.gnome.org/show_bug.cgi?id=728600 https://bugzilla.gnome.org/show_bug.cgi?id=793152 https://askubuntu.com/q/1156880/398785 cheers, egmont
Bug#909469: Bug #909469: lilyterm: crash when closing 2nd window
Hi, > I could not find an upstream bug or commit that looks related. Funnily, one was opened just a few hours after you made this comment. It's at https://github.com/Tetralet/LilyTerm/issues/134. cheers, egmont
Bug#886165: lxterminal: gtk warning on vertical resize
Hi, This was fixed in mainstream VTE (libvte-2.91-0) version 0.52.0. See https://bugzilla.gnome.org/show_bug.cgi?id=793435 for details. cheers, egmont
Bug#930315: Please drop obsolete uniutils package
Package: uniutils Version: 2.27-2+b1 Please remove this obsolete package from Debian. Upstream hasn't seen a new release for more than 10 years. The package provides useful character information based on version 5.1 of the Unicode standard. Unicode is continuously evolving, currently at version 12.1. Having such an (otherwise great) collection of tools that is so obsolete is not only pointless, but is also harmful as users might come across this outdated package first and waste time with it. The binary hardwires the character database, rather than taking from some external source which then could be updated separately. So I don't see a reasaonable way of fixing this issue within uniutils. The package "unicode" is a great replacement, using a fresh Unicode version. thanks, egmont
Bug#896101: Please switch Suggests from libvte9 to libvte-2.91-0
Hi, Friendly ping – dear developers, could you please address this trivial issue? This is the only thing that prevents Ubuntu from removing the obsolete libvte9 package, see https://bugs.launchpad.net/ubuntu/+source/vte/+bug/1829377 . (By the way, Debian should also aim to remove libvte9, but that's for another bug...) cheers, egmont
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
Hi, > Perhaps it should have generated scroll-backward (kR) and > scroll-forward (kF) keys, and provided a terminfo that defines > them. That way, this wouldn't mix up with the and > keys. There would be no point in that either: if an application cares enough to handle kR and kF, it could just as easily handle mouse scroll events directly. Again, the point of this feature, which you disagree with, was to make it _automatic_ (even despite its drawbacks in some contexts) for apps that don't care enough. (And, on a totally irrelevant note, which has been discussed many times and I won't start over, gnome-terminal doesn't ship its separate terminfo but piggybacks xterm's.) While the feature isn't perfect (it cannot be due to its nature), it's arguably still more useful for many people than harmful. I've seen many more people complaining about its lack whenever it didn't work for them, than complaining about its problems and imperfectness. If you find it harmful, you can switch it off. cheers, egmont
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
Hi, > Yes, but my point is that the default should not be broken. One could argue that the wheels working in "less" (or any other similar app) is the expected behavior, and not working at all is the broken one... I think we just have to agree that we disagree. cheers, egmont
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
Hi, > But this one is really special as specific to GNOME Terminal. No, not at all. At least I get this behavior in xterm and konsole, too. > Well, for applications that do not have any support, it is easy > to write a wrapper script that does the limited work. Thus the > user could choose whether to enable the wheel or not. Just as much as you can disable now, by writing wrapper scripts. Or just a one-off disabling in your shell startup files. It's unclear to me who would go through apps and decide which ones to turn on this feature, and how it would actually be implemented, e.g. would some distributions ship wrappers by default to hundreds of apps where scrolling is potentially useful? Because if it's up for individual users to come up with wrapper scripts for themselves to enable, it would probably be used by so few people that it would not be worth it to have this feature at all. > it has recently been implemented in "less" (not yet released) Which means "less" will enable mouse reporting, that is, you will no longer get synthesized keypresses for scrolling. > And because it has too much drawback in general and its could be > best used with wrapper scripts (i.e. only when it can make sense), > it should be disabled by default. That's your opinion on a design dilemma with IMO no clear single answer. > No, it came from GNOME Terminal. In xterm's log: I recalled it incorrectly, then. (I'm still not sure, there was quite some confusion, maybe the feature appeared in gnome-terminal without a way to turn it off, and the escape sequence was then introduced by xterm? I can't remember. Whatever.) > The fact that this user wants only wheel support may be a very specific > choice, and he didn't complain that this hack wasn't enabled by default > in xterm. I've seen a lot of people looking for mouse wheel support in "less" on various forums, having seen it already e.g. in gnome-terminal, wondering where it disappeared. I didn't see people complaining about the existence of this feature, apart from you. cheers, egmont
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
Hi, > I'm wondering why this isn't documented in the GNOME Terminal help. Because the help pages document the UI, and not the terminal emulation behavior. It would be practically impossible to provide an exhaustive description of the emulation behavior. (Even if we did so, a wiki page or something similar would probably be a better platform; rather than the help pages which are expected to get translated to a plethora of languages.) > I think that this should be part of the application configuration > (e.g. less), which could enable this feature at startup and disable > it before exiting. That approach would have pros and cons, too. For example, it would need to have explicit support from every application; it would only work in those few that actually care enough to implement emitting these sequences. Currently it works everywhere. For apps that do care about it, they can implement mouse support so that they receive the actual scroll event, and can act on it however they wish. E.g. "less" could scroll back by 6 lines on its viewer, but jump back by 1 entry in the search input field. You can't do this 6 vs. 1 line toggling with the 1007 mode. I can't really imagine an app that doesn't care enough about scrolling to add mouse handling, but would care enough to add support for this 1007 "fake scrolling". Consider this feature a dirty hack for non-mouse-aware apps. :-) I don't think it's a feature GNOME Terminal / VTE designed, by the way. I think it originates from xterm, although I'm not entirely sure. cheers, egmont
Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen
Hi, You can disable this behavior with: printf '\e[?1007l' See "Alternate Scroll Mode" at https://invisible-island.net/xterm/ctlseqs/ctlseqs.html . > This is potentially destructive, as what these and keys do depend > on the application. You're right, I can't argue with this. Many times it's pretty convenient though, e.g. inside "less". cheers, egmont
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Hi, Sorry, I missed this bit: > I've just tried on another machine, which uses nouveau instead of > the nvidia driver, and I cannot reproduce the issue. Does that machine have the very same packages (e.g. both are an up-to-date sid), same cairo version, same configs (I know this one's impossible to tell)? If not then it could be purely a coincidence. But I tend to more and more suspect the nvidia driver at this point. cheers, e.
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Hi, Thanks for the screencast, I'll try to see if I can reproduce the bug based on that. (I noticed the glitch at the right side of the test file, at the X pattern too.) > It is better to move the window slowly Yes, that's what I did, pixel by pixel. > handled by VTE like the box ones? Yes, these diagonal lines (actually all in the U+2500 .. U+259F range) are painted manually. As for the font, only its dimensions should be relevant. > Note: I'm using the FVWM window manager, no desktop environment, > and the NVIDIA driver (provided by the official Debian packages). I have some ATI Radeon. According to my memories from a loong time ago, there used to be two nvidia drivers: an open-source non-accelerated and a closed-source accelerated one, one called nv and the other called nvidia (not sure which was which). I don't know if this is still the case. If so, do you happen to know which one you're using? Can you by any chance switch to the other one? And/or if you have another video card built in to the motherboard (typically Intel on laptops, really unsure about desktop), can you maybe try that? Unfortunately I cannot remember at all how to switch between them, so figuring out would be up to you. At this point I cannot rule out the possibility of this being a bug in the nvidia driver, or cairo, or somehow their interaction. But it also could be a bug in VTE. Thanks a lot, egmont
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Note, mostly for myself: This reminds me of https://bugzilla.gnome.org/show_bug.cgi?id=721761#c47 . Could you please post a screenshot of the entire contents of your screen, or perhaps even a screencast? Details like the location of the previous/next character of whatever kind (e.g. manually drawn underline, replacement box etc.) might make a difference and might be the key to reproducing the issue. Thanks!
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Hi, Just for the record, the test file is the same as in bug 912329, correct? In which direction do you move the other window? (I tried multiple possibilities.) I couldn't reproduce the bug on Ubuntu Cosmic, fvwm, and vte 0.54.2's test app. If you feel like, could you help trying out vte 0.54.2 and git master, compile the standard way (./autogen.sh or ./configure; make) and then run ./src/app/vte-2.91 ? In master we changed a couple of things around repainting. In particular, we always repaint entire lines, rather than just the desired characters. The actual repaint is I believe still limited to the bounding box GTK asks us to repaint (but I'm not absolutely sure about this), whereas this bounding box can be anything especially with non-compositing window managers. My expectation is that you'd be able to reproduce the bug with 0.54.2, but not with git master. I'm not certain in this outcome, though. And even if that's the case, probably the real bug isn't fixed, just mitigated. That fading line seems to be the cropped version of a steep line. Diagonal lines are drawn in src/vtedraw.cc, at the 0x2571 .. 0x2573 cases. Both kinds of lines are drawn from the top-whatever towards the bottom-whatever corner. So I'm a bit puzzled; if I'm on the right track so far then at one of them we forget to "lift up" the pencil before drawing the diagonal line, at the other one we forget to do this after. Or something like this... thanks a lot, egmont
Bug#912329: gnome-terminal: incorrect rendering of some box characters
Hi, Sorry, I missed that you actually attached a screenshot. I can see double lines there, on the outer frame of the first picture. Could you please elaborate what is the problem you're seeing? Thanks, egmont On Tue, Oct 30, 2018 at 1:57 PM Egmont Koblinger wrote: > Hi, > > Could you please post a screenshot? > > I get double lines in the outer rectangle of the first picture. > > The font should be irrelevant. These characters are drawn manually by VTE, > not taken by the font. Just to be sure, I've checked with your font too. I > get double lines, each 2px wide, with a 2px gap between. > > There's also a similar example at > https://gitlab.gnome.org/GNOME/vte/blob/0.54.1/doc/boxes.txt which we > used while implementing/testing these characters. > > cheers, > egmont >
Bug#912329: gnome-terminal: incorrect rendering of some box characters
Hi, Could you please post a screenshot? I get double lines in the outer rectangle of the first picture. The font should be irrelevant. These characters are drawn manually by VTE, not taken by the font. Just to be sure, I've checked with your font too. I get double lines, each 2px wide, with a 2px gap between. There's also a similar example at https://gitlab.gnome.org/GNOME/vte/blob/0.54.1/doc/boxes.txt which we used while implementing/testing these characters. cheers, egmont
Bug#910208: Crash at encoding change
Package: libvte-2.91-0 Version: 0.54.0-1 Severity: grave Open gnome-terminal, and use its Terminal -> Set Character Encoding menu to switch to another encoding. Switch back, then again to something different. gnome-terminal crashes. Mainstream vte 0.54.1 fixes this issue. Could you please upgrade (or at least cherry-pick this fix)? Thanks, egmont
Bug#910078: the bold capability does not work after sgr0
A minor correction: The said changes appeared in vte 0.52 (gnome-terminal 3.28). Version 0.54 didn't change anything around colors.
Bug#910078: the bold capability does not work after sgr0
Hi, At the end of your prompt you emit \e[37m, that is, change to the 7th palette color (typically light gray), rather than the default color of your emulator. That is, the status at the beginning of executing your command, the status used for the letter "A" is not the default status, not the one which you achieve using tput sgr0 or \e[m or \e[0m. This explains why "B" and "D" don't have the same attributes. Go to GNOME Terminal's preferences, switch to the Colors tab under your profile. You'll find the "Default color" (potentially overridden by "Use colors from system theme"), this is what sgr0 a.k.a. \e[m switches to. You'll also see the 2x8 "Color palette" entries, the upper right of them is selected by \e[37m. Even if these two have the very same RGB value, they might behave differently when combined with the ambiguous "bold/bright" flag. VTE 0.54 changed a couple of things in how it handles colors. The changes were intentional, made in the direction of separating the bold attribute from the colors. The bold counterpart of the default color used to be an automatically generated brighter variant of that color. If your default text color is a light shade of gray, the automatically generated brigher variant was most likely #FF. It's no longer the case, the combination of the bold flag with the default text color still uses the exact same text color, just with bold font. If you preferred the old behavior of making the text brighter, you should set whatever color you'd prefer here as the "Bold color". For the 7th palette color, the bold variant used to switch to the 15th palette color (the one shown underneath). Beginning with 0.54 this behavior is no longer mandatory, can be switched off by disabling "Show bold text in bright colors". (By the way, starting with 0.56 it'll be disabled by default for new users. The same checkbox will remain there for users to re-enable switching to the brighter counterpart.) I hope this clarifies what's going on. cheers, egmont
Bug#909744: Crash with vte-0.54
Package: sakura Version: 3.6.0-2 Severity: grave Tags: patch Open multiple tabs in sakura, and close one of them by clicking on the X button. As of libvte-2.91-0 version 0.54, due to a change in how vte emits the child-exited signal, sakura crashes. Please see https://bugs.launchpad.net/sakura/+bug/1790317 for a fix. thanks, egmont
Bug#909328: More information and new backtrace
Hi, I can also reproduce the problem under Wayland + gnome-shell (but not on X11). On Wayland the window is not forced to fit in the screen, on X11 it is (with gnome-shell). (I incorrectly thought I was testing with Wayland previously while I was actually on X11. I should've tried both, anyways, my bad.) The crash happens when the window size exceeds a constant somewhere slightly below 16384 pixels (about 100 pixels smaller or so) in either direction. Presence of the menu bar, tab bar also influence the number of maximum lines without crash, so it's the window size that matters, not the VTE widget size. - gnome-terminal-server requests some situation that gnome-shell could not > deliver, > therefore it should possibly avoid such a request. > Without having further studied what's exactly going on, I also assume it's something along these lines. We'd need to check if it's indeed gnome-terminal's responsibility to handle the error and try a smaller window size. Isn't it rather a bug somewhere in our underlying infrastructure: wayland, gnome-shell, gtk+ and friends? gnome-terminal, xfce4-terminal and roxterm (three native Wayland, VTE-based emulators that handle app-initiated resize) all crash with "Gdk-Message: 09:55:43.773: Error 71 (Protocol error) dispatching to Wayland display." - vim seems to have a problem to handle SIGHUPs while currently reacting to > user input. > Sending a SIGHUP while vim is idle does not produce a SIGSEGV. > Also I thought inside a signal handler should be done just the absolute > necessary, > at least stdio/printf or malloc is forbidden - does this apply to > sprintf too? > Sure, the less the signal handler does the better, to the extent that it could just flip a flag and do the rest from the app's main flow (check for the flag after the main pselect() which atomically blocks/unblocks the signals the app is interested in). I'm not sure about sprintf either. Vim is known not to handle correctly if two SIGWINCHes arrive quickly after each other. That is, something's not right with its main loop infrastructure. Knowing that, it's a bit less surprising that weird signal conditions can make it crash. cheers, egmont
Bug#909328: More information and new backtrace
Hi Léon, It indeed looks like a gnome-terminal crash. If only vim crashed, you'd still have both of your terminal windows open. All your backtraces are about vim. Do you have a backtrace of gnome-terminal-server? That could help a lot. Without a backtrace, and without being able to reproduce, unfortunately it's pretty unlikely that I'll be able to find the problem. I'm honestly lost about the various contradicting vim backtraces. The one with SIGHUP, as you say, corresponds to the terminal disappearing, that's the expected behavior in vim if the terminal crashes. But at the other two occasions did vim really also segfault? (Now, it could be that vim doesn't always handle correctly the terminal disappearing, and instead of a clean SIGHUP exit it segfaults... who know.) It's a bit suspicious to me that two pieces of software segfault at the same time. Could it be a faulty hardware? Have you experienced any unusual behavior in other software? Is there anything suspicious in "dmesg" output? Could you please do the following for me: in gnome-terminal start "script -f" and inside that start "vim". Do the ":set lines=999". Does it crash? If it does, restart gnome-terminal and execute "cat typescript". Does it crash again? If so, could you please attach this typescript file? Thanks a lot, egmont
Bug#909328: gnome-terminal: Crashes when using 'set lines=999' in Vim editor
Hello, I also tried and couldn't reproduce the problem. It's probably a race condition as gnome-terminal asks to be of size 999x999, and the window manager rejects it and forces a smaller one. How do you exactly set the size from vim? Do you put these lines in vimrc, or you type these commands interactively, etc., how exactly? I'm asking because let's say whether the two dimensions are modified in a single step or in two consecutive steps might make a difference. What's your display server (X vs. Wayland), what graphical desktop and window manager do you use? I'm asking because potentially all of them behaves somewhat differently. Does vim's startup always crash gnome-terminal for you? If not then approximately how often? A backtrace would indeed be great, I'd add to Bernhard's response that libvte-2.91-0 should also be compiled with debug symbols, since the crash is most likely inside vte. Thanks, egmont
Bug#899031: [roxterm] Please provide new roxterm packages
... and he's also the maintainer of the Debian package, haha, I missed this bit :) Tony, do you feel like reviving maintenance of the Debian package, or perhaps finding a new maintainer for it? Thanks, egmont
Bug#899031: [roxterm] Please provide new roxterm packages
Hi, > it seems some people continued ROXTerm development on Github: I'd like to emphasize that it's not just "some people" who continue roxterm (maybe an unofficial fork or so). It's _the original author_ who moved it to a different location and is working on the project again. cheers, egmont
Bug#908817: RFP: fonts-old-hungarian -- Font for Old Hungarian (Rovásírás)
Package: wnpp Severity: wishlist Version: 0.5 URL: https://oldhungarian.eu/ License: CC-BY-SA 3.0 Unicode 8.0 (released in June 2015) allocates the range U+10C80 .. U+10CFF for "Old Hungarian" script and defines 108 characters. Probably none of the fonts you ship provide glyphs for these codeponts. I tried a few popular ones, including Google's Noto which has probably the biggest coverage, and these ones aren't available. This particular implementation that I'm pointing to is the only one I could find on the web that uses the official final Unicode codepoints. The font I'm kindly asking you to include seems to be of great quality work for me. The author has taken care of several special cases, including defining optional ligatures for some symbols that were debated and didn't make it into the standard as standalone codepoints, as well as including two special symbols that are used in Old Hungarian but belong to another Unicode range and are missing from many fonts. This project: https://oldhungarian.eu/ https://github.com/OldHungarian/old-hungarian-font https://github.com/OldHungarian/old-hungarian-font/releases Further links: http://www.unicode.org/charts/PDF/U10C80.pdf https://en.wikipedia.org/wiki/Old_Hungarian_alphabet Thanks a lot, egmont
Bug#908120: gnome-terminal: Cursor disappears when changing or moving window
Upstream gnome-terminal bugreport at: https://gitlab.gnome.org/ GNOME/gnome-terminal/issues/29 ... although chances are it's a bug in some other component, not gnome-terminal or vte. I'd appreciate if you could join our investigation there. thanks, egmont
Bug#899376: gnome-terminal: Ctrl-Shift-Enter/Ctrl-Enter in MC isn't working on Wayland
Hi, Terminal emulators don't send anything special on Ctrl-(Shift-)Enter, they can only send the same newline they do on Enter. MC has a hack called X11 support: Whenever it receives a newline from the terminal emulator, it queries the X server whether any modifier is pressed at that time. That's how Ctrl-(Shift-)Enter can have different actions. Give it a try under X11: do an "unset DISPLAY" and then start up "mc", these keys won't work specially anymore because mc can no longer find the X server. xterm still runs via the X compatibility layer called XWayland, that's why this hack still works there. GNOME Terminal, on the other hand, is a native Wayland app (if run under Wayland), there's no X server involved to connect to and query. I'm almost certain that Wayland's security model doesn't allow the same hack; but even if it does, it's not (yet) implemented in mc. Alt-Enter should still do the same as Ctrl-Enter used to do with the X11 hack, since in that case the terminal emulator sends a different sequence. I think the best you can do now is get used to Alt-Enter. I don't know off the top of my head how to bind some keypress to Ctrl-Shift-Enter's action, and wherever it's possible at all; you should consult mc's documentation. I guess mc should add some alternate keybinding by default. mc's manual mentions at C-Enter and C-Shift-Enter that "[m]ay not work on remote systems and some terminals" cheers, egmont
Bug#890769: libslang2: incompatible with the extended terminfo format in ncurses 6.1
Hi, FYI: slang-2.3.2 is out now. cheers, e. On Wed, Feb 21, 2018 at 3:17 PM, Egmont Koblinger <egm...@gmail.com> wrote: > Hi Sven & Alastair, > > Thanks a lot for this bugreport and the quick fix! > > I've asked Slang's author to release version 2.3.2 in the near future > to officially fix this issue, and he agreed to do so at the end of > this month. See [1]. > > If that indeed happens, upgrading to 2.3.2 would be a cleaner, > official fix, allowing you to drop the patch. Let's keep an eye on it. > > Cheers, > egmont > > [1] http://lists.jedsoft.org/lists/slang-users/2018/000.html
Bug#890769: libslang2: incompatible with the extended terminfo format in ncurses 6.1
Hi Sven & Alastair, Thanks a lot for this bugreport and the quick fix! I've asked Slang's author to release version 2.3.2 in the near future to officially fix this issue, and he agreed to do so at the end of this month. See [1]. If that indeed happens, upgrading to 2.3.2 would be a cleaner, official fix, allowing you to drop the patch. Let's keep an eye on it. Cheers, egmont [1] http://lists.jedsoft.org/lists/slang-users/2018/000.html
Bug#889898: Remove obsolete /usr/share/vte/termcap-2.91/xterm
Package: libvte-2.91-common Version: 0.50.2-4 The contents of /usr/share/vte/termcap-2.91/xterm have been unchanged at least since 0.28 (gtk2), about 6 years ago. xterm's terminfo description has changed significantly since then. VTE's behavior has changed a lot (got much closer to xterm). I don't think anyone locates that file there, no one would search for any file under that directory. VTE has defaulted to TERM=xterm-256color for quite some time now, so apps open the terminal description file "xterm-256color" and not "xterm", under whichever other directory. And xterm-256color is not even defined in this file. I'm quite certain this file isn't used by anyone (if it is, that's a huge problem), and its contents are heavily obsolete. Its presence might be misleading though for anyone looking at the package's contents.
Bug#887649: cdebconf-gtk-terminal: Please don't depend on unmaintained vte
Hi guys, > We don't do c++ in d-i. Unfortunately this sounds really problematic. As of version 0.42 vte has been using (more and more) C++. This is not like Ubuntu's PCRE2 hack which is a matter of a few hours of work reverting and merging a few commits. It's reasonably impossible to revert to plain C and maintain that as a fork, and upstream has no intention to revert to C either. You might want to have a special libvte2.91 0.40 package, or revive libvte2.90 0.36 for the installer. These are also abandoned by upstream, but already significantly less buggier than 0.28, probably good enough for the installer (after all, 0.28 was good enough until now), and allow you to drop the gtk2 dependencies, potentially buying you many more years (perhaps you'll be good until you decide to replace gtk3 by gtk4 in the installer). I understand it's far from ideal. Other possibilities include ditching the "no c++" policy (pulling in a 1.5M lib for the sake of a 400k one, sigh), maybe seeing if there's a good enough "minimal" replacement for libstdc++ providing just the basics that are sufficient for VTE; or finding a different terminal emulator solution. cheers, egmont
Bug#887429: Depends on development and obsolete packages
Package: guake Version: 3.0.0.b2-1 The brand new package for Guake's GTK+3 version depends on certain development packages, such as libglib2.0-dev, libgtk-3-dev and libvte-2.91-dev. Presumably they pull in dozens of other packages as dependencies, if not hundreds (complete X11 development suite). Enduser applications should require solely non-development packages, such as libglib2.0-0, libgtk-3-0 and libvte-2.91-0. The package also requires libvte-common which belongs to the gtk2-based vte 0.28, and is about to be dropped from Debian real soon. The correct one is libvte-2.91-common, if required at all. Thanks, egmont
Bug#818434: libvte-2.91-0: Blink attribute doesn't work on VTE terminals such as terminator, gnome-terminal and so on.
This has just been implemented in upstream git, will be available in vte-0.52.
Bug#854414: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."
Hi guys,
Quickly glazing through the thread, a couple of remarks:
- screen/tmux indeed needs that TERM inside them is something
screen-related. Forget xterm or xterm-256color, go with screen,
screen-256color or screen.xterm-256color or alike. This is properly
documented in their docs/faqs and answered on hundreds of random forums
(whereas, of course, the opposite is also answered on random forums, you
should use common sense which answers to trust :)) The most notable
difference is the lack of "bce" causing colored lines (e.g. in midnight
commander) not to fill the entire line, but there are other differences as
well.
- The most standard setup according to my experiences is that TERM=xterm of
the graphical terminal emulator (8/16 colors) translates into TERM=screen
inside (also 8/16 colors), whereas TERM=xterm-256color of the external
emulator ideally translates into TERM=screen-256color. I haven't heard of
any problems with this approach. (Well, strictly speaking you're still in
trouble if you launch screen from a 256-color emulator, detach and then
re-attach from an 8/16-color one.)
- Then ncurses added screen.xterm-256color, which, according to screen's
old-time behavior of prepending "screen." if such a definition is
available, messed up ssh'ing and friends. Of course given screen's
behavior, there's no way such a change could've been introduced without
such breakages.
- I don't understand why you're reluctant moving screen.xterm and
screen.xterm-256color from ncurses-term into ncurses-base. Of course it
wouldn't fix a thing now, but it's not clear to me what it'd break, and
it's desired to make screen.xterm{,-256color} widely available in the long
run. Please do it as soon as possible.
- On my machine (Ubuntu Artful) screen-256color and screen.xterm-256color
are not exactly the same file. We should investigate what's the difference
and why, and which one's the better to have.
- 256 colors became pretty standard perhaps like 5-7 years ago. Since then,
some of us put noticeable effort into pushing even further and have
truecolor support here and there (with less limited success than 256
colors, but it's already available at many places). Please, pretty please
don't make a step backwards and don't advocate solutions/workaround that
reduce the available colors to 8/16. Please don't recommend TERM=xterm or
TERM=screen as a workaround where the underlying terminal is known to
support 256 colors.
- A proper workaround might be to set screen-256color from screenrc, or
translate TERM=screen.xterm-256color into TERM=screen-256color in
/etc/bashrc.
- I've never seen anyone quoting from me; Sven, I'm happy to see you did :)
I can't remember where I wrote those exact words, but I've sure written
something analogous at multiple places. One day I might write a standalone
page summarizing all the issues and outlining a recommendation for
something better.
cheers,
egmon
Bug#877293: gnome-terminal: Missing localization for 'Copy', 'Paste' and 'Copy as HTML'
The missing translations were committed into mainstream gnome-terminal git after the 3.26.0 release, and hence will appear in 3.26.1.
Bug#854149: libvte-2.91-0: x-terminals not properly compose unicode characters
See also https://bugs.launchpad.net/ubuntu/+source/fonts-liberation/+bug/299158.
Bug#799802: [roxterm] Dodgy filename locks up roxterm during rsync (100% CPU)
Hi, I cannot reproduce the issue -- in fact, I came across it on the bugs.debian.org website which is encoded in UTF-8 so it cannot represent the non-UTF-8 you're talking about. I'm copy-pasting the command but it's perfectly valid UTF-8 and no lockup happens. It would be great if you could construct a command line that emits such locking non-UTF-8 (e.g. echo "\x12\x34..."), whereas the command itself can be copy-pasted from UTF-8 websites. That being said, I suspect that this bug might be the same as (or similar to) https://bugzilla.xfce.org/show_bug.cgi?id=13383 https://bugzilla.gnome.org/show_bug.cgi?id=33 https://bugzilla.gnome.org/show_bug.cgi?id=730154 comments 4-7 although that wouldn't explain the 100% CPU usage. cheers, egmont
Bug#854149: libvte-2.91-0: x-terminals not properly compose unicode characters
Hi,
This is a truly interesting bug.
If you highlight and copy-paste only the printed "1" or "2" digits, you'll
notice that "1" carries the combining strikethrough with it. This is one
possible way of making sure that VTE's belief about where that combining
accent is is correct. The problem "only" occurs when it displays it.
To make it more complicated, the behavior:
- depends on which regular characters are used instead of "1" and "2";
- depends on the combining accent
- depends on the font;
- is consistent with gedit.
Let's replace "1" and "2" with "a" and "b", as well as "x" and "y". Let's
also try '\u0301' (accent acute) in addition to the strikethrough.
echo -e '1\u03012'
echo -e 'a\u0301b'
echo -e 'x\u0301y'
echo -e '1\u03362'
echo -e 'a\u0336b'
echo -e 'x\u0336y'
and also redirect the output and open the file in gedit.
And let's try a couple of fonts:
DejaVu Sans Mono Oblique =>
Only the 2nd out of the 6 commands appear correctly ("a" with accent).
The rest: in gedit there's another cell in between containing the accent
only, in vte the accent is on top of the second letter.
FreeMono Regular, Noto Mono Regular, Tlwg Mono Regular, Ubuntu Mono Regular
=>
In both apps: The accent is always on the first character, as expected.
Liberation Mono Regular, Nimbus Mono L Regular =>
In vte: The accent is always on top of the second letter.
In gedit: The acute accent is always on top of the second letter. The
strikethrough is always in an additional cell between the two letters (as
DejaVu in 5 out of 6 cases).
Monospace Regular =>
Like DejaVu, except that the 3rd case also renders correctly (x with acute
accent).
Some conclusions:
It's broken in VTE if and only if broken in Gedit as well.
In Gedit it can be broken in two different ways; either the accent appears
over the second letter, or combines into a glyph that looks double wide
(but actually the cursor or mouse highlight jumps through it in a single
step) and contains the base letter in the left part and the combining one
in the right part. Which of these two broken variants occurs might depend
on the combining character itself.
Whether broken or not might depend on the base character and might depend
on the combining character too.
The only rendering difference between gedit and vte can be explained very
well. Gedit renders the entire flow in one step. VTE instead renders every
cell separately (putting into it the contents it wishes to see there, and
it knows correctly that these combining characters belong to the first
cell). Whatever is painted there might overflow out of the cell (and is
still painted there), but for the next character it's another painting step
started at the location VTE believes is the correct starting position. So
wherever gedit seems to paint three columns looking like "a-b", vte instead
renders "a-" beginning at column 1, and then paints "b" beginning at column
2, effectively looking as if the letter "b" was striked through.
For all the rest, it's a total mystery to me. I have no clue if it's all
these fonts that are buggy, or Gtk+'s font rendering has some fundamental
flow, or what else.
Okay, so let's check Konsole, KDE's terminal emulator build on top of Qt
and KDE libs. Konsole is notorious for not rendering each cell
independently, but rather a continuous run of text in a single step (as
most apps typically do except for terminal emulators).
KDE's behavior is almost the same as gedit's. The only exception I've found
was that with Monospace it rendered exactly as with Dejavu, that is, only
the accent on top of "a" was correct, the one on top of "x" wasn't (it was
on top of "y").
At this point my primary suspects are all these monospace fonts, although
there's sure much more to this story, e.g. there might be some mapping to
precomposed characters or whatnot...
It would be great to get someone heavily experienced in fonts involved in
this thread.
cheers,
egmont
Bug#876757: gnome-terminal: does not set the underlying setting key for "show menubar"
Hi, Right click menu's "Show Menubar" by design only influences the current window (similarly to some other options there, such as selecting a Profile or toggling Read-Only). What you're looking for is the global menu's Edit -> Preferences -> "Show menubar by default in new terminals". cheers, egmont
Bug#820303: remmina: Blank screen on ssh connections
Marek: "Is this bug already in upstream?"-- you've missed my previous comment here that begins with "Upstream investigation and fix". Please those links. Yup, mainstream VTE and Remmina developers have together investigated this issue, located the bug in Remmina, and came up with a patch. cheers, egmont
Bug#854816: remmina: Blank screen on ssh connections
Hi guys, Just one click away from the linked bug 820303, namely in https://bugzilla.gnome.org/show_bug.cgi?id=765382 it was clearly concluded -- and confirmed even by a Remmina developer -- that it was a bug in Remmina, accidentally triggered by a (not buggy) change in VTE. Again, repeating: It is clearly known to be a Remmina bug (with patch available) and by no means a VTE bug. Please act accordingly. e.
Bug#846861: layout is not displayed correctly
I've halved all the size numbers in the config, and it still appears perfectly for me (now the overall window is a "regular" window, smaller than the screen in both dimensions). Just for the record: What is your desktop environment / window manager? thx, egmont
Bug#846861: layout is not displayed correctly
Hi, I cannot reproduce this issue on Ubuntu 16.10 with Terminator-1.90 using your config. I get a terminator window occupying the entire screen, with 2x2 terminals in an equal split. Your config seems to contain hardcoded pixel values like 3200, 1672, 1600... The exact behavior might easily depend on their relation to the actual screen size. What's your screen size? My one is 1920x1080. e.
Bug#846645: terminator: Transparent background not working
Hi, I can confirm the transparency problem. It works on Ubuntu's default Unity 7, though. Also, transparency works under both Mutter and Unity 7 with some other emulators based on the same VTE, namely gnome-terminal with Ubuntu's transparency patch, Terminix, and xfce4-terminal. Forwarded upstream: https://bugs.launchpad.net/terminator/+bug/1647052 e.
Bug#846645: terminator: Transparent background not working
This is two separate bugreports. Transparency: What desktop / window manager are you using? VTE has reworked transparency and it requires a compositing WM. /usr/bin/who not reporting ttys: VTE, as per https://bugzilla.gnome.org/show_bug.cgi?id=747046, no longer does utmp/wtmp logging. e.
Bug#668238: terminator: Doesn't close unlinked files
I've reported this issue upstream: https://bugs.launchpad.net/terminator/+bug/1645500 e.
Bug#668238: terminator: Doesn't close unlinked files
Oh, wait... The fact that these file descriptors remain open _even after you close the corresponding terminal_ is still present (in Terminator-1.90) and is an actual valid issue. Hang on, I'll investigate. e.
Bug#623062: terminator: High memory usage
Hi, FYI: Approximate memory usage (RSS) for me right after starting up the apps is: gnome-terminal, xfce4-terminal, mate-terminal: 35 MB terminator: 55 MB terminix: 60 MB I'm on Ubuntu Yakkety, some of these apps are from Zesty beta or manually compiled, all of them using Gtk+-3 and corresponding libvte-2.91. (In the original report, and probably in the followup comments too they were probably based on Gtk+-2 and libvte9.) I don't know where these large numbers come from, but I can easily imagine Gtk+ itself (with all the things it's doing under the hood, e.g. I guess it caches the font, etc.) bringing in perhaps a good 30 or so megs (hey, an empty gedit consumes 44 MB for me), and perpahs the Python overhead (including its automatic deferred GC) is yet another 20 M. Dunno. VTE is expected to consume somewhere around up to maybe 0.5 MB - 1 MB per widget once you actually start using it (that is, once you produce a nice amount of output, not just the initial shell prompt and a few lines). That is, it's negligible here. cheers, egmont
Bug#822450: [terminator] Separator size doesn't work
Hi, I think this is fixed in the brand new 1.90 version; could you please confirm it? cheers, egmont
Bug#668238: terminator: Doesn't close unlinked files
Hi, I've just read it more carefully that you're not only worried about the number of files, but also about the overall disk usage and the entire design as well. Along with the encryption, compression was also implemented, so the overall occupied size is now (with the gtk3-based vte-0.40 or newer) about 3-4x smaller than before. (Note that compression relies on the sparse block features of Unix filesystems, see https://bugzilla.gnome.org/show_bug.cgi?id=738121 and https://git.gnome.org/browse/vte/tree/src/vtestream-file.h?h=vte-0-46 if you really care about the technical details.) Looking at your bullet points in order: 1. Just make your /tmp large enough, or decrease the scrollback size. "or is actually tmpfs in memory" -- this is not a concern; the scrollback has to reside somewhere, if it's in vte's (terminator's) memory then it's essentially the same as being written to a file on tmpfs. You can't have a large scrollbar that's just magical without being stored anywhere :) 2. That's a valid point, but not related to vte or terminator in particular, and should have an app-agnostic generic solution. With a trivial modification vte could only unlilnk those files when the widget is destroyed, it'd make them easier to discover, yet remain on the disk if the app crashes. Unlinking and keeping an fd open is a typical pattern used by many others who won't need the file once the app exits, I see no reason for vte not to follow this pattern. 3. As said, with newer (gtk3-based) vte (used by terminator-1.90) it's at most 3 per widget. 4. I don't understand this at all. Who would select() on them? It's unlinked as soon as created, so noone is supposed to open it other than the creator vte / terminator itself. It's not waiting for data to appear there, so there's no select() whatsoever going on on these files, only read()/write() operations. cheers, e.
Bug#668238: terminator: Doesn't close unlinked files
Hi, It is by design that Terminator (more precisely, the vte widget that does the actual terminal emulation) stores the scrollback data in unlinked temporary files. Terminator-0.98 uses the gtk2-based vte for terminal emulation, which uses too many of them, up to 12 per vte (that is, per terminal). Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've optimized it to use at most 3 files per vte. (Moreover, the contents are no longer in plain text, they are encrypted.) e.
Bug#833901: terminator: Copy and paste from other applications to Terminator are failing
Hi, Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does have a bug around the so-called "bracketed paste mode" which causes the behavior you see. Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've fixed this bracketed paste bug. e.
Bug#818635: terminator: Terminator omits lines in some scenarios (may be related to coloring)
Hi, Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does have a bug that sounds like the one you're describing (and yes it was related to coloring). Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've fixed the scrollback corruption bug that we were aware of. e.
Bug#751588: Setting TERM=terminator messes up console
The correct setting for TERM is xterm (or rather xterm-256color). This variable is supposed to refer to a terminal behavior description, not to the name of the executable that is a terminal emulator. Terminator uses the VTE widget for actual terminal emulation, which in turn tries to emulate xterm as closely as reasonable. VTE defaults to xterm-256color nowadays (used to be xterm up until about a year ago), and so does gnome-terminal (the "reference" frontend developed together with VTE). If kupfer (whatever that is) requires the terminal emulator's executable name to be specified in $TERM then it's a bug (a fundamental misunderstanding of this variable) in kupfer and should be fixed there.
Bug#809343: Lines disappear from scrollback
Hi, Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does have a bug that sounds like the one you're describing. Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've fixed the scrollback corruption bug that we were aware of. e.
Bug#807668: terminator: please package gtk3 port to experimental
Hi, Terminator 1.90 (based on gtk3) has been released. In the mean time, the gtk2 version will no longer be maintained. Please see the official announcement at https://gnometerminator.blogspot.com/2016/11/because-theyre-like-buses-which-is.html . cheers, egmont
Bug#747244: gnome-terminal: mouse cursor hides when typing and won't unhide when moving it again
Hi, I belive this is the same as the upstream bug at https://bugzilla.gnome.org/show_bug.cgi?id=725342, which in turn boiled down to the Gtk+ focus-out issue: https://bugzilla.gnome.org/show_bug.cgi?id=677329. If so, it's fixed in gtk+ 3.18.9. cheers, e.
Bug#330907: /usr/sbin/gnome-pty-helper: writes arbitrary utmp records
FYI: VTE (Debian package name: libvte-2.91-0) no longer ships gnome-pty-helper as of version 0.42. VTE, and in turn gnome-terminal, no longer does utmp/wtmp logging at all. See https://git.gnome.org/browse/vte/commit/?id=299c700 and https://bugzilla.gnome.org/show_bug.cgi?id=747046 for further details. cheers, egmont
Bug#843642: gnome-terminal: Scrolling with touchpad combines smooth and rough movement
There was no upstream bugreport up until now, however, I've talked to vte's main developer when I saw the roxterm bug and he had no clue about it either (neither did I). Mind you, neither of us actually started to deeply investigate the story. I've created an upstream bug now: https://bugzilla.gnome.org/show_bug.cgi?id=774430
Bug#843642: gnome-terminal: Scrolling with touchpad combines smooth and rough movement
Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/
Bug#834455: gnome-terminal: Window height decreases by 1 line with each typed character if multiple tabs are opened
Note: The height change probably occurs when the terminal title is set (perhaps even set again to its previous value). If the title is set via bash's PS1 then it might set it again on each keypress (but keys pressed e.g. after a "cat" won't change the window size). On Wed, Aug 17, 2016 at 11:04 AM, Egmont Koblinger <egm...@gmail.com> wrote: > Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898 >
Bug#834455: gnome-terminal: Window height decreases by 1 line with each typed character if multiple tabs are opened
Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
Bug#825069: RFP: terminix -- Tiling terminal emulator using GTK+ 3 and VTE
Package: wnpp Severity: wishlist Version: 1.0.0 (as tagged in git) or newer from the 'stable' branch (see https://github.com/gnunn1/terminix/issues/25) URL: https://github.com/gnunn1/terminix License: MPL Terminix is a tiling terminal emulator. It is more or less similar to Terminator (which is already shipped by Debian). Unlike Terminator, which still uses Gtk+-2 and its matching ancient buggy and unmaintained libvte9 for terminal emulation, Terminix is based on the newest Gtk+-3 and libvte-2.91. Terminator as a project is also pretty much abandoned, whereas Terminix is actively being maintained. After significant amount of development and testing-bugfixing, version 1.0.0 has just recently been tagged in git. It has a decent UI, a neatly organized prefs window, and cool features such as a session sidebar. It is also, according to my best knowledge, the first libvte-2.91 based terminal emulator that brings back the popular feature of background image (which is no longer explicitly supported by libvte-2.91, but could be hacked around by placing an image behind a transparent vte widget). (This was committed shortly after 1.0.0.) I believe Terminix is a great replacement for Terminator, an actively maintained project providing a nicer user interface, better overall experience, and most importantly, a significantly newer and better behavior for the actual terminal emulation. Thanks, egmont
