This test case does show something (the tokens are being parsed properly, but
the
comparison is failing).
--
mawk text-match count inconsistency
https://bugs.launchpad.net/bugs/485574
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
On Fri, 2 Apr 2010, Gavin McCullagh wrote:
Strangely, today I upgraded to the latest lucid packages and now my
uxterm is white as well.
http://invisible-island.net/xterm/xterm.log.html#xterm_256
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
xterm background
On Wed, 3 Mar 2010, Dominic Evans wrote:
@dickey so what is your suggested fix for the usability issue? :-)
It should be fixed in the qemu package, rather than gnome-terminal
(by making it work with different screensizes).
--
Thomas E. Dickey
http://invisible-island.net
On Wed, 3 Mar 2010, Anthony Liguori wrote:
You can use an ANSI sequence to resize a terminal. The following works
in gnome-terminal:
technically that's not ANSI (other than the form).
It's one of the dtterm (Sun) sequences that I implemented for xterm.
The security people don't much like it.
On Wed, 3 Mar 2010, Anthony Liguori wrote:
You can use an ANSI sequence to resize a terminal. The following works
in gnome-terminal:
technically that's not ANSI (other than the form).
It's one of the dtterm (Sun) sequences that I implemented for xterm.
The security people don't much like it.
The only (upstream) thing that comes to mind is to make the include-structure
of the uxterm
app-defaults files consistent with xterm. Doing that will make this user's
windows both have
a white background. I'm doing that for patch #256.
I did notice that on my Debian/stable (sarge), that the
On Wed, 3 Mar 2010, Dominic Evans wrote:
@dickey so what is your suggested fix for the usability issue? :-)
It should be fixed in the qemu package, rather than gnome-terminal
(by making it work with different screensizes).
--
Thomas E. Dickey
http://invisible-island.net
The report has several problems. I'll list a few of them.
vte would like to emulate xterm (it's incomplete).
xterm emulates vt100, vt220, etc. Those are all 24x80.
PC's have 25x80. But their emulation of vt100 is weak,
with well-known differences.
Terminator isn't relevant to the topic.
The report has several problems. I'll list a few of them.
vte would like to emulate xterm (it's incomplete).
xterm emulates vt100, vt220, etc. Those are all 24x80.
PC's have 25x80. But their emulation of vt100 is weak,
with well-known differences.
Terminator isn't relevant to the topic.
On Wed, 24 Feb 2010, Dominik George wrote:
Public bug reported:
This appears to be a duplicate of 526893.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
xterm wrongly handles Unicode on the prompt when printing text
https://bugs.launchpad.net/bugs/526894
You
On Wed, 24 Feb 2010, Dominik George wrote:
Public bug reported:
Binary package hint: xterm
xterm misinterpretes some characters and writes junk text to the
terminal under the followign conditions:
1. The prompt contains special charachters, in this test case german umlauts
2. The text
*** This bug is a duplicate of bug 526893 ***
https://bugs.launchpad.net/bugs/526893
** This bug has been marked a duplicate of bug 526893
xterm wrongly handles Unicode on the prompt when printing text
--
xterm wrongly handles Unicode on the prompt when printing text
On Wed, 24 Feb 2010, Dominik George wrote:
zsh is the login shell, but this is about Bash (running from zsh or
native does not matter). The bug is reproducible across multiple
hosts, users, environments.
It is not related to the shell itself. The bug can be reproduced in
Bash, Dash and Csh.
I've never come across any useful documentation from the GNOME project.
Just stuff that is targeted at nontechnical end-users.
However, the simplest fix would be setting gnome-terminal's TERM variable
to gnome, and handling the inevitable release-to-release nits with fixes
in the terminal
** Changed in: xterm (Ubuntu)
Status: New = Invalid
--
xterm word wrap bug
https://bugs.launchpad.net/bugs/505526
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
This is the same issue as described in my faq:
http://invisible-island.net/xterm/xterm.faq.html#grep_colors
(not a bug in xterm)
** Changed in: xterm (Ubuntu)
Status: Triaged = Invalid
--
xterm does not handle tab character in last column correctly
On Wed, 20 Jan 2010, Imre Péntek wrote:
May I ask why it is changed to invalid? btw I can still reproduce with
xterm under ubuntu.
It's not a bug, but the way vt100's would work. That seems the most
appropriate status.
--
Thomas E. Dickey
http://invisible-island.net
This was fixed upstream in
http://invisible-island.net/diffstat/CHANGES
31-Aug-2009
diffstat 1.49
add special case for no-newline message from some diff's (Ubuntu
#269895).
--
diffstat: bogus parsing of diffs that contain \ No newline at end of file
diffstat already has a -w option which can be used to achieve the same result.
Making it respond to the environment variable would change existing uses.
man diffstat
-w number
specify the maximum width of the histogram. The histogram will
never be shorter
This was fixed upstream in
20091114
+ limit hashing for termcap-names to 2-characters (Ubuntu #481740).
--
termcap emulation broken
https://bugs.launchpad.net/bugs/481740
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
The fixes mentioned are in 9.7x (which currently is in Lucid).
I made one additional fix which may be relevant for 9.7y
(the current version is 9.7z, I have unrelated changes for 9.7za)
--
xvile 9.7 hangs on amd64 (9.6 was ok)
https://bugs.launchpad.net/bugs/481253
You received this bug
This was fixed upstream in
20091031
+ change initialization of hidden flag for soft-keys from true to
false, broken in 20090704 merging (Ubuntu #464274).
--
Karmic libncurses5.7 problems
https://bugs.launchpad.net/bugs/464274
You received this bug notification because you are
Upstream has these changes, last updated in
20091003
patch by Benjamin C W Sittler:
+ add linux-16color
--
init_color (and the initc capability) for terminal type linux fails when
red, green and/or blue is set to the maximum value (1000)
https://bugs.launchpad.net/bugs/438413
On Wed, 20 Jan 2010, Steve Langasek wrote:
The request was for diffstat to honor the existing $COLUMNS env
variable. Commandline options are orthogonal to this.
If you have some advice on how to not impact existing usage, you should
comment on that in the bug report.
--
Thomas E. Dickey
This was fixed a while ago:
2007/09/3
+ fix editbox widget to handle zero-length files (report by Joe
McDonagh).
--
dialog --editbox crashed with 'Segmentation fault (core dumped)'
https://bugs.launchpad.net/bugs/230376
You received this bug notification because you are a
On Mon, 11 Jan 2010, Imre Péntek wrote:
reply to comment #7: I've encountered it in xterm. Check my screenshot.
This bug is reproducibly present in xterm(243).
See
http://invisible-island.net/xterm/xterm.faq.html#grep_colors
(since the bug is most often reported for grep)
fwiw, I
Package: xterm 243-1ubuntu1
That's from last spring. #254 is current.
--
xterm word wrap bug
https://bugs.launchpad.net/bugs/505526
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
do you have a typescript or other text-file which can be used to replay the case
you're reporting?
--
xterm word wrap bug
https://bugs.launchpad.net/bugs/505526
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
The behavior you're seeing is because of the \E[K (clear-to-end-of-line) which
is being sent at the
end of the line. Attaching a readable form of the part of the script we're
talking about.
** Attachment added: readable form of script-detail
http://launchpadlibrarian.net/37683119/foo.map
The clear-to-end-of-line control arrives when the last column of the
screen is filled; the cursor is waiting on that position. The control
clears that column; subsequent text is written from that point.
The difference that you expect happens to be a bug in gnome-terminal.
It works properly in
It's also the same bug in konsole (the developers copy from each other
of course).
The bug assumes that after writing to the 80th column that the next control will
affect the next line. It does not (per vt100 compatibility). The only thing
that
takes you to the next line is by writing
On Sat, 9 Jan 2010, Bryce Harrington wrote:
On Sat, Jan 09, 2010 at 02:09:14AM -, Thomas Dickey wrote:
On Sat, 9 Jan 2010, Bryce Harrington wrote:
Well, I'm out of clue. I don't see where we have anything different
from debian for the Xresources for this. I don't have a ~/.Xdefaults
On Fri, 8 Jan 2010, Bryce Harrington wrote:
From the last comment, sounds like this is a wontfix issue. Certainly
not something we'd patch ourselves in ubuntu, and upstream already knows
about the issue, so no need to have this bug report open any further.
It would only be fixed in the X
On Fri, 8 Jan 2010, Bryce Harrington wrote:
Sorry, this testing was on Karmic. I'll check on Lucid in a moment.
The fonts are probably much the same...
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
xterm renders some unicode characters incorrectly when using
On Fri, 8 Jan 2010, Bryce Harrington wrote:
Actually, fixing the manpage is probably within scope. The next xterm
upload will fix this.
It's been documented in the xterm manpage since patch #250.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
xterm ignores
On Fri, 8 Jan 2010, Bryce Harrington wrote:
Hmm, not sure how to go about fixing this. I can confirm the behavior.
We're not doing anything in the xterm packaging to make it white rather
than black in Ubuntu. Maybe something elsewhere in the system is
causing it to show up white but I can't
Julian's comment #15 seems to be the best clue (though why it would
be set for uxterm and not xterm, I don't know).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
xterm background colour used to be black, now white
https://bugs.launchpad.net/bugs/421261
You
On Sat, 9 Jan 2010, Bryce Harrington wrote:
Well, I'm out of clue. I don't see where we have anything different
from debian for the Xresources for this. I don't have a ~/.Xdefaults,
and the x11-common resource file is the same as from debian.
If I had something like that where I could test
This should be either closed (not a bug in xterm),
or reassigned to KDE (in case someone changed
the default resources for xterm).
--
xterm title won't change with kde (xttitle, xtermset, xtermcontrol all broken)
https://bugs.launchpad.net/bugs/495733
You received this bug notification because
On Thu, 24 Dec 2009, Alice Kærast wrote:
Would it be an idea to include the libtinfo.so.5 symlink in libncurses5?
Is there any reason it would cause any problems?
ncurses' configure script generates that link - but only if it's
configured to generate the separate library. As I understand it,
The behavior in question is a gawk extension (non-standard),
and has been there a while, as documented in this rather old
link:
http://www.delorie.com/gnu/docs/gawk/gawk_214.html
--
hex print in mawk does not work on ubuntu 64bit
https://bugs.launchpad.net/bugs/321890
You received this bug
On Sat, 12 Dec 2009, Paul Szabo wrote:
xterm can't change it's title any more. ...
... look at the control-right-mouse entry for Enable Title Ops ...
Testing my own karmic machine: the xterm default Allow Title Ops is
ticked, Allow Window Ops is not ticked. Apparently regardless of
On Sat, 12 Dec 2009, Paul Szabo wrote:
Dear Thomas,
The problem is not with the meanings or descriptions of AllowTitleOps
(though a warning that setting AllowWindowOps is insecure is missing).
The problem is that
perl -e 'print \e\]0;;bad-command;\a\e\[21t'
should set the title (then
I don't see xterm's version number anywhere, and don't see a pointer
to the package definition for xterm, to see what changes may have been
made from the upstream source.
--
xterm title won't change with kde (xttitle, xtermset, xtermcontrol all broken)
https://bugs.launchpad.net/bugs/495733
You
If it's the same executable (and unless KDE now has some feature for disabling
changes
to the titlebar), then it's probably a difference in X resource settings due
to starting
xrdb with a slightly different set of files.
If it's X resources, then you should be able to see the Allow Title Ops
On Sat, 12 Dec 2009, David Sharnoff wrote:
Sorry, I'm using 243-1ubuntu1 -- the current version in Karmic.
thanks (I don't have Ubuntu, so I need information to fill in between
upstream source and the package details).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
It would be greyed out if Allow SendEvents (control/left/menu) is
enabled (in turn, that could be a resource-difference between GNOME/KDE).
man xterm
allowSendEvents (class AllowSendEvents)
Specifies whether or not synthetic key and button events (gen-
erated
On Sat, 12 Dec 2009, David Sharnoff wrote:
xterm can't change it's title any more. Did this fixing this bug
There is a resource setting that can disable it - perhaps someone set
that. (which version of xterm are we discussing?)
break this important feature? The screen program is one
see
http://invisible-island.net/xterm/xterm.log.html#xterm_210
man xterm (resource settings):
utf8Title (class Utf8Title)
Applications can set xterm's title by writing a control
sequence. Normally this control sequence follows the VT220
Unless access_log is encoded in UTF-8 (a possibility), mawk and gawk should
give the same result for that pattern.
--
mawk text-match count inconsistency
https://bugs.launchpad.net/bugs/485574
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
On Thu, 12 Nov 2009, Joachim Schimpf wrote:
Public bug reported:
Binary package hint: xvile
I upgraded from jaunty to karmic, which apparently involved xvile 9.6m-1
being upgraded to xvile 9.7s-1.
Start xvile on any file, then type dd, and it hangs and needs to be
killed.
I went back
On Fri, 30 Oct 2009, Michael Selig wrote:
Public bug reported:
Binary package hint: libncurses5
Just upgraded to Karmic, and some legacy ncurses programs broke, using
libncurses5 ver 5.7+20090303-2ubuntu2.
Replacing /lib/libncurses.5.7.so with the version from Jaunty fixes the
problems.
On Fri, 30 Oct 2009, Thomas Dickey wrote:
On Fri, 30 Oct 2009, Michael Selig wrote:
Public bug reported:
Binary package hint: libncurses5
Just upgraded to Karmic, and some legacy ncurses programs broke, using
libncurses5 ver 5.7+20090303-2ubuntu2.
Replacing /lib/libncurses.5.7.so
On Fri, 30 Oct 2009, Thomas Dickey wrote:
On Fri, 30 Oct 2009, Thomas Dickey wrote:
On Fri, 30 Oct 2009, Michael Selig wrote:
Public bug reported:
Binary package hint: libncurses5
Just upgraded to Karmic, and some legacy ncurses programs broke, using
libncurses5 ver 5.7+20090303
On Fri, 30 Oct 2009, Thomas Dickey wrote:
On Fri, 30 Oct 2009, Thomas Dickey wrote:
It was working in 20090803, but re-broken in
20090927
+ completed integrating sp-funcs by Juergen Pfeifer in ncurses
library (some work remains for forms library).
...runtime size
On Wed, 28 Oct 2009, Micah Cowan wrote:
Kamus, I see absolutely nothing in Thomas Dickey's comments that even
remotely hint at a violation of the Code of Conduct, so maybe you could
consider dialing your sensitivity down a bit?
Thomas, I think the (previous) Incomplete status was due to the
Actually, there was adequate information to discuss the report.
(looks like someone's mis-triaging reports).
--
Screen missing terminfo entries for 'xterm'
https://bugs.launchpad.net/bugs/190852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
On Wed, 28 Oct 2009, Kamus wrote:
@Thomas, please what do you mean with mis-triaging? I closed this report
because have a long time here without activity and since nobody has
confirmed this problem I change to invalid until other people can check
if this issue is still occurring. Please
That sounds correct (it's not due to a change in xterm's sources, but in how
the system is
configured).
--
xterm background colour used to be black, now white
https://bugs.launchpad.net/bugs/421261
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Is this with lynx 2.8.1dev.1, or some other version?
--
lynx can't find issuer of some https sites and can't connect with -dump
https://bugs.launchpad.net/bugs/293708
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
If the Debian packager were responding, it would be about a week.
However, he's ignored most of my bug reports (aside from the one
about incorrect license).
Look here - I've marked fixed-upstream on the ones that I believe are
done...
http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mawk
--
Other than documenting it in the manpage as a limitation of the X libraries,
there's no fix to be made, noting that it's already documented in the changelog
from 5 years ago.
--
xterm ignores VT100 widget resources color16 through color255
https://bugs.launchpad.net/bugs/438850
You received this
Not a bug in xterm, but a limitation of the X libraries.
http://invisible-island.net/xterm/xterm.log.html#xterm_188
Patch #188 - 2004/5/12 - XFree86 4.4.99.6
modify initialization of 256- and 88-colors so that colors beyond 16 are
normally not X resources. This works around a hard-coded limit in
On Mon, 28 Sep 2009, juhtolv wrote:
Public bug reported:
Binary package hint: xterm
Whenever I want to write Japanese language, I use input method called
Anthy, via scim-bridge. No matter how much I hit Ctrl-Space, Alt-Space
or Shift-Space, SCIM-toolbar do not appear at all, when mouse
The previous comment stated that it was assumed to be fixed in #235.
This comment repeats the original report against #229.
(The current version is #248).
--
xterm segfaults when run via panel launcher
https://bugs.launchpad.net/bugs/258089
You received this bug notification because you are a
No - since there's no fix released for 8.04 Hardy. But it's certainly not a
New, since there's
previous history which tends to make it Confirmed. (There's no progress on
it in this release).
--
xterm segfaults when run via panel launcher
https://bugs.launchpad.net/bugs/258089
You received
On Tue, 8 Sep 2009, Martin Pitt wrote:
Since it's past feature freeze now, does that new upstream version have
any intrusive changes/new features? Do we need it in karmic to fix
urgent bugs?
What's the previous patch-date?
--
Thomas E. Dickey
http://invisible-island.net
On Tue, 8 Sep 2009, Martin Pitt wrote:
Since it's past feature freeze now, does that new upstream version have
any intrusive changes/new features? Do we need it in karmic to fix
urgent bugs?
Reading this bug report, it seems that 20090607 is where karmic is.
20090613 has a build-fix.
There
On Tue, 1 Sep 2009, Julien Cristau wrote:
On Sat, Aug 29, 2009 at 23:28:51 -, Gavin McCullagh wrote:
gavi...@teenie:~$ xrdb -query
Xcursor.size: 18
Xcursor.theme: Human
Xcursor.theme_core: true
Xft.antialias: 1
Xft.dpi:96
Xft.hinting:1
Xft.hintstyle: hintslight
On Sun, 30 Aug 2009, Gavin McCullagh wrote:
UXTerm is an interesting one to check. I switched over to it and it
gets the black background as expected. I'm not starting to wonder if
that's what I might have been using before. Maybe xterm has always been
white.
X's default background for
On Sun, 30 Aug 2009, Gavin McCullagh wrote:
X's default background for xterm is white; Debian sets it to black.
Redhat and some others leave it as white. (I generally prefer black,
since color contrasts work better against black).
I prefer black too. I guess the issue here is, what colour
On Sat, 29 Aug 2009, Gavin McCullagh wrote:
Public bug reported:
Binary package hint: xterm
Since upgrading my Acer Aspire One to Karmic, my xterms always have a
white background.
Looking at /etc/X11/app-defaults/XTerm-color, it appears it should be
black:
! Set the default text
On Sat, 29 Aug 2009, Gavin McCullagh wrote:
I downgraded and it made no difference, the xterms are still white:
A packager may have made changes to the X resources which would show up in
the output from xrdb -query.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
On Sat, 29 Aug 2009, Gavin McCullagh wrote:
gavi...@teenie:~$ xrdb -query
Xcursor.size: 18
Xcursor.theme: Human
Xcursor.theme_core: true
Xft.antialias: 1
Xft.dpi:96
Xft.hinting:1
Xft.hintstyle: hintslight
Xft.lcdfilter: lcddefault
Xft.rgba: rgb
Not sure I
This isn't the same case as Debian #231609
(I'll make a fix in lynx 2.8.8dev.1).
--
lynx can't find issuer of some https sites and can't connect with -dump
https://bugs.launchpad.net/bugs/293708
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
On Tue, 4 Aug 2009, Imre Péntek wrote:
Well, I reported an Ubuntu bug:
Where did you find the bug?:
Distribution: Ubuntu
package xterm
I maintain xterm upstream, and check bugs in various packages,
since as a rule, packagers do not bother to notify upstream.
--
Thomas E. Dickey
On Mon, 3 Aug 2009, Imre Péntek wrote:
Public bug reported:
by default XTerm*utf8Title is set to false, however the byte sequences
that will change the title bar are actually sent out in utf8, so I
suggest to hard-wire this setting to true. Check the attached screenshot
also. Thank you.
For the record, the vtansi.htm page (originally by Robert M. Free - though I
don't see his
name on that copy) contains several technical errors - citing it in a bug report
is a nonstarter.
In this instance, it happens to say something which is relevant, but still not
completely true. In
On Mon, 3 Aug 2009, Imre Péntek wrote:
Hello, the Ubuntu system generally is utf8 based. That 'Zenék' directory was
created by the installer (when I created my user account), and it really
means Music. So changing the setting I suggest you to change would only mean
that XTerm wouldn't be
Regarding comment #11 and following - xterm is configurable.
I suggest that he read the documentation and customize it.
(This is not even a wishlist item, since it's a problem with
the user's understanding of the program).
--
Jaunty: CTRL-LEFT and CTRL-RIGHT do not work in zsh
The xterm source package provides suitable icons,
which the Ubuntu packager could install.
--
Jaunty: no icon in the title menu of xterm
https://bugs.launchpad.net/bugs/364474
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
From the description, it sounds as if the problem is in bash.
--
Cursor in terminal behaves badly with special characters present
https://bugs.launchpad.net/bugs/378668
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Whether a character shows up as a box or not depends on whether the font
contains the given glyph. xterm has separate normal/bold font settings,
and (though it can be configured to use overstriking rather than a bold font)
will choose to use the bold font for bold text.
By the way, on my
On Thu, 30 Jul 2009, Bernhard wrote:
@Thomas: I have since configured my terminal via shell settings. The
desired behaviour should be default though, especially for out-of-the-
box Ubuntu.
Doing that would break existing applications (those that use
the terminal description from ncurses and
Near the end of this section, there's a table showing the codes sent by
xterm for different modifiers:
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#PC-Style Function Keys
Back to the original report -
A 3 is sent for an alt key, a 5 for a control key.
That's not changed in upstream
One problem with the patch is that it's hardcoded, doesn't
use the locale information. I've written an alternate form which
is in the 20090727 version of mawk at
http://invisible-island.net/mawk/
--
Mawk does not support Posix character classes in expressions
It doesn't appear to be related to 64-bits. The values correspond
to the first character of the parameters. Incidentally, mawk's
behavior matches awk's (perhaps gawk's behavior is an extension).
--
hex print in mawk does not work on ubuntu 64bit
https://bugs.launchpad.net/bugs/321890
You
no - as Aharon Robbins pointed out (and X/Open):
substr(s, m[, n ])
Return the at most n-character substring of s that begins at position m,
numbering from 1. If n is omitted, or if n specifies more characters than are
left in the string, the length of the substring shall be limited by the
mawk does care - but it's not accepting a explicit null-character.
I've added a fix for the next snapshot of mawk.
--
RS is readonly
https://bugs.launchpad.net/bugs/400409
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
On Sun, 10 May 2009, SimonX200 wrote:
The problem is solved by removing the s-flags from xterm. Why the hack
does a user application like xterm s-flags in the first place?
xterm could be installed (and configured...) for systems that use setuid,
setgid. setuid is rarely used now (was mainly
At some point gnome-terminal changed its strings for modified function-keys. I
documented those
in terminfo.src for ncurses 5.7 (they don't match xterm, of course).
--
[feisty] function keys don't work in gnome-terminal
https://bugs.launchpad.net/bugs/96676
You received this bug notification
The entrypoints for libinfo are part of ncurses (whether the ncurses library is
installed as the
two files is a decision made by the packager, and does not affect the ability
of applications
to use those entrypoints). Any build script which looks explicitly for libtinfo
without first trying in
It's expected behavior - in the 80 case, stdout is redirected,
so it's no longer a terminal. When this happens, the terminal
initialization falls back to the terminfo settings.
--
'tput cols' give strange results
https://bugs.launchpad.net/bugs/187866
You received this bug notification because
On Tue, 9 Sep 2008, Julien Cristau wrote:
On Fri, Aug 29, 2008 at 16:46:40 -, Julien Cristau wrote:
On Fri, Aug 29, 2008 at 15:47:00 -, Thomas Dickey wrote:
On Fri, 29 Aug 2008, Wouter van Heyst wrote:
According to the changelog for version 236 of xterm, this bug should be
fixed
On Fri, 29 Aug 2008, Wouter van Heyst wrote:
According to the changelog for version 236 of xterm, this bug should be
fixed in that version. Doesn't seem to be in Debian yet unfortunately.
yes (I don't recall seeing it updated yet in Debian - checked the
package page and it's not there).
--
On Fri, 29 Aug 2008, Julien Cristau wrote:
On Fri, Aug 29, 2008 at 15:47:00 -, Thomas Dickey wrote:
On Fri, 29 Aug 2008, Wouter van Heyst wrote:
According to the changelog for version 236 of xterm, this bug should be
fixed in that version. Doesn't seem to be in Debian yet unfortunately
On Fri, 25 Jul 2008, Izzy wrote:
Just wanted to report that the problem disappeared for me after a dist-
upgrade to Hardy (via Gutsy, of course). So maybe the bug is silently
solved?
No bug here - it's either a fix in gnome-terminal, or the application
using it, e.g., vim.
--
[feisty]
On Tue, 23 Oct 2007, Alexey Borzenkov wrote:
Thomas, I don't seem to understand you. I just grabbed and compiled
terminfo.src you gave and while it helped with xterm (except that it's
just like with my previous attempts, Shift+F2 starts a new file in mc
instead of Shift+F4) it didn't work in
On Tue, 23 Oct 2007, Alexey Borzenkov wrote:
Also I just found that xterm sends slightly different codes for
Shift+F1...F4, so this myxterm.ti is also for xterm:
xterm|X11 terminal emulator with correct kf-sequences,
This would be for xterm with modifyFunctionKeys:0
I made a list in xterm
On Tue, 23 Oct 2007, Alexey Borzenkov wrote:
I'd like to second steviant's request. For a long time this bug forced
me to use konsole instead of gnome-terminal, just for ability to press
Shift+F4. Unfortunately with konsole Shift+Left/Shift+Right don't work
(which work under gnome-terminal),
201 - 300 of 313 matches
Mail list logo
