On 2007-06-26 19:32:22 -0400, Thomas Dickey wrote:
hmm. Going back through the thread, it seems you're talking about selecting
text while it's moving.
Yes.
Outside of that - I'm not seeing any instance where it selects past the
current line. From your report, I cannot tell if there's a
On 2007-06-27 12:24:33 +0200, Michel Dänzer wrote:
Let me point out that char is unsigned by default on powerpc. Could
there be code in xterm that assumes otherwise?
I can reproduce the bug on both x86 and powerpc.
BTW, is there a way to record X events and replay them?
--
Vincent Lefèvre
On 2007-06-27 07:34:45 -0400, Thomas Dickey wrote:
Supposedly (there's an XTest extension). But I haven't seen anyone
responding on xorg to the occasional request for information regarding
this. Most of the references to it are very old. Here's a museum:
On 2007-06-27 23:08:15 +0200, Vincent Lefevre wrote:
I haven't found. The closest would be xnee (I've used xnee -rec -fc
--all-events -o rec -l -1), but it just records keyboard and mouse
events, and doesn't record what is displayed.
But perhaps this is the solution:
http://www.unixuser.org
On 2007-06-27 23:15:31 +0200, Vincent Lefevre wrote:
http://www.unixuser.org/~euske/vnc2swf/
I've used that to generate the movie you can see at:
http://www.vinc17.org/download/debbug430121.html
It lasts about 34 seconds.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org
On 2007-06-25 09:21:26 -0400, Thomas Dickey wrote:
On Mon, Jun 25, 2007 at 03:17:50PM +0200, Vincent Lefevre wrote:
Would ttyrec be OK? I only have my laptop here and script isn't
installed.
That sounds ok (google suggests it's a form of 'script').
Unfortunately, ttyrec no longer works
On 2007-06-26 06:03:21 -0400, Thomas Dickey wrote:
On Tue, Jun 26, 2007 at 09:27:29AM +0200, Vincent Lefevre wrote:
Unfortunately, ttyrec no longer works on my PowerBook (I get the
error Out of pty's). But I've tried xterm's log to file feature.
This log file (attached) looks OK, though I
On 2007-06-26 09:24:44 -0400, Thomas Dickey wrote:
On Tue, Jun 26, 2007 at 02:58:31PM +0200, Vincent Lefevre wrote:
A naive replay won't work: you need (triple-)clicks while the output
occurs to be able to reproduce the bug (such clicks more or less
freeze xterm's output).
I would take
On 2007-06-23 18:20:09 +0200, Thomas Dickey wrote:
perhaps you are using screen
No, I wasn't using screen. BTW, I thought the problem could be
related to colors, but I could reproduce it without colors.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible
On 2007-06-25 08:56:34 -0400, Thomas Dickey wrote:
xterm marks wrapped lines as it sees text being written across the right
margin, and those marks tell it how long a line really is. Clearing the
screen is supposed to remove the marks, scrolling shifts-in unmarked
lines, etc. I haven't made
Package: xterm
Version: 226-1
Severity: normal
EOL characters are sometimes missing from the selection. This affects
the triple-click, which selects too much in such a case.
I've attached a snapshot. If I triple-click on the line
make[1]: *** [all-recursive] Error 1
or below, the whole part
On 2007-06-22 15:58:17 +0200, Vincent Lefevre wrote:
Package: xterm
Version: 226-1
Severity: normal
EOL characters are sometimes missing from the selection. This affects
the triple-click, which selects too much in such a case.
[...]
I could reproduce the EOL problem in other two xterm
On 2007-06-22 15:58:17 +0200, Vincent Lefevre wrote:
Package: xterm
Version: 226-1
Severity: normal
EOL characters are sometimes missing from the selection. This affects
the triple-click, which selects too much in such a case.
[...]
This was even worse: when I selected other parts
Taking the modeline from
http://forums.gentoo.org/viewtopic.php?t=469455
solved the problem, but this doesn't explain why the old one no longer
works.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Hi Brice,
On 2007-06-16 16:56:57 +0200, Brice Goglin wrote:
Does this problem about X sometimes giving an incorrect display after
startup still occur nowadays? With latest xserver-xorg-core and drivers
currently in unstable? If so, please send the output of
Package: xterm
Version: 225-1
Severity: wishlist
It would be useful to have the ability to run a script just before
xterm is about to exit. The script should have access to the following
information in some way:
* the exit status of the subprocess if it has terminated (thus
causing xterm to
On 2007-06-04 22:53:36 +0200, Brice Goglin wrote:
Does this problem with arrow keys sometimes producing repeated digits
still happen nowadays? With latest xserver-xorg-core 1.3 and drivers?
I don't know. I mostly use this machine remotely. I'm installing
the latest versions so that when I try
On 2007-04-11 23:00:59 -0400, Nathanael Nerode wrote:
retitle 232345 xterm: Control sequences document is not installed anywhere
severity 232345 important
thanks
Well, this old bug has actually gotten *worse*. While xterm (1)
refers repeatedly to the control sequences document, now that
On 2007-04-12 08:04:57 +0200, Vincent Lefevre wrote:
On 2007-04-11 23:00:59 -0400, Nathanael Nerode wrote:
retitle 232345 xterm: Control sequences document is not installed anywhere
severity 232345 important
thanks
Well, this old bug has actually gotten *worse*. While xterm (1
On 2007-04-09 22:12:15 +0200, Brice Goglin wrote:
About 3 years ago, you reported (or replied to) a bug in the Debian BTS
regarding xclock font/color not changing with cmdline options or X
resources. There has been some interesting replies since then. Does any
of you guys still have this
On 2007-04-09 16:51:42 +0200, Brice Goglin wrote:
What's the status of this bug? Did you find a fix/workaround? Does it
still happen with xbase-clients 7.2.ds2-1 (currently in experimental)?
A strace -f shows that the include directories are stat'd, but they
are not read. But in this case, why
On 2007-03-06 19:08:16 +0100, Vincent Lefevre wrote:
Another snapshot... This is not a color problem only.
This may be a bug in aptitude. I wonder if this is this one:
aptitude (0.4.4-3) unstable; urgency=low
[...]
* Fix a bug in an internal sprintf variant that would include random
On 2007-03-14 01:04:23 +0100, Vincent Lefevre wrote:
On 2007-03-06 19:08:16 +0100, Vincent Lefevre wrote:
Another snapshot... This is not a color problem only.
This may be a bug in aptitude. I wonder if this is this one:
aptitude (0.4.4-3) unstable; urgency=low
[...]
* Fix a bug
severity 414838 grave
thanks
On 2007-03-13 17:39:08 -0700, Steve Langasek wrote:
# Automatically generated email from bts, devscripts version 2.9.27
severity 414838 normal
tags 414838 = unreproducible
The fact that it is unreproducible on your machine doesn't make it
no longer a security
Package: xserver-xorg
Version: 1:7.1.0-13
Severity: normal
Sometimes when I hit an arrow key (e.g. the left arrow one), the
system produces a digit ('4' in the case of the left arrow), which
is repeated, just as if I had pressed the key '4'. The digit is
repeated until I hit another key.
This
Another snapshot... This is not a color problem only.
--
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)
xterm-aptitude2.png
Hi,
On 2007-01-14 00:33:22 +0100, Brice Goglin wrote:
About 3 years ago, you reported (or replied to) a bug in the Debian BTS
regarding an erroneous automatic update of X config files. It was
supposed to be fixed but was apparently not. Did any of you guys
reproduce this problem recently? If
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
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
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
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.
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.
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.
On 2006-11-08 02:35:56 +0100, Julien Cristau wrote:
I tried to reproduce this by upgrading xterm from sarge to etch and
didn't get any dangling symlink. I tried an upgrade with xterm as the
only x-terminal-emulator package installed, as well as with xterm and
rxvt, and I also tried setting
On 2006-10-07 14:50:39 +0200, Denis Barbier wrote:
If you run startx by hand, try
startx startx.log 21
OK, this says:
The XKEYBOARD keymap compiler (xkbcomp) reports:
Error:Can't find file uk for symbols include
Exiting
Abandoning symbols
Package: xserver-xorg
Version: 1:7.1.0-3
Severity: minor
(Not sure about the package, please reassign the bug to the right one.)
Sometimes, just after I start X (with startx), the display is
incorrect:
* Some icons have wrong colors (e.g. black instead of white).
* Most text is not visible
On 2006-10-07 10:55:31 +0200, Denis Barbier wrote:
It was successfully parsed, but the external xkbcomp program
rejected it.
How can I see that?
I've tried again and attached the log file.
If you run a display manager, error messages appear in
/var/log/*dm.log.
I don't run a display
This problem no longer occurs with xserver-xorg 1:7.1.0-2, but I don't
know if the problem was fixed in 1:7.1.0-2, or if this is because I've
just upgraded the kernel (because udev wasn't working with the previous
one).
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100%
On 2006-10-06 12:19:30 +0200, Vincent Lefevre wrote:
This problem no longer occurs with xserver-xorg 1:7.1.0-2, but I don't
know if the problem was fixed in 1:7.1.0-2, or if this is because I've
just upgraded the kernel (because udev wasn't working with the previous
one).
Hmmm... I've just
Package: xserver-xorg
Version: 1:7.1.0-2
Severity: minor
The /etc/X11/xorg.conf file contains:
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type man /etc/X11/xorg.conf at the shell prompt.)
man /etc/X11/xorg.conf is incorrect as this shows the /etc/X11/xorg.conf
Package: xkb-data
Version: 0.8-17
Severity: normal
In my xorg.conf file, I have:
Section InputDevice
Identifier Generic Keyboard
Driver kbd
Option CoreKeyboard
Option XkbRules xorg
Option XkbModel pc105
On 2006-10-06 15:21:28 +0200, Julien Cristau wrote:
On Fri, Oct 6, 2006 at 13:48:01 +0200, Vincent Lefevre wrote:
Option XkbLayout uk
uk is not a valid layout, please change it to gb.
OK, why was uk accepted by the X server, then?
--
Vincent Lefèvre [EMAIL PROTECTED
Package: xfonts-100dpi
Version: 1:1.0.0-3
Severity: normal
I use fonts like -*-helvetica-medium-o-*-*-12-*-*-*-*-*-*-* in fvwm
menus, and in UTF-8 locales, I get a very large vertical space between
the items. No problem in ISO8859-1 locales or with default fonts,
though the same characters are
On 2006-10-06 21:39:40 +0200, Denis Barbier wrote:
On Fri, Oct 06, 2006 at 04:22:53PM +0200, Vincent Lefevre wrote:
On 2006-10-06 15:21:28 +0200, Julien Cristau wrote:
On Fri, Oct 6, 2006 at 13:48:01 +0200, Vincent Lefevre wrote:
Option XkbLayout uk
uk
Package: xserver-xorg
Version: 1:7.1.0-1
Severity: grave
Justification: renders package unusable
In the postinst, I get a dialog saying:
Configuring xserver-xorg
Empty value
A null entry is not permitted for this value.
OK
If I type Return,
Package: xbase-clients
Version: 1:7.1.ds-3
Severity: important
After the NFS server has restarted, I get the following error:
dixsept:~ xrdb .Xresources
cc1: error: /users/spaces/logiciels/mathlib/linux/../include: Stale NFS file
handle
Everything is local, so I really don't know why xrdb
On 2006-09-14 17:13:09 +0200, Bernhard R. Link wrote:
Try xrdb -nocpp instead.
But a resource file is not a C/C++/Objective C file! If it is uses
the C preprocessor for some reason (BTW, the default behavior is
badly documented), then it should probably undefine the variables
CPATH,
On 2006-05-14 21:06:50 -0400, David Nusinow wrote:
We've found a good solution for this bug.
A solution that breaks the system is not a good solution. The breakage
for official Debian packages is avoided thanks to the many conflicts
in the Conflicts: field, but this doesn't work with packages
On 2006-05-15 09:06:33 +0200, Eduard Bloch wrote:
- present a list to the user, saying what the remaining files are and
where they do come from (package names to be easily removed by $user)
The user can remove these packages. But this is not sufficient,
as the user could re-add them later.
On 2006-05-15 15:43:31 -0500, Steve Langasek wrote:
On Mon, May 15, 2006 at 05:01:56AM +0200, Vincent Lefevre wrote:
A solution that breaks the system is not a good solution. The breakage
for official Debian packages is avoided thanks to the many conflicts
in the Conflicts: field
Any news about this bug?
As the current error doesn't solve any problem, why not let
/usr/X11R6/bin there until a better solution (if any) is found?
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR
reopen 362885
thanks
BTW, I'm reopening this bug: Making a symlink is bogus since
dpkg removes it when one removes a package that contains files
in /usr/X11R6/bin. Otherwise, x11-common should make sure that
the symlink remains (if possible).
--
Vincent Lefèvre [EMAIL PROTECTED] - Web:
On 2006-01-23 08:37:32 +0100, Vincent Lefevre wrote:
I get the following error:
dixsept:~ man x-terminal-emulator
man: warning: /usr/share/man/man1/x-terminal-emulator.1.gz is a dangling
symlink
No manual entry for x-terminal-emulator
The problem is still there in xterm 210-3.
dixsept
Package: xbase-clients
Version: 1:7.0.1-1
Severity: normal
A man atobm gives the error:
man: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory
before the man page can be found.
dixsept:~ gunzip -c /usr/share/man/man1/atobm.1x.gz
.so man1x/bitmap.1x
but the man page is:
On 2006-05-04 18:02:31 -0700, Steve Langasek wrote:
Yes, it says that local changes must be preserved; it does not say
that the package may not attempt to upgrade config files.
If it attempts to upgrade something the user has changed, this isn't
much different. Moreover the /etc/X11/xorg.conf
Package: xserver-xorg
Version: 1:7.0.16
Severity: serious
Justification: Policy 10.7.3
The Debian policy manual says that local changes must be preserved
during upgrade. However xserver-xorg upgrade duplicated some lines
in Section Files:
Section Files
FontPathunix/:7100
On 2006-01-10 13:22:08 -0500, Thomas Dickey wrote:
On Tue, Jan 10, 2006 at 04:50:16PM +0100, Wichert Akkerman wrote:
This happens with the current unstable version.
When selecting the top visible line in xterm it can include text from
the (scrolled off) line above it. This does not
reassign 348111 bash
merge 343471 348111
thanks
--
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 / SPACES project at LORIA
On 2005-12-27 10:54:27 +0100, David Martínez Moreno wrote:
What are you using? Mmmm...X.Org 6.8.2-11. The same as here.
As I've said in my latest message, the change is in 6.8.2.dfsg.1-1.
I didn't notice the problem before because I upgraded from XFree86
to Xorg a few days ago (but I also
reassign 344776 xorg-x11
retitle 344776 Incorrect Speedo/fonts.dir leads to incorrect font selection
thanks
On 2005-12-26 17:46:09 -0500, Thomas Dickey wrote:
I also noticed that the default fontsize is different in XFree86 vs
Xorg.
I've found the cause of the problem. I have
reassign 344776 xorg-x11
retitle 344776 Incorrect Speedo/fonts.dir leads to incorrect font selection
thanks
(resent since I forgot to Cc [EMAIL PROTECTED] -- sorry)
On 2005-12-26 17:46:09 -0500, Thomas Dickey wrote:
I also noticed that the default fontsize is different in XFree86 vs
Xorg.
On 2005-12-26 20:27:04 -0500, Thomas Dickey wrote:
On Tue, Dec 27, 2005 at 01:47:08AM +0100, Vincent Lefevre wrote:
If I remove this directory from my font path, then the fonts are OK.
/usr/X11R6/lib/X11/fonts/Speedo does contain a fonts.dir file:
I have the same data, but my /var/log
Package: xterm
Version: 204-0pre1
Severity: normal
When I make a menu appears with Ctrl-click over an xterm window,
the fonts are very large.
I've attached the result of appres XTerm.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'),
Snapshot attached.
xterm-menu.png
Description: PNG image
On 2005-12-26 05:08:50 +0100, David Martínez Moreno wrote:
Strange, I have the right menus with the same version
(204-0pre1). I send attached a picture.
It was like this before I upgraded to xterm 204-0pre1. Or is it due
to my recent upgrade to Xorg? Perhaps not a problem with xterm since
Package: xterm
Version: 6.8.2.dfsg.1-11
Severity: important
In a VNC desktop (served by Xrealvnc) with the fvwm window manager,
when I run uxterm or start xterm with LC_CTYPE=en_US.UTF-8, the
top command shows that the xterm process takes up to more than
200 MB RES memory, making the whole system
Package: xterm
Version: 6.8.2.dfsg.1-7
Severity: important
As shown by strace -f, xterm -e ./cmd tries to access cmd found in
$PATH (ignoring .) instead of cmd found in the current directory.
If cmd isn't found, xterm just segfaults. In particular, this breaks
rox, which tries to compile in an
On 2005-08-07 01:15:17 +0200, Vincent Lefevre wrote:
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-14
Severity: important
I don't know if this is related to the crash: I had network problems
(lost packets + following packets that arrived several seconds late,
as shown by a ping). After
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-14
Severity: important
I don't know if this is related to the crash: I had network problems
(lost packets + following packets that arrived several seconds late,
as shown by a ping). After the crash, the ping showed lost packets
only (about 10%).
--
On 2005-07-20 18:30:39 +0200, Vincent Lefevre wrote:
The xterm source knows about IUTF8, but for some reasons xterm is not
built with IUTF8 support.
I managed to compile xterm from upstream and IUTF8 support with
the attached patch. Not sure about side effects or portability
or missing features
Package: xterm
Version: 6.8.2.dfsg.1-3
Severity: normal
The file /etc/X11/app-defaults/UXTerm says:
! The fonts here are duplicated in XTerm by *VT100.utf8fonts, but are
! left here for compatibility:
*VT100*font2: -misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
*VT100*font:
Package: xterm
Version: 6.8.2.dfsg.1-3
Severity: wishlist
The xterm source knows about IUTF8, but for some reasons xterm is not
built with IUTF8 support.
For more information about IUTF8, see the end of the section
http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod
-- System Information:
Debian
On 2005-07-13 17:09:08 +0200, Vincent Lefevre wrote:
Attached, but the problem no longer occurs!
Now is occurs again. I've attached the diff on the output.xorg file.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17
On 2005-07-13 18:29:25 +0200, David Martínez Moreno wrote:
Try the attached dexconf, and see if your problem vanishes.
Yes, this solves the problem. Thanks.
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog:
Package: xterm
Version: 4.3.0.dfsg.1-13
Severity: wishlist
I think that the printing feature should be disabled by default, as
most users probably don't need it, don't know it and this feature
may lead to security/privacy problems (see bugs 301989 and 311384
for instance). The solution is to set
On 2005-03-24 07:12:01 +, Adam M. Costello wrote:
Package: xterm
Version: 4.3.0.dfsg.1-10
Severity: minor
There used to be a file /usr/share/doc/xterm/ctlseqs.* that
described the control sequences understood by xterm. It seems to
have disappeared.
I think this is wanted. You can get
reopen 277832
thanks
Patch #200 fixes indeed a scrolling problem. But the selection is
still thrown away when using screen for instance (gnome-terminal
doesn't have this problem).
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog:
On 2005-02-12 03:18:26 -0800, Debian Bug Tracking System wrote:
+ Fix a regression from patch #197 which disowned the selection
if it was scrolled, e.g., by the user pressing return at the
bottom of the screen. (Closes: #277832, #291787)
Bug 277832 was not about a regression and
On 2005-02-08 01:26:55 -0500, Branden Robinson wrote:
I'm attaching the patch that Thomas Dickey has put into XTerm #200.
I expect to include this in the next package release, and plan to
close this bug accordingly.
I've just checked out xterm from the xfree86.org CVS and compiled it,
and I
On 2005-01-11 05:15:09 -0500, Branden Robinson wrote:
I still want to hear what Thomas Dickey as to say about this. I'm
also not sure the semantics of selections vs. cut buffers are as you
describe.
I don't think the end user should be exposed to differences between
implementations (e.g.
On 2004-12-31 04:34:13 -0500, Branden Robinson wrote:
Well, let's call this bug what it is, then.
Note that gnome-terminal isn't the only application that keeps the
primary selection when it is no longer highlighted. Mozilla, Opera
and Emacs all have the same behavior.
And I don't think this is
On 2004-12-23 18:53:17 -0500, Branden Robinson wrote:
On Wed, Dec 15, 2004 at 10:59:42PM +0100, Vincent Lefevre wrote:
On 2004-12-15 14:59:14 -0500, Branden Robinson wrote:
If screen is linked against ncurses, it may be a simple mattter of
programming to enable sensitivity to mouse
On 2004-12-19 06:50:34 -0500, Thomas Dickey wrote:
On Sat, 18 Dec 2004, Vincent Lefevre wrote:
How should I change them? Does select-extend() work without a
select-start() first?
no - how would it know where the selection started?
So, I don't see how to configure xterm so that a left click
On 2004-12-16 17:55:47 -0500, Thomas Dickey wrote:
Actually I did fix the hard part. The remainder is user-preferences
which can be easily set with resources.
How? I didn't see anything new in the man page.
In #197, I also added a section to the manpage describing the use of
the clipboard -
On 2004-12-17 13:27:40 -0500, Thomas Dickey wrote:
There aren't that many choices - the primary selection is only owned by
one application at a time. I reduced(*) xterm's tendency to give it up,
but
if another application asserts it, or
you start a new selection, or
The
On 2004-12-17 19:22:15 -0500, Thomas Dickey wrote:
On Sat, 18 Dec 2004, Vincent Lefevre wrote:
When I tried with the latest Debian version, neither of these
conditions were satisfied (a click shouldn't be regarded as
starting a selection). So, the bug is still there.
It's been documented
On 2004-12-15 14:59:14 -0500, Branden Robinson wrote:
Output streams from character devices are not the same sort of
data for the purpose of bug severities as the contents of a
filesystem.
OK.
The (only?) big problem with screen is that one cannot scrollback
with the mouse.
If screen
reopen 277832
thanks
I have xterm 4.3.0.dfsg.1-9, and the problem (as described in the
first message) is still there.
--
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 /
On 2004-12-10 03:45:11 -0500, Branden Robinson wrote:
Severity: wishlist
I agree. :)
Well, I considered that losing data (as long as the program has the
control of them) was a bug.
I get basically this functionality, plus a lot of other useful
features, by using GNU Screen, available
On 2004-11-09 06:31:42 +0100, Fabio Massimo Di Nitto wrote:
If X applications are not able to handle data properly on crash,
that's an application problem.
Hmm... OK. I hope that their maintainers won't say that the X server
shouldn't crash. However, it seems difficult to recover the session
as
Package: xterm
Version: 4.3.0.dfsg.1-8
Severity: normal
When the X connection is lost abnormally, e.g. when the X server
has crashed as in bug#280364, xterm should save the terminal data
(including the lines that are scrolled off the top of the window)
in some way so that the user doesn't lose
Package: xserver-common
Version: 4.3.0.dfsg.1-8
Severity: grave
Justification: causes non-serious data loss
While I was scrolling a Mozilla window, X crashed (signal 7).
This is the first time this happens, but I usually don't use
XFree86. I lost all the data that have not been saved by X
On 2004-11-04 12:29:21 -0500, Branden Robinson wrote:
Is this not a bug, then, but rather a misunderstanding of how
translation table resources work?
Well, this is a bug in the documentation, which doesn't provide
enough information. It wasn't even clear that XtAugmentTranslations
or
Package: xterm
Version: 4.3.0.dfsg.1-8
Severity: important
I wanted to try to use CLIPBOARD instead of CUT_BUFFER0, so that
copy-paste between xterm and Mozilla (in fact, not only Mozilla,
but other GTK+ applications too) work in any case. So, I modified
*VT100.translations in my
On 2004-10-30 08:38:36 +0200, Vincent Lefevre wrote:
*VT100.translations: #override \n\
CtrlUp: scroll-back(1, line) \n\
CtrlDown: scroll-forw(1, line) \n\
BtnUp:select-end(PRIMARY, CLIPBOARD) \n\
~Ctrl ~Meta Btn2Up
On 2004-10-30 10:26:58 -0400, Thomas Dickey wrote:
It should be documented perhaps, but that's an issue with the way X
resources work - the manpage would be several times longer if I
included all of the relevant documentation within it.
I don't think all of the relevant documentation should be
Package: xterm
Version: 4.3.0.dfsg.1-8
Severity: normal
I open two uxterm's. In the first one, I type from zsh:
echo \\u20ac
to get a Euro symbol. I double-click on this Euro symbol and paste it
(with the middle button) to the second uxterm. No problem: I get the
Euro symbol.
Now, I click in
On 2004-10-13 16:34:42 +0200, Loïc Minier wrote:
It's been some months now that I repeatedly get a strange problem with
a less in xterm: if I select the first line of the xterm window, being
the first line of the less dump too, I am pasting some sort of buffered
data too, coming from
On 2004-10-18 07:20:05 -0500, Branden Robinson wrote:
Does xprt-xprintorg work for you?
After installing xprt-xprintorg, Mozilla no longer complains.
I've just seen in the xprt-xprintorg description:
This package provides Xprt, the Xprint server compiled from
xprint.mozdev.org. This
Package: xterm
Version: 4.3.0.dfsg.1-8
Severity: important
Since the Mozilla bug 63419 [*] has been closed as wontfix, then this
should be fixed in xterm.
The problem is that if a selection in an xterm is no longer there
(e.g. after a click in the xterm or if the xterm has been closed),
then it
301 - 400 of 419 matches
Mail list logo