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
See https://bugs.debian.org/1068339 .
e.
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
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
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.
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
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
I sent the previous comment to the wrong bug, apologies!
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
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 .
I've asked about it upstream at
https://gitlab.gnome.org/GNOME/vte/-/issues/88#note_1849187 .
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
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.
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
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
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
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
Hi,
Thanks, I've created this upstream report:
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253
egmont
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-te
Upstream: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/236
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.)
-
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.
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.
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
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
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
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.
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.
>
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
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.
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
.
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.
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.
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
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
BiDi support is available beginning with libvte-2.91-0 version 0.57.3.
e.
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),
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
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
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
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
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
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
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
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
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
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
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,
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
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
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 y
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
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
A minor correction: The said changes appeared in vte 0.52
(gnome-terminal 3.28). Version 0.54 didn't change anything around
colors.
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
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
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,
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,
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
... 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
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
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
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
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.
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 f
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,
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
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
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).
This has just been implemented in upstream git, will be available in
vte-0.52.
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
The missing translations were committed into mainstream gnome-terminal git
after the 3.26.0 release, and hence will appear in 3.26.1.
See also
https://bugs.launchpad.net/ubuntu/+source/fonts-liberation/+bug/299158.
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
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
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,
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.
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
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
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
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
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.
I've reported this issue upstream:
https://bugs.launchpad.net/terminator/+bug/1645500
e.
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.
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
Hi,
I think this is fixed in the brand new 1.90 version; could you please
confirm it?
cheers,
egmont
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
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
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
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
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
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
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
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.
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
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:
Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/
6 at 11:04 AM, Egmont Koblinger <egm...@gmail.com> wrote:
> Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
>
Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
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
1 - 100 of 149 matches
Mail list logo
