vte-0.39.1 (to be released as stable in Gnome-3.16) changes this to
xterm-256color.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This is caused by https://bugzilla.gnome.org/show_bug.cgi?id=677329 ,
a bug in either Gtk+ or X (unfortunately we don't know).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I wonder if it's the same as
https://bugzilla.gnome.org/show_bug.cgi?id=735101 ... probably it is.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi,
I've been an active contributor/developer of gnome-terminal in the
last 1.5 years.
I firmly disagree with Christoph's comment Apparently upstream
intentionally breaks things or simply doesn't care.
We do care, and we worked hard recently to make gnome-terminal work
reasonably close to
Forwarded upstream: https://bugzilla.gnome.org/show_bug.cgi?id=746665
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=748520
cheers,
e.
In Preferences, you can specify whether a new terminal should be opened in
a tab or a window. This setting is used if you click on the Open Terminal
menu entry.
As you've realized, the two actions still have their separate shortcuts.
It's only the menu entry that offers only one or the other,
Sounds the same as https://bugzilla.gnome.org/show_bug.cgi?id=735101 -
follow this link to find the fix to the Gtk+ patch (
https://git.gnome.org/browse/gtk+/commit/?id=561ff51a) which should ideally
be backported indeed.
e.
Duplicate of bug 765877?
e.
Hi,
As per Andreas's off-bugtracker request, let me send a skeleton patch.
It compiles but sure doesn't run correctly; but at least shows which
are the bits that need to be addressed by someone familiar with
synaptic and C++. Please make sure to review every line of the patch
and address all the
Thanks, I filed it upstream: https://bugzilla.gnome.org/show_bug.cgi?id=754497
> If you have time it would be awsome to test the latest git.
Thanks for your work!
Unfortunately I don't think I'll have time to test it. If it "seems
to" work (starts up the command properly) there's hardly anything that
can go wrong. I recommend that you apply your patch and let the
community
Actually, instead of 0.98 you should really consider the gtk3 bazaar branch.
At this moment, it contains 2 known regressions compared to the gtk2
bazaar branch (which already has maybe two dozens of bugfixes since
0.98), and the underlying VTE library (responsible for the terminal
emulation
Package: cowsay-off
Version: 3.03+dfsg1-15
Package description says:
This package contains cows witch some may consider to be offensive.
Should be s/witch/which/
Upstream investigation and fix:
https://github.com/FreeRDP/Remmina/issues/835
https://bugzilla.gnome.org/show_bug.cgi?id=765382
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
> all terminals in Debian I'd call good currently use libvte9
This is quite subjective.
You might judge a terminal emulator by the "chrome" (the UI, menus, config
dialog, etc.) and then it's entirely up to your taste which one you prefer.
Or you might judge it by the actual terminal behavior.
Even though triggered by a recent change in mc, this is not a bug in mc,
rather a bug in the (ancient, unmaintained, Gtk2-based) libvte9 (vte-0.28).
See the upstream mc bug, as well as the other mc bug linked from there for
explanation.
Fix for libvte9 is at
Hi,
By the way, see https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1566437
comment 7.
I'm wondering, does this workaround really belong to mc? Shouldn't rather
the shell prompt (PS1) emit all kinds of escape sequences that reset plenty
of terminal settings (that faulty apps might leave in a
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
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.
Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
6 at 11:04 AM, Egmont Koblinger <egm...@gmail.com> wrote:
> Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
>
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:
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.
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,
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
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.
I've reported this issue upstream:
https://bugs.launchpad.net/terminator/+bug/1645500
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
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
Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/
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
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,
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
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,
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 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,
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,
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,
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
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 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
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.
This has just been implemented in upstream git, will be available in
vte-0.52.
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).
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 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,
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,
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,
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
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,
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,
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
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
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
A minor correction: The said changes appeared in vte 0.52
(gnome-terminal 3.28). Version 0.54 didn't change anything around
colors.
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
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,
> 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
... 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 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,
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
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
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,
> 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,
> 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,
> 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,
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
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,
> 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
BiDi support is available beginning with libvte-2.91-0 version 0.57.3.
e.
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
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
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
.
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.
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.
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.
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
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,
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.
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
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
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,
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
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,
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,
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,
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
Hi,
Thanks, I've created this upstream report:
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253
egmont
1 - 100 of 149 matches
Mail list logo
