> @egmont-gmail For users on 22.04, would you suggest upgrading to 24.04 as
> well ?
> Is this something you would recommend or are there some important pitfalls to
> know about beforehand ?
@toniopelo I cannot make a generic recommendation. It depends on your
circumstances, priorities,
> The only thing that has worked for me is listed below
> 1. Reinstall Ubuntu LTS 22.04.4 without any upgrade or just don't connect it
> to the internet.
To anyone who considers reinstalling the OS due to this issue (because
you messed up your system beyond repair, or whatever): Why not go for
Sorry if I wasn't clear. I didn't mean what if you toggle transparency
after the bug manifests.
What I meant was: What if you completely disable transparency, use
gnome-terminal without enabling that feature. Maybe even restart gnome-
terminal, just in case. Does the bug still occur then?
If so,
Just wondering, does it help if you disable transparency (in Preferences
-> Unnamed profile -> Colors)?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/2064716
Title:
Upstream GNOME Terminal 3.52.1 received a change that _looks_ like it
_might_ fix this. I don't know, there's no bug entry linked to it, we'd
have to try and see if it indeed fixes the problem.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
*** This bug is a duplicate of bug 2059847 ***
https://bugs.launchpad.net/bugs/2059847
It's a bug in the mutter package; a fix is on the way. See bug #2059847.
** This bug has been marked a duplicate of bug 2059847
Input lag or freezes on Nvidia desktops with X11 after logging
> .background.decorated:backdrop {
This still doesn't feel entirely good. The background can be applied to
a window, in which case it needs to be restricted to the .decorated
property; but I presume it can also be applied to many other GTK widgets
in which case it shouldn't be restricted, at
DING developer's response is basically that they clear the "decorated"
property of the window, and the theme should handle that.
Based on this, I think the correct solution for the Ambiance/Radiance
themes is to further restrict the offending block with the ".decorated"
selector, i.e.
Let's see what DING devs think: https://gitlab.com/rastersoft/desktop-
icons-ng/-/issues/315
** Bug watch added: gitlab.com/rastersoft/desktop-icons-ng/-/issues #315
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/315
--
You received this bug notification because you are a member of
> Wow, I didn't realize that people were still trying to use Ambiance
and Radiance (from source package ubuntu-themes) with Ubuntu 24.04 LTS.
I'd love to switch to Adwaita or Yaru, but I prefer to have dark window
header and light window contents, and I haven't found yet how to do it
in those.
Without root access (or being worried of an update overwriting the
changes), this is how I could fix it as a user.
I've placed this in my ~/.config/gtk-3.0/gtk.css file:
window.desktopwindow.background:backdrop {
box-shadow: none;
}
Don't ask why it's gtk-3.0 and not 3.20 or 4.0, I have
It's /usr/share/themes/{Amb,Rad}iance/gtk-3.20/gtk-widgets.css line 18:
.background:backdrop {
color: @backdrop_fg_color;
box-shadow: inset -1px 0 shade (@bg_color, 0.94);
}
Change that to 0 (or I guess you could remove the entire line or even
the
I've modified /usr/share/themes/Ambiance (recursively), search-replacing
all the "1px" to "10px", and (after logging out and back in) the line at
the desktop's right edge looks about 10px wide.
So we're on the right track.
--
You received this bug notification because you are a member of Ubuntu
Looks remotely related: https://askubuntu.com/questions/927893/white-
line-on-left-of-ubuntu-launcher-when-desktop-icons-enabled
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-shell in Ubuntu.
I can reproduce the problem on two computers, both running fully-updated
24.04 beta.
For me, the bug appears if all of these circumstances are met:
- /org/gnome/desktop/interface/gtk-theme is Ambiance or Radiance
- one of the windows is focused
- the Desktop Icons NG (DING) extension is enabled
*** This bug is a duplicate of bug 2059847 ***
https://bugs.launchpad.net/bugs/2059847
Duplicate of bug 2059847.
See also: https://askubuntu.com/questions/1509058/input-delay-on-
terminal-ubuntu-22-04-4
** This bug has been marked a duplicate of bug 2059847
Input lag or freezes on Nvidia
> Upstream Gnome 46 made a lot of changes recently to improve
performance and input lag in Gnome-Terminal. Those changes are separate
from this bug.
Exactly.
> I don't know whether those changes were backported to Ubuntu 22.04,
which ships Gnome 42.
They weren't, and almost certainly won't be.
@ Daniel van Vugt,
The faulty change has a timestamp of 22 Feb, and the package began to
arrive at users probably on 29 Mar. That's a difference of 5 weeks.
I'm not familiar with Ubuntu's internal procedures, I don't know how
things work, which component (e.g. building packages, QA, somewhat
> [amirsalarsafaei] I downgraded my mutter to 45.0-3ubuntu3 but the
issues persists
Mentioning just in case:
You should downgrade all the packages built from mutter's source that
you have installed, including libmutter-13-0, mutter-common, mutter-
common-bin etc. (Or at least I don't know which
Seems to be reported upstream at
https://gitlab.gnome.org/GNOME/mutter/-/issues/3384.
The upstream bug unfortunately also made it into Ubuntu update packages
in https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2054510.
** Also affects: mutter (Ubuntu)
Importance: Undecided
Status:
Another most likely duplicate: https://github.com/gnome-
terminator/terminator/issues/899
And yet another most likely duplicate:
https://bbs.archlinux.org/viewtopic.php?id=294164. Here a user claims
that downgrading gnome-shell and mutter fixes the issue, and points to
upstream issue
During the last barely more than 24 hours, at least 4 people have
reported/confirmed heavy latencies newly appearing in their GNOME
Terminal. One person with Ubuntu 23.10 and two people with Ubuntu 22.04
(one of which comments has just been removed).
The downstream patch added by Ubuntu to address this issue is suspected
to cause a crash, see lp:2049923.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1493964
Title:
H trying to make sense of it...
There's hardly any code from gnome-terminal itself in the stack trace,
most of them is from GTK.
#10 is from update_color_scheme():
if (gdk_rgba_hash (>bg_color) != gdk_rgba_hash ())
{
priv->bg_color = bg;
g_object_notify (G_OBJECT
> change to that new tab
This is a no-op because the new tab is automatically swithed to,
correct?
---
Are you on Wayland or X11? This command should answer it:
echo $XDG_SESSION_TYPE
---
I cannot reproduce the crash. The steps to reproduce are very simple, so
I believe we should have
Maybe the bug you _really_ wanted to report is that gnome-terminal
doesn't use the "surrounding text" feature of input methods?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
By the way... absolutely independently from terminals...
U+17d2 is a combining accent. When I checked (many years ago), major
graphical toolkits (e.g. GTK and QT) disagreed whether the backspace
keypress should delete only the combining accent, or the entire glyph
(base character + combining
Correct me please if I'm wrong, but it looks to me that you have studied
the relevant source code and even located the problem in one of the ibus
related package.
So I'm wondering, shouldn't you have filed this bug against that
component, rather than gnome-terminal?
Is there anything
It's never the terminal emulator (whether GNOME Terminal or any other
terminal app) that decides what to print on a backspace. The only thing
it does is that it tells over the tty line that the backspace key has
been pressed.
It's the remote party, which could be the application running inside
It looks to me that you still don't understand how it's all meant to
work.
You found a possibility that we did not intend to have, involving
dragging. This unexpected behavior that you found will be disallowed in
future versions.
Here's how it's supposed to work:
In the Colors tab of the
We just made the actual behavior a bit cleaner.
Can you point out any particular piece of text in the help that you
think mislead you and could be improved?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8050
** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #8050
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8050
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
The bottom 16 "palette" pictures are not the colors to choose from. They
are the 16 basic slots whose colors you can also configure.
Click on any of these: either default fg/bg, bold colors etc. or one of
the bottom 16 ones. Pick a color in the color cube or enter a hex value.
Close this window
I have to start by asking the obvious: Did you notice the checkbox in
front of the grayed out options and toggled them?
If so: How do you create the new profile: by creating a fresh one (the
"+" sign next to "Profiles") or by cloning an existing one?
I don't think anything of importance changed
What do you mean by "split windows out from tabs"? Do you mean right-
clicking on the tab and choosing "Detach Terminal"?
Do I understand correctly that the freeze and crash always happens right
after opening a new window or detaching a tab? Does the new window
appear before the freeze or not?
What we _could_ perhaps do (because detecting a URI in a text flow is
undefined territory, with already quite a few quirks in place, such as
stripping off the trailing dot) is to strip off the trailing
":linenumber". That is, the trailing ":" if it's followed by numbers
only.
That way you could
The problem is: according to the URI specification, there is no way to
denote the line number. In fact, the URI
"file:///full/path/to/filename.cpp:linenumber" refers to a file whose
name is literally "filename.cpp:linenumber".
Correspondingly, the entire stack that handles the opening of a URI
Looks the same as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1052172.
If it's indeed the same, and if the analysis over there was correct,
then this was a bug in package libvte-2.91-0 version 0.74.0-1 and is
already fixed in version 0.74.0-2.
** Bug watch added: Debian Bug tracker
I've just found a link to this ancient bugreport in
https://en.wikipedia.org/wiki/ANSI_escape_code.
Unfortunately this discussion here contains two confusing mistakes. I'd
like to correct them for future reference purposes. No action necessary,
other than perhaps closing this bug, and fixing the
As far as I can see, VTE did not change. However, any external
circumstance might have accidentally made it occur much less frequently.
Please get back to me if it crashes again, knowing what action triggered
the crash might be a big clue for us.
--
You received this bug notification because
I'm starting to wonder whether it's really
https://gitlab.gnome.org/GNOME/vte/-/issues/2577, or perhaps the change
done there covers up this bug (prevents a crash) but might still result
in slightly incorrect behavior (e.g. not recognizing whatever needs to
be recognized as being under the mouse),
alainpannetier,
You show how to rebuild the terminal emulator widget (not exactly the
version shipped by Ubuntu, without the patches and configurations
shipped by Ubuntu), with one patch that is utterly irrelevant to this
topic here.
I don't have the slightest idea how that could fix the truly
> EDIT: THIS IS THE WORKAROUND:
> bind 'set enable-bracketed-paste off'
It's absolutely unclear to me what you're referring to here. You mention
a workaround that wasn't mentioned earlier in this thread, the word
"bind" first appears in your comment (so: where did you take it from?)
then you say
I assume you paste this to the shell (command line).
I can reproduce the same problem in xterm with the bash shell. Not with
zsh, though.
Therefore it's a bug in bash (shell), not gnome-terminal.
** Also affects: bash (Ubuntu)
Importance: Undecided
Status: New
--
You received this
Most likely it's upstream bug
https://gitlab.gnome.org/GNOME/vte/-/issues/2577.
** Bug watch added: gitlab.gnome.org/GNOME/vte/-/issues #2577
https://gitlab.gnome.org/GNOME/vte/-/issues/2577
** Also affects: vte2.91 (Ubuntu)
Importance: Undecided
Status: New
--
You received this
Re "cat" (which should rather be "ls -1") with LTR vs. autodetected
directionality:
Let's use the convention here that uppercase letters are fake Arabic,
e.g. imagine that the word [written as LTR here] "ARABIC" is a valid
Arabic word which is supposed to visually appear as "CIBARA".
Let's have
Re "nano" with LTR vs. autodetected directionality:
The LTR screenshot is more obviously "broken" (or at least
undesireable). The autodetected directionality's brokenness is less
obvious, maybe no breakage is visible in this particular screenshot, but
is still broken.
Maybe it looks pretty much
Hi M.Hanny,
Thanks a lot for spreading the word about BiDi support in VTE!
Really no need to apologize about your English! I'm not a native English
speaker either, and your English is at least as good as mine. We have no
communication issues at all!
---
> Ideally, there shouldn't be a text in
> The only thing that remains is related to bug 2 and the RTL text auto-
detection in VTE. I am yet to hear from Egmont on anything we can do in
this regard.
Both the autodetection "on" and "off" values have pros and cons. I don't
think either one is better per se than the other. One is better in
** Package changed: vte (Ubuntu) => vte2.91 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/2002290
Title:
Poor Arabic rendering in VTE
To manage notifications
Hi M.Hanny,
I'm so glad that you're way more familiar with fontconfig quirks as well
as Ubuntu processes than me. I wish you good luck in getting some better
config accepted and made default in Ubuntu!
-
Re lam-alif:
As far as I remember, and
Hi M.Hanny,
Re bug 1 (rendering):
Thanks for attaching screenshots, I was lazy to do that. Indeed this is
also how the letters look to me.
It would indeed be great if Ubuntu could change its default font choice,
at least for Arabic locales. I don't know what would be the best place
to bring it
To be absolutely fair, I have to add this:
One thing, namely the handling of BiDi _control_ characters at the very
beginning of a paragraph (logical line), remains as a TODO item both in
the spec and in VTE's implementation (both of which are really
nontrivial).
I just ran out of motivation and
(I am the one who designed [1] and implemented RTL (right-to-left) and
BiDi (bidirectional) text support in VTE.)
The two issues you report here are totally independent.
Re bug 1:
Terminal emulators, by their very nature and their legacy of maybe ~50
years, _have to_ operate in a strict
Freshly released bash-5.2 allows to disable the highlighting of pasted
text (while keeping the "bracketed paste mode" functionality enabled),
or even to define custom highlighting.
You need to place something like this in your .inputrc:
set enable-active-region off
or
set
*** This bug is a duplicate of bug 1927063 ***
https://bugs.launchpad.net/bugs/1927063
** This bug has been marked a duplicate of bug 1927063
Terminal prompt got strangely replicated when resizing terminal horizontally
--
You received this bug notification because you are a member of
(Former VTE developer here)
A terminal emulator's job is to execute the precise instructions it
receives from the connected application (e.g. bash), and in this case,
VTE does that correctly. It's bash (or some other readline app) that
asks the terminal to print the prompt over and over again,
> I see the benefit to the change in bash from a security perspective, so
> perhaps gnome-terminal needs to adapt to this new feature.
You missed the possibility of keeping bracketed paste mode (the
functionality) enabled (as I, for one, have had it enabled ever since
bash added this feature,
> h. Bracketed paste mode is enabled by default.
> If so, it looks like this "feature" can be disabled. How?
The way to disable bracketed paste mode is presumably to place this in .inputrc:
set enable-bracketed-paste off
But DON'T do this! Bracketed paste mode is an important safety measure
...patch its source or ask its developers...
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1926256
Title:
Pasted text in the terminal is always highlighted and selected
> You mean it will always be like this going forward?
I don't know. This was a change in the default shell "bash". I'm not
involved in bash's development, nor in Ubuntu's. I don't know what their
plans are. I don't know if this feature can be disabled in bash (but I
know that it's bash's
This is not an issue with the terminals, this is a new feature of
bash-5.1. Search for the word "highlight" at
https://lists.gnu.org/archive/html/info-gnu/2020-12/msg3.html .
---
This could not theoretically be a bug in gnome-terminal/vte. Terminals
don't directly paint a letter as a
gnome-terminal 3.36, which is included in Ubuntu 20.04, added a config
option Preferences -> -> Command -> Preserve working
directory.
Older versions preserved the directory only when launching a shell, not
when launching a custom command. This behavior was frowned upon by some
folks,
For setting: vte-2.91.sh is intended to do that... the ".sh" extension
was missing, sorry.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1609342
Title:
Gnome-terminal sets
The same applies not just for the mouse mode, but a whole lot of other
terminal modes (e.g. keypad modes, alternate charset, alternate scroll
mode, bracketed paste mode, colors, attributes and many many more...).
The problem cannot be fixed in the terminal: The terminal, by design,
only sees a
Yes the space could be relevant, search for "ignorespace" in bash's
manual.
Also, it's the shell (bash) handling the history, not the terminal.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
gnome-terminal lists the fonts that are monospace according to
pango_font_family_is_monospace(). The font as well as Pango should be
examined why this one isn't believed to be a monospace one.
That being said, you can still set this font using dconf-editor, by
setting
I'd take one step back and ask the question: Why would anyone one a
graphical system need to run a terminal emulator in order to get
notified about new mail? What if someone uses all kinds of other
applications (web browser, document editor, photo viewer, music
player...), just not a terminal, why
It is really, really not the terminal emulator's job to set basic
environment variables.
It should either be done by the environment in which gnome-terminal is
started (e.g. systemd --user), so that the terminal just transparently
passes this on; or should be done by the shell initialization
https://weechat.org/files/doc/devel/weechat_user.en.html#option_weechat.look.eat_newline_glitch:
"[eat_newline_glitch] is disabled by default because it can cause
serious display bugs"
Try the behavior in xterm, too. If it's buggy there too then it clearly
has nothing to do with gnome-terminal.
> but dropping the change creates a regression on the Ubuntu
session/theme
So the situation is: Unpatched gnome-terminal looks perfect on the
default GTK theme and on many others, except Ubuntu's.
Conclusion: Let's patch gnome-terminal! Wow.
I'm wondering: Has anyone considered fixing the
> It appears we would need a new upstream bug to track this because the
old one didn't go anywhere.
This is not true. The old one did go somewhere: It examined the behavior
and clearly concluded that upstream gnome-terminal is NOT buggy here, it
never was. It's one of the Ubuntu patches that
*** This bug is a duplicate of bug 1691678 ***
https://bugs.launchpad.net/bugs/1691678
** This bug has been marked a duplicate of bug 1691678
Scrollbars escape the bottom and right side of the Terminal window by 1px
--
You received this bug notification because you are a member of Ubuntu
This should be a feature request against the command line shell, not the
terminal.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1856438
Title:
auto suggest previously
*** This bug is a duplicate of bug 1849285 ***
https://bugs.launchpad.net/bugs/1849285
This is fixed in official gnome-terminal 3.34.1, which is on its way to
appear as an eoan update. So let me mark this as duplicate.
** This bug has been marked a duplicate of bug 1849285
[SRU] 3.34.2
Autocompletion is done by the shell and its configs, not by the
terminal.
** Also affects: bash-completion (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
Public bug reported:
Please update to gnome-terminal 3.34.1 (or .2) for eoan.
Or, at least, cherry-pick this trivial fix:
https://gitlab.gnome.org/GNOME/gnome-
terminal/commit/2cbc9e6b9be7f4d6b2d92b40e37ec687d36ce98d
A change in GTK triggered a bug in Terminal causing a pretty bad user
> Cursor color: checked, same colors
Well, if cursor color is the same as the default color then it is
requested to be invisible. What you need for the cursor color is
something very different from the defaults (e.g. the two colors
swapped).
Nitpicking: You shouldn't need to restart
Could you please execute this command? Do you see a cursor while it is
running?
echo -ne '\e[?25h\e]112\e\\'; sleep 1000
If not, then while the previous command is still running: Please open
gnome-terminal's preferences, click on your profile in the left-side
bar. Disable cursor blinking,
> What the script does, since you ask,
Sorry for the loose phrasing. I was aware of the global picture, just
wasn't sure (and was lazy to investigate) when exactly a bug would be
triggered, i.e. when that code would be reached, which you answered:
> It is broken if you pass --app-id
Thanks for
Public bug reported:
Debian/Ubuntu package of gnome-terminal 3.34.0 moved the server binary
from /usr/lib/gnome-terminal to /usr/libexec.
The Ubuntu package ships a wrapper script as /usr/bin/gnome-terminal.
This one still looks for the server at its old location in
spawn_terminal_server().
VTE (libvte-2.91-0) version 0.56 mostly addresses this issue, spacing
marks are now combined as desired with the preceding base letter.
(Dotted circles still might be displayed around line wraps, as well as
under the rectangle cursor. For the latter problem, a workaround is to
choose a different
> Starting a gnome-terminal from this terminal
Even executing "gnome-terminal" from an xterm goes through dbus/systemd.
"gnome-terminal" is just a controlling client that asks systemd to start
up a server which then displays the window and does all the rest.
Don't ask why the architecture is
gnome-terminal itself doesn't do any authentication / PAM stuff. It's
probably an issue with `systemd --user` which launches gnome-terminal.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
GNOME Terminal 3.33.3 (VTE 0.57.3) implements BiDi support, according to
the proposal at https://terminal-wg.pages.freedesktop.org/bidi/ .
In alignment with Diego's comments and my responses to them, it
implements multiple modes. Shuffling the characters according to the
BiDi algorithm is enabled
I confirm the previous suspicion: This is _not_ an upstream bug.
Upstream gnome-terminal draws the scrollbar perfectly.
This bug is introduced by one of the Ubuntu patches.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
Public bug reported:
Please remove the ancient GTK2-based vte aka. libvte9{,-common} from
Eoan.
Upstream version has been unmaintained for about 8 years, development
continued in the GTK3 branch (vte2.91 aka. libvte-2.91-0).
Geany is the only package referring to it, and it also does
Please do not forget to remove the pcre patch from Tilix, see
https://bugs.launchpad.net/ubuntu/+source/tilix/+bug/1818991 - thanks!
** Also affects: tilix (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs,
Most likely a duplicate of bug 1770507.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1817438
Title:
Error displaying icon for preference menu in title bar
To manage
Thanks for the report! I can confirm this; forwarded to:
https://gitlab.gnome.org/GNOME/gnome-terminal/issues/81
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1816171
Title:
** Summary changed:
- Mouse scrolling no longer moves between tabs in gnome-terminal 2.30
+ Mouse scrolling no longer moves between tabs in gnome-terminal 3.30
** Description changed:
- In gnome-terminal 2.28 and earlier, scrolling with the mouse cursor over
+ In gnome-terminal 3.28 and
> cursor-blink-time: 1200
> cursor-blink-timeout: 1
> time=463 timeout=10
Oops, time should also match and it doesn't.
Can you confirm that blinking is pretty fast for you, that is, the
duration of an entire cycle (on + off phases) is a bit less than half a
second (463 ms, rather than 1.2
VTE does have code in place to support these variables and they work for
me. No need for reboot, not even to restart gnome-terminal, it should
pick up the change immediately.
It stops blinking the cursor when the focus is lost, and restarts
blinking it when the terminal is focused again. Are you
Hi guys,
- Due to a change in vte-0.54 around the child-exited signal,
unfortunately lxterminal (LP: #1794440) and sakura (LP: #1790317) now
crash when a tab is closed by clicking on the X button. Luckily, a fix
is available for both of them. Could you please make sure to apply those
fixes?
- I
Thanks for the report! I've forwarded it upstream:
https://gitlab.gnome.org/GNOME/gnome-terminal/issues/33.
(Note that this shortcut is disabled by default, not assigned to F10.)
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
> I don't think having to hit Enter when you paste several lines [...]
would be a great annoyance
You have the shell as use case in your mind. Other use cases include
e.g. pasting to a text editor. Having to hit Enter there would be quite
an annoyance.
> but if it was for someone, there would
I'm not affiliated with Ubuntu, so I probably shouldn't be the one
warning you, but your style is unacceptable, no matter how serious issue
you report.
gnome-terminal could warn you before pasting a newline. It could offer
to disable that warning, in which case most users would do so, falling
Fix: "I have to admit I don't know what this regex *flag* is for..."
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1666264
Title:
FFe: Update gnome-terminal to 3.24 and
> So the cause is that the MULTILINE flag is just that not set during
compilation?
Compilation of the regex when running tilix, not compilation of the
source code.
I have to admit I don't know what this regex is for, and whether
required in unpatched vte or not. If tilix is warning-free with
It's indeed an opinion, but my one matches Merlijn's (Merlijn, I'd
appreciate if you opened a bug according to Daniel's suggestion (does it
really belong to mutter, rather than some more core wayland
component?)).
In most software, Ctrl+Arrow walk the cursor faster than the modifier-
less Arrow
1 - 100 of 490 matches
Mail list logo
