Subject: display problem with xterm + screen and bold characters
Date: Thu, 21 Dec 2006 16:07:22 +0100
Package: xterm
Version: 223-1
Severity: important
Not sure this is a bug in xterm, but the following problems don't occur
with rxvt.
Xterm doesn't behave correctly when there are bold characters in screen,
when using TERM=xterm-debian or TERM=xterm-xfree86, but no problem when
using TERM=xterm. It seems to be a regression (as I didn't notice this
problem before), but I'm not sure.
For instance, ssh to a Debian/stable machine, start "screen", with the
zsh shell. Set the following prompts:
PS1="%{`tput bold`%}%% %{`tput sgr0`%}"
RPS1="abc"
Hit [Enter] a few times and type "true", and hit [Enter] again a few
times, to have:
% abc
% abc
% true abc
% abc
% abc
Detach the screen session and reattach it. I get:
% bc
% bc
% rue abc
% bc
% bc
Same problem after a ssh to Mac OS X, but only with TERM=xterm-debian.
Note: like Debian/stable, Mac OS X uses ncurses 5.4.
This problem makes xterm quite unusable with screen.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686-bigmem
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Versions of packages xterm depends on:
ii libc6 2.3.6.ds1-9 GNU C Library: Shared libraries
ii libfontconfig1 2.4.2-1 generic font configuration library
ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library
ii libncurses5 5.5-5 Shared libraries for terminal hand
ii libsm6 1:1.0.1-3 X11 Session Management library
ii libx11-6 2:1.0.3-4 X11 client-side library
ii libxaw7 1:1.0.2-4 X11 Athena Widget library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxft2 2.1.8.2-8 FreeType-based font drawing librar
ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library
ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library
ii xbitmaps 1.0.1-2 Base X bitmaps
Versions of packages xterm recommends:
ii xutils 1:7.1.ds.3-1 X Window System utility programs
-- no debconf information
On Thu, Dec 21, 2006 at 07:00:15PM +0100, Vincent Lefevre wrote:
> Package: xterm
> Version: 223-1
> Severity: important
>
> Not sure this is a bug in xterm, but the following problems don't occur
> with rxvt.
This sounds like (see http://invisible-island.net/ncurses/NEWS.gz)
20040710
+ modify logic in tgetent() which adjusts the termcap "me" string
to work with ISO-2022 string used in xterm-new (cf: 20010908).
also note the followups for sgr0 in that file.
> Xterm doesn't behave correctly when there are bold characters in screen,
> when using TERM=xterm-debian or TERM=xterm-xfree86, but no problem when
> using TERM=xterm. It seems to be a regression (as I didn't notice this
> problem before), but I'm not sure.
rxvt behaves different since it has different error detection for the
control sequences (this is not saying that it's behaving correctly ;-).
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
On Thu, Dec 21, 2006 at 07:20:40PM -0500, Thomas Dickey wrote:
> On Thu, Dec 21, 2006 at 07:00:15PM +0100, Vincent Lefevre wrote:
> > Package: xterm
> > Version: 223-1
> > Severity: important
> >
> > Not sure this is a bug in xterm, but the following problems don't occur
> > with rxvt.
>
> This sounds like (see http://invisible-island.net/ncurses/NEWS.gz)
>
> 20040710
> + modify logic in tgetent() which adjusts the termcap "me" string
> to work with ISO-2022 string used in xterm-new (cf: 20010908).
>
> also note the followups for sgr0 in that file.
If there's no new information here, there's nothing to fix (the fixes are
in ncurses 5.5, and there's no way other than by breaking the related
fixes for luit to make ncurses 5.4 work as you want).
Also note (as you already did) that there's a known workaround (use the
terminal description that uses the single-character ^N and ^O rather than
\E(B, etc.
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
On Fri, Dec 22, 2006 at 03:04:53PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 06:27:26 -0500, Thomas Dickey wrote:
> > If there's no new information here, there's nothing to fix (the
> > fixes are in ncurses 5.5, and there's no way other than by breaking
> > the related fixes for luit to make ncurses 5.4 work as you want).
>
> The problem is that Debian/stable still provides ncurses 5.4.
> So, there must be a fix for Debian.
>
> Also, concerning Mac OS X, though I have ncurses 5.5 installed (via
> MacPorts), the problem is that several programs are written for curses
> (instead of ncurses), and ncurses 5.5 doesn't provide compatibility
> links. I've already reported a few bugs for MacPorts and written a few
> fixes, e.g.
>
> http://trac.macosforge.org/projects/macports/ticket/11157
I've seen some confusing comments about Mac OS X "curses" versus "ncurses",
but am left with the impression that it's still ncurses (in a different
directory, etc, but still the same code).
Even still, 5.4 is nearly three years old, and there's a year-old 5.5
release which Mac OS X should be using.
> > Also note (as you already did) that there's a known workaround (use the
> > terminal description that uses the single-character ^N and ^O rather than
> > \E(B, etc.
>
> But this time, these characters break "less"!
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399848
That's odd, since "less" has always been a termcap application.
Perhaps it's a regression, e.g., changes by someone using a terminfo
underneath.
> And I don't know if this is related to changes in ncurses:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403612
Since "less" uses only the termcap interface, it would only be
related to changes in that one area.
Essentially the changes to sgr0 were made necessary by a long-ago equating
of terminfo "sgr0" and termcap "me". They're not identical:
a) several years ago, I made changes to allow termcap applications
to assume that "me" (sgr0) did not reset line-drawing since
termcap applications generally did not support that feature.
b) that change only worked for single-bytes - and the change
I noted yesterday was a fix for that. The fix was needed to
allow using multi-byte \E(B, etc., to support luit.
c) further changes past that point were refinement (improving
the interaction with applications that had not been fixed
with (b)).
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
Subject: Re: Bug#404079: display problem with xterm + screen and bold
characters
Date: Fri, 22 Dec 2006 19:56:55 +0100
On 2006-12-22 10:07:25 -0500, Thomas Dickey wrote:
> I've seen some confusing comments about Mac OS X "curses" versus "ncurses",
> but am left with the impression that it's still ncurses (in a different
> directory, etc, but still the same code).
Mac OS X 10.4.x uses ncurses, even with the curses API.
> Even still, 5.4 is nearly three years old, and there's a year-old
> 5.5 release which Mac OS X should be using.
We could say the same thing for the current Debian/stable.
Now I just hope that Mac OS X 10.5 will use ncurses 5.5.
> > > Also note (as you already did) that there's a known workaround
> > > (use the terminal description that uses the single-character ^N
> > > and ^O rather than \E(B, etc.
> >
> > But this time, these characters break "less"!
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399848
>
> That's odd, since "less" has always been a termcap application.
> Perhaps it's a regression, e.g., changes by someone using a terminfo
> underneath.
According to ldd, less uses libncurses (not libtermcap).
The less man page says:
Less uses termcap (or terminfo on some systems) [...]
/usr/share/doc/less/README.Debian doesn't say anything.
> > And I don't know if this is related to changes in ncurses:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403612
>
> Since "less" uses only the termcap interface, it would only be
> related to changes in that one area.
Changing the terminfo database (e.g. with infocmp to retrieve some
data + tic to install them, possibly modified, in my $HOME directory)
changed the behavior.
--
Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Fri, Dec 22, 2006 at 07:56:55PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 10:07:25 -0500, Thomas Dickey wrote:
> > I've seen some confusing comments about Mac OS X "curses" versus "ncurses",
> > but am left with the impression that it's still ncurses (in a different
> > directory, etc, but still the same code).
>
> Mac OS X 10.4.x uses ncurses, even with the curses API.
>
> > Even still, 5.4 is nearly three years old, and there's a year-old
> > 5.5 release which Mac OS X should be using.
>
> We could say the same thing for the current Debian/stable.
> Now I just hope that Mac OS X 10.5 will use ncurses 5.5.
Or the more straightforward solution - I'm running ncurses 5.6 on all
platforms. Aside from being a nuisance, there's no problem updating
just the libraries.
Given the glacial progress of the *BSD's in updating packages,
it's not unlikely that they'll remain 2-3 years behind indefinitely.
> > > > Also note (as you already did) that there's a known workaround
> > > > (use the terminal description that uses the single-character ^N
> > > > and ^O rather than \E(B, etc.
> > >
> > > But this time, these characters break "less"!
...
> Changing the terminfo database (e.g. with infocmp to retrieve some
> data + tic to install them, possibly modified, in my $HOME directory)
> changed the behavior.
hmm - since you said "less" does not recognize ^N/^O, I'm assuming you
meant that you changed sgr0 to \E[m, which works for termcap, but not
for applications that use line-drawing (without of course hardcoding
things).
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
Subject: Re: Bug#404079: display problem with xterm + screen and bold
characters
Date: Fri, 22 Dec 2006 22:17:06 +0100
On 2006-12-22 15:42:45 -0500, Thomas Dickey wrote:
> Or the more straightforward solution - I'm running ncurses 5.6 on all
> platforms. Aside from being a nuisance, there's no problem updating
> just the libraries.
I prefer to have them (libraries compiled by the user) in a separate
directory. Applications that use ncurses should also be recompiled.
But in addition to my Mac OS X machine, I have lots of accounts,
so that this is annoying.
> Given the glacial progress of the *BSD's in updating packages,
> it's not unlikely that they'll remain 2-3 years behind indefinitely.
For several things, Mac OS X is more up-to-date than Debian/stable.
> hmm - since you said "less" does not recognize ^N/^O, I'm assuming you
> meant that you changed sgr0 to \E[m,
I think I'll change that back to \E[m because of this problem.
> which works for termcap, but not for applications that use
> line-drawing (without of course hardcoding things).
Well the applications that use line-drawing seem to use rmacs
explicitly (I think they should all do that for a few years
for compatibility). Then having the rmacs escape sequence in
sgr0 is useless for these applications, isn't it?
I also have the following in my precmd() in zsh:
[[ -n $zsh410 && -n $TTY && -n $terminfo ]] &&
print -n "$terminfo[rmacs]$terminfo[sgr0]" > $TTY
--
Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Fri, Dec 22, 2006 at 10:17:06PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 15:42:45 -0500, Thomas Dickey wrote:
> > Or the more straightforward solution - I'm running ncurses 5.6 on all
> > platforms. Aside from being a nuisance, there's no problem updating
> > just the libraries.
>
> I prefer to have them (libraries compiled by the user) in a separate
> directory. Applications that use ncurses should also be recompiled.
I suppose so. In 5.6 I've revisited rpath linkage, and made it work
well enough for that, so I won't be recompiling ncurses applications
where they've been linked dynamically any more. (Though checking, no
one's provided any information on rpath in Mac OS X - working from manpages
alone is futile).
> But in addition to my Mac OS X machine, I have lots of accounts,
> so that this is annoying.
I did mention that it was a nuisance...
> > Given the glacial progress of the *BSD's in updating packages,
> > it's not unlikely that they'll remain 2-3 years behind indefinitely.
>
> For several things, Mac OS X is more up-to-date than Debian/stable.
I suppose so - 2-3 years behind the releases.
> > hmm - since you said "less" does not recognize ^N/^O, I'm assuming you
> > meant that you changed sgr0 to \E[m,
>
> I think I'll change that back to \E[m because of this problem.
...and remove sgr (see below).
> > which works for termcap, but not for applications that use
> > line-drawing (without of course hardcoding things).
>
> Well the applications that use line-drawing seem to use rmacs
> explicitly (I think they should all do that for a few years
> for compatibility). Then having the rmacs escape sequence in
> sgr0 is useless for these applications, isn't it?
Not exactly - most curses libraries use sgr if it's present.
In that case, I would expect them to use sgr0. (I recall getting
burned with that on more than one Unix platform - sgr0 is expected
to reset the alternate character set).
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
Subject: Re: Bug#404079: display problem with xterm + screen and bold
characters
Date: Sun, 24 Dec 2006 14:39:07 +0100
On 2006-12-22 17:04:14 -0500, Thomas Dickey wrote:
> On Fri, Dec 22, 2006 at 10:17:06PM +0100, Vincent Lefevre wrote:
> > I prefer to have them (libraries compiled by the user) in a separate
> > directory. Applications that use ncurses should also be recompiled.
>
> I suppose so. In 5.6 I've revisited rpath linkage, and made it work
> well enough for that, so I won't be recompiling ncurses applications
> where they've been linked dynamically any more. (Though checking, no
> one's provided any information on rpath in Mac OS X - working from manpages
> alone is futile).
Mac OS X *seems* to always use rpath: unlike Linux, I've never had
to set LD_LIBRARY_PATH or similar under Mac OS X (with any library),
and libraries are found even those in /opt/local/lib (which is a
non-standard path, where libraries installed by MacPorts are stored).
> > I think I'll change that back to \E[m because of this problem.
>
> ...and remove sgr (see below).
OK, done.
Merry Christmas,
--
Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Sun, Dec 24, 2006 at 02:39:07PM +0100, Vincent Lefevre wrote:
> On 2006-12-22 17:04:14 -0500, Thomas Dickey wrote:
> > On Fri, Dec 22, 2006 at 10:17:06PM +0100, Vincent Lefevre wrote:
> > > I prefer to have them (libraries compiled by the user) in a separate
> > > directory. Applications that use ncurses should also be recompiled.
> >
> > I suppose so. In 5.6 I've revisited rpath linkage, and made it work
> > well enough for that, so I won't be recompiling ncurses applications
> > where they've been linked dynamically any more. (Though checking, no
> > one's provided any information on rpath in Mac OS X - working from manpages
> > alone is futile).
>
> Mac OS X *seems* to always use rpath: unlike Linux, I've never had
I was reading something like that yesterday (considering what new
development I could do for shared libraries). It was stated that
Mac OS X stores only the absolute pathname to each shared library.
That has the same effect of rpath...
> to set LD_LIBRARY_PATH or similar under Mac OS X (with any library),
> and libraries are found even those in /opt/local/lib (which is a
> non-standard path, where libraries installed by MacPorts are stored).
>
> > > I think I'll change that back to \E[m because of this problem.
> >
> > ...and remove sgr (see below).
>
> OK, done.
no problem (report bugs)
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
Subject: Re: Bug#404079: display problem with xterm + screen and bold
characters
Date: Sun, 24 Dec 2006 19:00:25 +0100
On 2006-12-24 08:48:36 -0500, Thomas Dickey wrote:
> On Sun, Dec 24, 2006 at 02:39:07PM +0100, Vincent Lefevre wrote:
> > Mac OS X *seems* to always use rpath: unlike Linux, I've never had
>
> I was reading something like that yesterday (considering what new
> development I could do for shared libraries). It was stated that
> Mac OS X stores only the absolute pathname to each shared library.
> That has the same effect of rpath...
Well, if it stores the absolute pathname to each shared library,
this doesn't exactly have the same effect. AFAIK, rpath stores an
ordered list of directories, then this list is used to search for
shared libraries. This means that if versions 1 and 2 of library A
are stored in directories /usr/lib and /usr/local/lib respectively
and if versions 1 and 2 of library B are stored in directories
/usr/local/lib and /usr/lib respectively, it is not possible to
use version 2 of libraries 1 and 2 (unless the soname is different
from version 1).
--
Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Sun, Dec 24, 2006 at 07:00:25PM +0100, Vincent Lefevre wrote:
> On 2006-12-24 08:48:36 -0500, Thomas Dickey wrote:
> > On Sun, Dec 24, 2006 at 02:39:07PM +0100, Vincent Lefevre wrote:
> > > Mac OS X *seems* to always use rpath: unlike Linux, I've never had
> >
> > I was reading something like that yesterday (considering what new
> > development I could do for shared libraries). It was stated that
> > Mac OS X stores only the absolute pathname to each shared library.
> > That has the same effect of rpath...
>
> Well, if it stores the absolute pathname to each shared library,
> this doesn't exactly have the same effect. AFAIK, rpath stores an
> ordered list of directories, then this list is used to search for
...
agree - I was not thinking of the search list (though I'm aware of it).
The description I read did not mention it, either...
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
Subject: Re: Bug#404079: display problem with xterm + screen and bold characters
Date: Tue, 26 Dec 2006 15:56:27 -0500
Thomas Dickey <[email protected]> writes:
> agree - I was not thinking of the search list (though I'm aware of it).
>
> The description I read did not mention it, either...
Mac OS's approach to dynamic libraries is ... somewhat unusual.
AFAICT, the way things work there is that each library hard-codes a
(single) canonical installation location, which the static linker then
embeds in any executables (or other dynamic libraries) that link to
it. The runtime linker then proceeds to search for each required
library in, in order, DYLD_LIBRARY_PATH, the hardcoded per-library
path, and DYLD_FALLBACK_LIBRARY_PATH.
(It's actually slightly more complicated than that because there's
also the concept of frameworks, but I don't believe it concerns
ncurses.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [email protected] (NOT a valid e-mail address) for more info.
On Tue, Dec 26, 2006 at 03:56:27PM -0500, Aaron M. Ucko wrote:
> Thomas Dickey <[email protected]> writes:
>
> > agree - I was not thinking of the search list (though I'm aware of it).
> >
> > The description I read did not mention it, either...
>
> Mac OS's approach to dynamic libraries is ... somewhat unusual.
> AFAICT, the way things work there is that each library hard-codes a
> (single) canonical installation location, which the static linker then
> embeds in any executables (or other dynamic libraries) that link to
> it. The runtime linker then proceeds to search for each required
> library in, in order, DYLD_LIBRARY_PATH, the hardcoded per-library
> path, and DYLD_FALLBACK_LIBRARY_PATH.
HPUX embeds an installation location as well...
Creating the libraries is one part of the problem.
Installing them can be a pain as well.
--
Thomas E. Dickey
http://invisible-island.netftp://invisible-island.net
Subject: xterm: Problem reproducible on unstable only with vttest
Date: Mon, 14 Jan 2008 23:36:14 +0100
Followup-For: Bug #404079
Package: xterm
Version: 231-1
Hello,
I can reproduce this problem on unstable only using vttest (1) (by the
author of xterm).
Here are the steps I followed to do this:
$ LANG=fr_FR.UTF-8 /usr/bin/xterm
Then in the new xterm:
$ vttest
Select "2. Test of screen features"
The screens are correctly displayed until "Graphic rendition test
pattern", "Light background". On the next screen, the characters
(stars, lines, x'es and diamonds) in the bold column are not bold.
After exiting vttest, a test:
$ echo -e ' \033[1;37m\033[40m gYw \033[0m'
does not display gYw as bold (as should be).
If I start xterm with LANG=C, this problem does not show up. In both
cases (LANG=C and LANG=fr_FR.UTF-8), the value of TERM is xterm.
HTH
Greetings,
Fred
(1) http://invisible-island.net/vttest/vttest.html. A source Debian
package is available at
http://mentors.debian.net/debian/pool/main/v/vttest/
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.23.12
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xterm depends on:
ii libc6 2.7-6 GNU C Library: Shared libraries
ii libfontconfig1 2.5.0-2 generic font configuration library
ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library
ii libncurses5 5.6+20080105-1 Shared libraries for terminal hand
ii libsm6 2:1.0.3-1+b1 X11 Session Management library
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxaw7 2:1.0.4-1 X11 Athena Widget library
ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar
ii libxft2 2.1.12-2 FreeType-based font drawing librar
ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library
ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii xbitmaps 1.0.1-2 Base X bitmaps
Versions of packages xterm recommends:
ii xutils 1:7.3+10 X Window System utility programs m
-- no debconf information
Source: xterm
Source-Version: 232-1
We believe that the bug you reported is fixed in the latest version of
xterm, which is due to be installed in the Debian FTP archive:
xterm_232-1.diff.gz
to pool/main/x/xterm/xterm_232-1.diff.gz
xterm_232-1.dsc
to pool/main/x/xterm/xterm_232-1.dsc
xterm_232-1_i386.deb
to pool/main/x/xterm/xterm_232-1_i386.deb
xterm_232.orig.tar.gz
to pool/main/x/xterm/xterm_232.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Julien Cristau <[email protected]> (supplier of updated xterm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Tue, 19 Feb 2008 21:20:08 +0100
Source: xterm
Binary: xterm
Architecture: source i386
Version: 232-1
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force <[email protected]>
Changed-By: Julien Cristau <[email protected]>
Description:
xterm - X terminal emulator
Closes: 404079459816459817460545462621464947
Changes:
xterm (232-1) unstable; urgency=low
.
* New upstream release.
+ corrected logic in a font-cache used for reverse-video
(closes: #404079)
+ allow building with configure options --disable-ansi-color and
--disable-leaks (closes: #459817)
+ allow building with configure options --enable-wide-chars and
--disable-c1-print (closes: #459816)
+ add pointerMode resource to control whether and when the pointer cursor
is hidden as the user types; also fix it so it's really hidden instead
of showing a black dot (closes: #460545)
+ add limit-checks to tabs.c, increase maximum column for setting
tab-stops from 320 to 1024 (closes: #462621)
* Set pointerMode to "never" by default, to restore pre-230 behaviour.
Document that change in xterm.man (new patch 902_pointermode_never.diff).
* Look for luit in /usr/bin, not /usr/X11R6/bin.
* Refresh patches.
* debian/control: luit is in x11-utils now, update Recommends and
Description.
* Add Vcs-* and Homepage fields in debian/control. Thanks, Joey Hess!
(closes: #464947)
Files:
28bc10a50cf0df435fbad0cc3277dd2c 974 x11 optional xterm_232-1.dsc
47cc1f1642189c8ae272b19675e86db4 853200 x11 optional xterm_232.orig.tar.gz
2114b0eda13c362d2dc8067e5517894e 62016 x11 optional xterm_232-1.diff.gz
437cb55b5ff837a7922f040e4a2d9aa4 463984 x11 optional xterm_232-1_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHuzuDmEvTgKxfcAwRAs3+AJ94L4zgXEqcUNtA6M0egohxae/1uwCgkNoY
GpAmy50RG8gCFGPJLSJ/1oU=
=ZcC1
-----END PGP SIGNATURE-----