I had similar problems on Utopic (14.10), but not anymore on Vivid
(15.04). The same problem occurred to me with all other system-wide
shortcuts as well, e.g. volume up/down, keyboard layout switch etc. I
heard other people confirming it. Is it maybe the same for you?
--
You received this bug not
See also http://en.wikipedia.org/wiki/MiB
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1467086
Title:
Calculating wrong file sizes!
Status in gnome-terminal package in Ubunt
This bug was located and fixed in Gtk+ (follow the link I posted above),
and the fix (https://git.gnome.org/browse/gtk+/commit/?id=561ff51a) made
it to Vivid. Ubuntu folks should backport it to Trusty too.
--
You received this bug notification because you are a member of Desktop
Packages, which
Sounds really interesting.
Any chance of this being the same as
https://bugzilla.gnome.org/show_bug.cgi?id=730763 ?
Could also indeed be an issue related to Cinnamon. Can you try to
reproduce under a different WM?
Can you download vte-0.38.3, compile with "./configure --enable-debug;
make" and l
There are some known glitches with highlighting, but I'm not sure I
understand your situation.
Let's start with the simplest one: no highlighting, just
Shift+Page{Up,Down}. How does the bug occur exactly? How can I reproduce
it? (I'm using these keys all the time and never had a problem, except
fo
Is there a way to reproduce this?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1460409
Title:
gnome-terminal-server process randomly gets into a deadlock and blocks
gnome-t
Vivid ships 3 parallel versions of vte:
libvte9 0.28.x - used by Gtk2 apps such as terminator, xfce4-terminal
libvte-2.90-9 0.36.x - a tiny bit older than the newest, used by e.g.
roxterm-gtk3
libvte-2.91-0 0.38.x - the newest, used by e.g. gnome-terminal
As stated above, the bug was fixed in 0.3
Ubuntu might decide to create a patch and apply to Vivid, in that case
it'll reach its users in a short time. It's beyond my control (I'm not
an Ubuntu developer, and for this reason I can't close this bug either.)
Even if upstream addressed this situation, it would take 1 year until it
makes it t
@zds: Making it a profile-level setting could lead to another pretty
annoying misleading behavior, e.g. you have two tabs, Alt+2 switches
from the 1st to the 2nd, but then Alt+1 doesn't switch back. There's a
good reason hotkeys are global, not per-profile.
@laney: I wasn't the one pushing for thi
Under Preferences, you can specify whether the "New Terminal" menu entry
opens it in a window or a tab.
Separate shortcuts (Shift+Ctrl+N and Shift+Ctrl+T by default) are still
available.
This was a change done in mainstream gnome-terminal; I have no idea what
was the intent behind it. I have no o
You could also try setting LANG= and LC_CTYPE=en_US.UTF-8
simultaneously - does this work?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1448563
Title:
terminal won't launch w
Gnome-terminal is unfortunately known to have troubles with non-UTF-8
locales, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=732127.
In your case, however, I suspect that you're doing something wrong with
your installation (because you also seem to aim for UTF-8). It's weird
to me that you u
Gnome-terminal indeed removed this feature from the UI. You can still
set the title via escape sequences. E.g. define this function in your
.bashrc:
title () {
echo -n $'\e]0;'"$@"$'\a'
}
and then change the title with the command:
$ title This is my new title
--
You received this bug notifi
As a rule of thumb: try these in xterm (and maybe a few other
terminals); if it's the same there then it's probably a bash/readline
bug :) as it's also the case in these examples.
The first one is especially tricky: in order for both the display to
look good and copy-paste to behave correctly (tha
Beware that:
- The scrollback contents need to reside somewhere. Currently it's on
disk (compressed as of 0.40, but still). We shouldn't surprise users by
filling up their disks.
- Content rewrapping on resize starts to become noticably slow at around
100.000 lines of scrollback.
IMO scrollbac
Public bug reported:
/etc/profile.d/cedilla-brazil.sh complains about error:
bash: [: too many arguments
I don't have LC_IDENTIFICATION, nor anything related to pt_BR.
The error message is printed when I log in in text mode, and a popup
dialog is presented when I log in from the default lightdm
Could this be another manifestation of
https://bugzilla.gnome.org/show_bug.cgi?id=735101 ? It's another case of
gnome-terminal using 100% CPU, and unfortunately we're stuck and ran out
of ideas.
The next time it happens, could you connect to gnome-terminal with
strace (e.g. from an xterm) and see
Another week of heavily using gnome-terminal for everyday work, another
15 MB of data written. (I won't measure this anymore.)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to vte in Ubuntu.
https://bugs.launchpad.net/bugs/1430620
Title:
Okay, there's indeed an OSC 112 (that is: \e ] 112 \a) in the output.
You could try installing the libvte-2.90-9 package from Utopic (and then
restart all gnome-terminal instances), I'm pretty certain this would fix
your problem. (I hope it doesn't have dependency problems.)
(I'm not giving this
Looks from that other bugreport that it's OSC 112 causing a problem.
Support for this escape sequence was added to vte-0.35.2 which appeared
in Utopic.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs
Could you please get a(n as short as possible) script(1) log of this
behavior?
Gnome-terminal handles unknown escape sequences worse than other
emulators. We'd need to understand whether tmux emits something
incorrect, or gnome-terminal (actually vte) just doesn't understand that
sequence.
--
Yo
After 1 week of usage, my gnome-terminals have written a total of 48 MB.
Out of this, about 40 MB was cating my favorite test file 4 times for
speed measurement purposes, and the remaining about 8 MB was the normal
tasks I performed, including management of several remote servers via
ssh, compilati
If it was for me, I probably would have dropped infinite scrollback
support. But apparently some people find it really useful.
We already have a certain code. It was designed with multiple criteria
in mind, including infinite scrollback support, efficient storing on
disk, compression, encryption a
Having two "Terminal" entries is indeed a bug.
As for opening a new tab: There's only a single "New Terminal" entry,
which opens either a new tab or a new window, based on the setting under
Edit->Preferences. The shortcut keys Ctrl+Shift+N and Ctrl+Shift+T are
still available.
--
You received th
> Speed
Encryption added about 10% to the required CPU usage. Now, with in-
memory scrollback, would you keep it encrypted or not? If so, you'd keep
wasting CPU. If not, someone will come along and complain that it's been
written to disk (swap) unencrypted and it leaks data. But other apps
also ca
I have seen the OOM killer killing an innocent process, and other
developers have expressed similar concerns too. That being said, I'm not
against storing the scrollback contents in memory as a possibility, see
the upstream bugreport for details. But I still can't see the SSD wear-
out issue justif
** Patch added: "Count the amount of data written to /tmp"
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/1430620/+attachment/4343310/+files/vte-ubuntu1430620-count-tmp-written.patch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
> But I run out of ram space very rarely.
Maybe because you don't allow large (let alone infinite) scrollback.
> It's highly elegant to keep volatile data in RAM unless RAM is full.
How do you think gnome-terminal should handle that? Suppose you have 4
GB of ram, shall it consume up to 3 GB and
See https://bugzilla.gnome.org/show_bug.cgi?id=730128 for discussions
and workaround.
Short summary: these are hotkeys for changing between gnome-terminal
tabs. You can disable these shortcuts, in that case they'll be forwarded
to irssi or whichever other applications.
Older versions of gnome-ter
With the max speed of vte measured on my computer (as I mentioned
above), producing 75 TB of scrollback data takes about half a year.
(With the compression, it'll be 1.5-2 years or so). Combine that with
the typical load average of your terminals in the long run (including
those times when the app
Vte stores the scrollback buffer's contents on disk, that's what you see
there. See https://bugzilla.gnome.org/show_bug.cgi?id=631685,
https://bugzilla.gnome.org/show_bug.cgi?id=664611 (and maybe a few other
mainstream Gnome bugreports) about discussions and rationale why this
was chosen. Quick sum
> This flag is used to 'upgrade' from xterm to xterm-256color in almost
every bash environment people use...
Then these should be fixed.
COLORTERM's semantics have nothing to do with 256 color support per se,
it was a mere coincidence that all terminals that set this variable also
supported 256 c
In https://github.com/GNOME/gnome-
terminal/commit/1d5c1b6ca6373c1301494edbc9e43c3e6a9c9aaf I've found that
you're most worried how you'll set TERM=xterm-256color.
As pointed out in the links above, checking for $VTE_VERSION could be
one approach.
Note that vte-0.40 (gnome-terminal-3.16) will def
> This affects release: Vivid Vervet
How exactly does it effect it?
$COLORTERM was dropped for a good reason; appart from the links you
posted the best explanation is probably at
https://bugzilla.gnome.org/show_bug.cgi?id=733423.
$COLORTERM should not be necessary ever. Instead of bringing it ba
I'm not against fixing it at all, but ... if you take a look around
either here among launchpad bugs (both gnome-terminal and vte/vte3) or
mainstream bugzilla and git, you'll find quite a few way more important
issues, including crash scenarios with known fixes - yet there's no
activity and willing
Simple version:
export PROMPT_COMMAND='printf "%*s\r\e[K" $COLUMNS'
More complex version with an inverse exclamation mark:
export PROMPT_COMMAND='printf "\e[7m!\e[0m%*s\r\e[K" $((COLUMNS-1))'
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed
This is not a gnome-terminal bug, you'll see the same behavior in every
terminal.
The problem is that there's no reliable way of querying where the cursor
is, so bash assumes it's in the 1st column when it prints the prompt and
edits the command line. If it's not there, screen corruption is bound
> but I am afraid that due to above reason they won't care about that
report
Rest assured, it's not that we don't care, it's that we couldn't
reproduce on our systems and have absolutely no clue what could be the
problem. Chances are it's some problem with some other component of
Vivid that is s
Nope, sorry, other than patching the source. I'll give it another try
to convince the main author.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1401207
Title:
No 'Select-by-
Unfortunately mainstream gnome-terminal removed this feature in 3.14. See e.g.
https://bugzilla.gnome.org/show_bug.cgi?id=727743
https://bugzilla.gnome.org/show_bug.cgi?id=730632
** Bug watch added: GNOME Bug Tracker #727743
https://bugzilla.gnome.org/show_bug.cgi?id=727743
** Bug watch added
Upstream fix is https://git.gnome.org/browse/gtk+/commit/?id=732af31 (I
haven't verified).
Ubuntu folks should verify this fix, and if indeed works then backport
to their Gtk+ packages.
** Also affects: gtk via
https://bugzilla.gnome.org/show_bug.cgi?id=740613
Importance: Unknown
Sta
Filed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=740613
** Bug watch added: GNOME Bug Tracker #740613
https://bugzilla.gnome.org/show_bug.cgi?id=740613
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu
This is definitely not a gnome-terminal bug. It's either the locale
system, or powertop.
The correct canonical value is LANG=en_US.UTF-8 with a hyphen. You're
better off using this one rather than anything else.
For figuring out what's going on with the locale system, you should use
the command
Looks like a bug in Gtk+ -- the same code can also crash gedit,
evince...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1395250
Title:
XConvertSelection crashes gnome-terminal
> Also, I'm not sure that even if GT would be migrated to VTE 3, that
it would be pushed to 14.04.
I'm absolutely sure it wouldn't. (It has a preliminary vte3 version,
with many remaining bugs, but you might want to give that a try.)
Someone might create an unofficial repo for this package, thou
To everyone suffering from this bug:
You could maybe - as a terrible workaround - disable "bracketed paste mode"
from your shell prompt. In case of bash, you might want to alter your PS1 to
contain
$'... \[\e[?2004l\] ...'
or set PROMPT_COMMAND to echo $'\e[?2004l'.
When pressing ^O to return
A BIG FAT WARNING ABOUT PARALLEL VTE 0.36/0.38 INSTALLS VS BRAIN-DAMAGED
PYTHON GIR:
https://bugzilla.redhat.com/show_bug.cgi?id=1114379 (especially comment
9)
Summary: Just by installing vte-0.38 (next to the already installed
vte-0.36), python apps that happily used 0.36 before will now try to
Typo: ... On the other hand, blocking update of these components until
all of them has a vte-0.38-based version released *sounds* even worse to
me.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.lau
I'm not sure what 'supported' means in this context, but I guess it's
something like the core/default packages of Ubuntu (e.g. config tools,
default desktop including gnome-terminal etc.) as opposed to the
additional software (e.g. other vte-based terminals). Am I right?
I understand that the form
Fair enough, thanks :)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1132700
Title:
gnome-terminal >= 3.7 requires sourcing of vte.sh login script
Status in GNOME Terminal:
Great, thanks!
While we're at it, could you please make sure to upgrade to vte-0.36.3
and gnome-terminal-3.12.3?
Both contain important bugfixes, especially gnome-terminal-3.12.3 fixes
a nasty crash that happens relatively often.
We're talking about minor version numbers here, it should be as ea
Thanks Martin!
I guess it's way too late for Utopic, but will make it into VV, correct?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1132700
Title:
gnome-terminal >= 3.7 req
This is a feature of bash, see "man bash" -> HISTCONTROL
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1378151
Title:
Commands not saved to .bash_history when a leading space
Looking at http://old-releases.ubuntu.com/ubuntu/pool/main/b/bash/, it seems
that up to bash_3.2-0 (which was shipped by Hardy 08.04 LTS) bash's
/etc/skel/.bashrc defined
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'
Beginning with bash_3.2-4 (Intrepid 08.10) PROMPT_
One more thing to consider with the "fallback" approach:
If you do this, users who've manually set PROMPT_COMMAND will remain
with the old method of figuring out the cwd, including all its bugs and
limitations (not remembering symlink components, not working after sudo,
etc.) They would probably
Indeed it could be crucial to know if PROMPT_COMMAND was ever present in
/etc/skel. I think it's fair game if users who have once touched their
configs will need to touch that again.
And it's not that they'll live with something fundamentally broken until
then - it's one convenience feature that
Also, if you really hate to touch configs and love to patch binaries,
how about patching bash/zsh to automatically emit OSC 7 without any
configs or env vars? :) I know it sounds crazy first, but if you think
about it for a while, it's probably not such a brain-damaged idea after
all, is it?
--
Y
Sorry, I missed the fact that you're not a random single user, but
Ubuntu's developer finally updating gnome-terminal. I'm grateful you're
doing it and supportive of your work!
You *don't* need to modify any user's existing settings!
You need/should modify some global files under /etc, such as pr
I (a recent vte/gnome-terminal developer) firmly disagree with the
previous comment's proposal in multiple levels, please see
https://bugzilla.gnome.org/show_bug.cgi?id=697475#c43 - #c44 for my
response. Sourcing vte.sh from .bashrc or /etc/bash.bashrc, as per the
original ticket, is the right way
It's the same issue – the whole app (Firefox) loses the focus
temporarily, whch in turn might cause a permanent focus loss of one
particular component inside Firefox. The core problem is that Firefox
itself shouldn't lose the focus at the first place.
--
You received this bug notification becau
This is not a gnome-terminal bug, but due to the design of ssh/scp.
In your .bashrc/.profile, make the echo happen only if it's output to a
terminal, e.g.
if [ -t 1 ]; then
echo whatever you wish to see on login
fi
--
You received this bug notification because you are a member of Desktop
Pack
So it is a bash or bash-completion problem (not sure which), but not
gnome-terminal.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1360005
Title:
Cyrillic symbols looks strang
guake builds on the same codebase as gnome-terminal (namely vte), so it might
not be relevant.
Could you please try with xterm, konsole, rxvt-unicode and/or pterm?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
Hi Ivan,
The feature of setting iutf8 was implemented in gnome-terminal 10 years
ago and I've been happily using it ever since. There might be a bug of
course, it would be nice to investigate further why it's not set for
you. (At this moment I have no idea how it could be wrong for you.)
Your a
Is this specific to gnome-terminal, does it work as expected in other
terminals (e.g. xterm, konsole, urvxt)?
If it's buggy in all of them then it's probably a problem with bash or
bash-completion.
--
You received this bug notification because you are a member of Desktop
Packages, which is subsc
If you're using UTF-8 character set, you need to execute "stty iutf8", so that
a "stty -a" reports back "iutf8".
For non-UTF-8, the command to be executed is "stty -iutf8" and accordingly
"stty -a" should report "-iutf8".
Gnome-terminal sets this according to the initial character set of the
ter
(to clarify: there's nowhere to _grab_ that tab for dragging)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1356433
Title:
detached tabs can not be reattached
Status in “
Yup, there's nowhere to drag that tab because the tab bar is not shown.
I don't know what a proper solution could be.
As a workaround, you can open a temporary second tab (next to the one
you wish to drag), then you can drag the desired one and finally close
the temporary one.
--
You received th
** Summary changed:
- gnome terminal swallows tabs
+ gnome terminal swallows tab characters
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1353354
Title:
gnome terminal swallo
You might want to check the progress I made in bug 1030562 porting
terminator to gtk3. It would be cool if you could step up and finish
that work, or find someone to do that.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to vte in Ubuntu.
I'm sure this behavior won't change. TAB is not a regular character, it
is a control character, just like let's say escape sequences that move
the cursor; copy-pasting doesn't include those either. It's a bonus
that gnome-terminal tries to remember when a tab was emitted, most
terminal emulators
Gnome-terminal (actually vte) has fixed this issue and this fix will
appear in Utopic. If Terminator finally updated their code to Gtk3
(which apparently nobody is working on), it would also automatically get
the fix.
In my experiences, it's very hard to get Ubuntu folks pay attention to
bugs lik
The mentioned terminals do support bracketed paste mode - but do it
incorrectly. If they didn't support it all, you wouldn't see the bug.
The *real* problem here is Terminator using a 3 year old unmaintained
version of vte (bug 1030562). The bracketed paste issue is just a
manifestation of this
*** This bug is a duplicate of bug 827380 ***
https://bugs.launchpad.net/bugs/827380
** This bug has been marked a duplicate of bug 827380
scroll bar disappears when switching tabs
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to g
Public bug reported:
When a window is maximized or made fullscreen, it is first resized to a
slightly bigger size and then made maximized or fullscreen.
This intermittent step shouldn't be there, the window should be resized
to its final size immediately.
To reproduce:
1. Start gnome-terminal,
I see. I assume you misplaced the closing parenthesis and meant this:
In normal Gtk+ applications this key combination deletes the previous word
(Ctrl+W in Bash).
Terminals and apps running inside terminals (e.g. bash) are quite a
different world from Gtk+ and it's hopeless to aim for the same
C
See https://bugzilla.gnome.org/show_bug.cgi?id=733246 . Gnome-terminal
should do whatever xterm does.
"In normal Gtk+ applications this key combination deletes the previous
word (Ctrl+W) in Bash" -- what do you mean by normal Gtk+ applications
that run bash?
Note that by default Alt+Backspace in
Indeed, this patch should be dropped.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/1340067
Title:
Drop 20_add_alt_screen_toggle_ui.patch - it does nothing with vte3 >=
0.34
Public bug reported:
Gnome-terminal can crash if a tab is dragged across windows, and later
the title of the tab is changed.
Since gnome-terminal is one single process for all your terminal windows
and tabs, upon a crash all the gnome-terminal windows disappear, easily
causing loss of precious un
Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=677329
** Bug watch added: GNOME Bug Tracker #677329
https://bugzilla.gnome.org/show_bug.cgi?id=677329
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in U
I don't know what to say now.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ibus in Ubuntu.
https://bugs.launchpad.net/bugs/1263249
Title:
[Input methods] Keyboard stops working after Ctrl+Shift+U followed by
7 alphanumeric keys
S
These characters seem to be defined double width by the Unicode
standard.
http://www.unicode.org/reports/tr11/
"ED4. East Asian Wide (W): All other characters that are always wide.
These characters occur only in the context of East Asian typography
where they are wide characters (such as the Unif
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=730157
** Bug watch added: GNOME Bug Tracker #730157
https://bugzilla.gnome.org/show_bug.cgi?id=730157
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
http
To be absolutely clear: The keys have to pressed when the focus is in an
input field, that is, where you'd normally type something. E.g. a
gnome-terminal. Pressing Ctrl+Shift+U enters a special mode where you
type a Unicode character by its hex code. If you type at most 6 digits
and then press E
Dear Christopher,
Seeing that Ubuntu developers did nothing to locate this bug other than
you guessing this might be a hardware issue – which was not an
unreasonable guess, but I already proved wrong a long time ago – I
finally took the time to locate this. I found which package causes the
proble
I've located the bug. Upstream report:
https://code.google.com/p/ibus/issues/detail?id=1715
** Package changed: xorg (Ubuntu) => ibus (Ubuntu)
** Bug watch added: IBus bugs #1715
http://code.google.com/p/ibus/issues/detail?id=1715
--
You received this bug notification because you are a memb
Gtk+ apps: Reproducible with GTK_IM_MODULE=ibus and with
GTK_IM_MODULE=xim. Not reproducible if GTK_IM_MODULE is unset before
launching a Gtk+ app [I guess Ctrl+Shift+U is handled by Gtk+ in this
case, rather than the X Input Method].
xterm: Reproducible with the default XMODIFIERS=@im=ibus, no
The bug is still present in Trusty.
I've installed a Fedora 20, and it's working correctly there. Note that
Ctrl+Shift+U works in xterm under Ubuntu, but does nothing in xterm
under Fedora. This means that probably something is done substantially
differenty in the two distros. I have a feeling
> I had to boot to a terminal instead of the usual Unity GUI.
Could you please be more specific here? What do you type or choose and
where? Is it some grub boot option? Or you choose something different
in the graphical login screen? What shall I do to try to reproduce this
bug?
--
You recei
> this default/standard location /tmp is certainly inadmissible
If it is, then I guess you're arguing that /tmp shouldn't exist at all.
It exists, it has its purpose, and g-t uses that for that purpose.
If /tmp is inadmissible, what would be a better location? The user's
home, which potentially
"man readdir" also says:
Currently, only some filesystems (among them: Btrfs, ext2, ext3, and
ext4) have full support for returning the file type in d_type. All
applications must properly handle a return of DT_UNKNOWN.
You need to do an lstat in this case, as you said
> The question is this: why does it overflow the / rather than the /home
partition?
gnome-terminal stores the scrollback content in a temporary file, opened
at the standard location which is /tmp by default, overridable with the
standard TMPDIR environment variable.
> May be "unlimited" should be
This should be fixed in vte-0.34.9 (shipped by Trusty).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/878739
Title:
terminal scrolls up when resized taller
Status in “gnome-t
This is perhaps the same as
https://bugzilla.gnome.org/show_bug.cgi?id=730220 (patch available
there).
** Bug watch added: GNOME Bug Tracker #730220
https://bugzilla.gnome.org/show_bug.cgi?id=730220
--
You received this bug notification because you are a member of Desktop
Packages, which is s
Bumped the version in the title – now that 3.12 is out, it wouldn't make
much sense to update to 3.8 or 3.10.
There's at least one more reason to update to at least 3.12, namely the
"rewrap on resize" UI setting, see bug 1319864.
** Summary changed:
- Update GNOME Terminal to 3.10.2
+ Update GNO
Public bug reported:
Currently Utopic has vte-0.36 (from Gnome 3.12) and gnome-terminal-3.6
(from Gnome 3.6).
Should you decide not to upgrade gnome-terminal (which would be a really
bad idea because these two components are so strongly related – bug
1261619), please at least backport the rewrap
Could you provide concrete escape sequences (like an echo command, or a
short text file to cat)?
I can't figure out how to test this. CSI is traditionally ESC + [. This is used
e.g. to change the foreground color:
echo -e '\x1B[31mred\x1B[0m'
The CSI you're referring to seems to be an alternate
My 2 cents:
Shift+PageUp, Shift+PageDown have historically been the shortcuts for
scrolling, hence application don't expect these keypresses to get
delivered.
Shift+Up, Shift+Down, however, generate escape sequences that are useful
for applications (e.g. select text in editor), it would be bad if
Created attachment 98637
Works for me, probably not the proper solution though
Here's a workaround patch that I've been using successfully for a while.
Upon loading a new keymap, Xkb does something with the locks. I'm not
sure what it is and why it would do so. I just commented out that part
and
A few people confirmed that their system always sends keycode 87 for
keypad 1/End, independently of NumLock's state. They don't face this
bug.
I've connected an external keyboard to my laptop and that one also
always sends 87, as opposed to the built-in one.
Really looks like we're facing some br
401 - 500 of 553 matches
Mail list logo
