nts,
such as "9.53", but the gs that I have installed actually reports version
number "9.53.3". Fixing that code in pdfxup doesn't resolve the rest
of the errors.
-zefram
Upstream:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69436
-zefram
Upstream:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69436
-zefram
me design issue, it's likely that a
single upstream fix would resolve both bugs.
A near-identical customisation can also be applied to the guile-2.2
package, to ameliorate the same problems there, which I reported as
Bug#106 and Bug#1064445.
-zefram
ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:130
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_setting)
from :1
(/usr/lib/perl6/runtime/perl6.moarvm:)
$
raku(1) should not be failing because of an environment variable that
isn't controlling anything and isn't being referenced.
-zefram
x27;chdir ".."; while(1) { rename("a", "b"); rename("b", "a"); }' &
[1] 390457
$ guile-2.2 --no-auto-compile ok.scm
ok
$ guile-2.2 --no-auto-compile ok.scm
Backtrace:
0 (primitive-load "/home/zefram/tmp/g0/b/ok.scm")
ERR
0bar.scm'
$ LC_ALL=de_DE.iso88591 guile-2.2 --no-auto-compile
$'foo\xf4\x90\x80\x80bar.scm' 2>&1 | cat -v
perplexity
$ LC_ALL=de_DE.utf8 guile-2.2 --no-auto-compile $'foo\xf4\x90\x80\x80bar.scm'
2>&1 | cat -v
;;; Stat of /home/zefram/tmp/g0/fooM-
1) must at least detect that it can't handle the specified
filename. It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose. Furthermore,
this limitation must be documented.
-zefram
;chdir ".."; while(1) { rename("a", "b"); rename("b", "a"); }' &
[1] 389562
$ guile-3.0 --no-auto-compile ok.scm
ok
$ guile-3.0 --no-auto-compile ok.scm
Backtrace:
0 (primitive-load "/home/zefram/tmp/g0/b/ok.scm")
0bar.scm'
$ LC_ALL=de_DE.iso88591 guile-3.0 --no-auto-compile
$'foo\xf4\x90\x80\x80bar.scm' 2>&1 | cat -v
perplexity
$ LC_ALL=de_DE.utf8 guile-3.0 --no-auto-compile $'foo\xf4\x90\x80\x80bar.scm'
2>&1 | cat -v
;;; Stat of /home/zefram/tmp/g0/fooM-
1) must at least detect that it can't handle the specified
filename. It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose. Furthermore,
this limitation must be documented.
-zefram
in any of these locales,
and the help text ought to always conform to the environmentally-selected
locale. For ASCII and Latin-1 locales this implies that it can't use
that en dash, and must substitute an ASCII "-". I have no strong opinion
about whether it should use the en dash in a UTF-8 locale.
-zefram
parts of the output.
I'm specifically seeing that result with a Latin-1 terminal emulator
and the C locale.
-zefram
ause @ARGV would then always be empty by the
time that loop is reached. But it would still be good style to change <>
to , to better indicate the program's intended behaviour.
>If it is, I would like to include your reasoning into a patch for
>upstream, ok?
Sure. You may use that text freely.
-zefram
s
line 114.
# echo > '|echo wibble'
# debconf-set-selections '|echo wibble'
wibble
#
These arise from its use of the <> Perl operator, which is not suitable
for the implementation of a read-from-list-of-files kind of command.
Because the range of misbehaviour includes writing to arbitrary files
and running arbitrary commands, this is a more severe bug than normal.
-zefram
Package: xindy
Version: 2.5.1.20160104-10
Severity: important
xindy(1) does various funny things if a filename contains characters
that are not usually used in filenames:
$ touch '>t0'
$ ls -l
total 0
-rw-rw-r-- 1 zefram zefram 0 Jul 17 01:21 '>t0'
$ xindy '>t
Package: psutils
Version: 1.17.dfsg-4
Severity: minor
If the extractres(1) program attempts to display a usage message, it
gets its own name wrong:
$ extractres -q
Usage: 1 [-merge] [file]
$
-zefram
certain characters that are not
usually used in filenames:
$ ls -l
total 4
-rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0
$ ts %F '>t1'
$ ls -l
total 4
-rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0
-rw-rw-r-- 1 zefram zefram 0 Jul 17 00:49 t1
$ echo c > 't2 '
$ ts %F '
Package: psutils
Version: 1.17.dfsg-4
Severity: important
extractres(1) does various funny things if a filename contains characters
that are not usually used in filenames:
$ touch '>t0.ps'
$ ls -l
total 0
-rw-rw-r-- 1 zefram zefram 0 Jul 17 00:25 '>t0.ps'
$ extractre
x27;t even an attempt to open the additional files:
$ echo a >t0
$ echo b >t1
$ markdown t0 t1
a
$ markdown t1 t0
b
$ markdown t2doesnotexist
Can't open t2doesnotexist: No such file or directory at /usr/bin/markdown line
221.
$ markdown t0 t2doesnotexist
a
$
-zefram
Package: markdown
Version: 1.0.1-10.1
Severity: important
markdown(1) does various funny things if a filename contains characters
that are not usually used in filenames:
$ echo a > '>t0'
$ ls -l
total 4
-rw-rw-r-- 1 zefram zefram 2 Jul 16 23:20 '>t0'
$ markdown '
= 15
write(2, "\33[33mhint: \tgit branch -m "..., 36) = 36
And a configuration extract:
$ sed -n 6,7p ~/.gitconfig
[color]
ui = never
-zefram
tion, maybe the checking
step and non-checking conversion recombine into an ordinary checking
conversion of the kind you already have.
-zefram
es its input while checking the encoding. Apparently it's
being optimised incorrectly, to a pure identity transformation without
the checking.
-zefram
y the
same condition.
-zefram
he use of these concepts
for efficient job control. I use the commands "fg" (foregrounding the
current job) and "%-" (foregrounding the previous job) all the time,
and I'm thus heavily affected by this bug.
-zefram
of the name that was
supplied on the command line. It must pass to the file syscalls the
same octet string that was supplied as a command line argument, without
assuming anything about its syntax.
If it cannot be made to handle arbitrary filenames correctly, then
clojure(1) must at least detect that it can't handle the specified
filename. It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose. Furthermore,
this limitation must be documented.
-zefram
lace of the original job.
The attached patch therefore fixes this bug in a very simple way, by
deleting the logic that switches focus to the subjob. With this patch
in place, the above test case produces this pleasing output:
% t0 () { sleep 1000; }
% t0
^Zzsh: suspended t0
% echo foo
foo
% :
% jo
as a command line argument, without
assuming anything about its syntax.
If it cannot be made to handle arbitrary filenames correctly, then
node(1) must at least detect that it can't handle the specified filename.
It must signal an error on any filename it can't handle, and not use
any mangled form of the filename for any purpose. Furthermore, this
limitation must be documented.
-zefram
console's ownership set to the invoking user, for the duration of its
use by the X server.
-zefram
yellow
text is now rendered in white, until you get up to the first post-list
text "foo", at which point all the text rendered on the screen, plus
the help text, turns yellow.
-zefram
the documentation should instead use the IEC prefixes "kibi-",
"mebi-", and "gibi-".
-zefram
reality-is-NSFW deal.)
libquvi ought to work around the age gate. It should not impose this
censorship on its users.
I found a discussion of the same issue being addressed in some other
code at <https://github.com/fent/node-ytdl-core/issues/19>. Maybe the
fix they used can be adopted.
-zefram
y file,
it rewrites the display of the rendered x0.html file, and then rewrites
the status line back to its normal state. It then rewrites the rendered
display again with different colouration, and finally waits for input.
-zefram
which the link was selected. The user can continue navigating
in the displayed page, as if ey had never selected the link to the other
page, or as if loading had failed due to a network problem (though no
error message is displayed). This is not long-standing behaviour in my
experience: it is new and problematic.
-zefram
other activity between attempts, doesn't
make it succeed. After a successful repeated page load, further attempts
to load the same page again go back to failing.
-zefram
specify size
or position should continue to not set those bits, and should accept
whatever geometry the window manager imposes as a result. mplayer should
never be moving or replacing the window after it has been mapped.
-zefram
te(1, "\33[33mcommit 613abc6d16e99bd9834fe6afd79beb61a3a4734d\33[m\n",
56) = 56
Given the configulation, that line should be free of escape sequences.
-zefram
etter to leave the -p output completely unchanged,
and add a new command-line option that provides the same information in
the new format.
-zefram
the existing number
is still whitespace-delimited and the first thing following the colon,
so it's still easy to parse out in a backward-compatible way. What do
you think?
-zefram
Michael Kerrisk (man-pages) wrote:
>fixed in upstream quite a long time back (2014).
Ah, cool. The version at
<http://man7.org/linux/man-pages/man2/adjtimex.2.html> is fine.
-zefram
in either microseconds or nanoseconds, depending on the STA_NANO status
flag, just like timex.time.tv_usec.
-zefram
ermitting input option values to use units (like
"-o +200us", whose meaning would be unaffected by STA_NANO).
-zefram
diff -ur adjtimex-1.29.orig/adjtimex.8 adjtimex-1.29/adjtimex.8
--- adjtimex-1.29.orig/adjtimex.8 2009-03-12 00:31:07.0 +
+++ adjtimex-1.29/adjtimex.
*nanoseconds*. The true raw time
is different from both of the values shown, and for the call made above
should have been shown as
raw time: 1490397277s 23837440ns = 1490397277.023837440
-zefram
id not configure the package during installation.
The default configuration shouldn't be mucking about with the running
system in uninvited ways.
-zefram
Control: tags -1 -moreinfo
thanks
aa37b1a24855e760e71ee9a20a1a90 is the first bad
commit\n", 65) = 65
20408 open("/home/zefram/.gitconfig", O_RDONLY) = 3
20408 read(3, "[user]\n\tname = Zefram\n\temail = zef...@fysh.org\n\tsigningkey
= 0x8E1E1EC1\n\n[color]\n\tui = never\n", 4096) = 93
20
unhighlighted
instance). Obviously this is quite an inconvenience when one wants to
c&p some text including the search string.
-zefram
to depend on the variable more than it used to.
Fixed in Data-Alias-1.20, now on CPAN.
-zefram
C language level of
which I was not previously aware. I can probably track it down from here.
-zefram
ailing setup would
try figuring out which part of the perl build makes the difference.
Something I haven't yet tried varying is the C compiler. I'm using Debian
gcc 4.7.2-5, which doesn't understand the -fstack-protector-strong option
that the failing perls are built with.
-zefram
les[i], argv[i],
ret);
system(maps_cmd);
if(ret) exit(1);
}
exit(0);
}
$ gcc -std=c99 try_dl.c -ldl -o try_dl
$ ./try_dl /usr/lib/x86_64-linux-gnu/libperl.so.5.20
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/home/zefram/tmp/try_dl
/lib/x86_64-linux-gn
h the clock.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
critical function is not documented seriously
damages the usability of this program to people who don't already know
how to use it.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
thus theoretical
and untested, but I have considerable confidence in it.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ality:
$ ls -l /proc/self/fd
total 0
lrwx-- 1 zefram zefram 64 Apr 3 16:45 0 -> /dev/pts/13
lrwx-- 1 zefram zefram 64 Apr 3 16:45 1 -> /dev/pts/13
lrwx-- 1 zefram zefram 64 Apr 3 16:45 2 -> /dev/pts/13
lr-x-- 1 zefram zefram 64 Apr 3 16:45 3 -> /proc/5271/fd
so th
t;15 byte >2 \b, line size 2^%d byte
>>14 byte >2 \b, page size 2^%d byte
>>13 byte &1
>>>13 byte >1 \b, max fanout %d
0 lequad =0xc693dac5ed5e47c2 Hash::SharedMem data file, little-endian
>8 lequad <0x100
>>8 byte >2 \b, line size 2^%d byte
em starting by
downloading the source as shown. If you have difficulty reproducing it,
obviously I can supply these files on request.
I see this on i386 but not on an amd64 machine that has otherwise the
same versions of things installed.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-r
tom character (whose identity varies)
following the spurious space. The phantom character vanishes upon ESC,
but the space remains.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
e Perl module Apache::SizeLimit) that makes that mistake.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16360
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16361
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16359
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16356
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16357
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16362
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16358
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16363
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16364
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
es the behaviour of guile-1.8, which classifies
+inf.0 and -inf.0 as integers, and +nan.0 as rational but not integer.
guile-2.0 follows R6RS in treating all three of these values as real
but not rational. (Mathematically, infinities are not real, and NaN is,
as the acronym says, not a number.)
quot;frisk"]
155: 2 [show-help # #]
In ice-9/boot-9.scm:
788: 1 [call-with-input-file #f ...]
In unknown file:
?: 0 [open-file #f "r" #:encoding #f #:guess-encoding #f]
ERROR: In procedure open-file:
ERROR: Wrong type (expecting string): #f
$
-zefram
--
To UNSUBSCRIBE, email
n: info guile 'Using Guile Tools'
$
Subcommands mentioned in the guile documentation are actually available,
despite not being listed.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
more sensible for guild to unconditionally and unconfigurably
use /usr/bin/guile-2.0.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
. Test case:
$ echo '(display "aaa\n")' >t13
$ echo '(display "bbb\n")' >t14
$ guile-2.0 t13
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/gui
"a" "b" "c")
$ guile-1.8 -s t11 a b c
("t11" "a" "b" "c")
$ guile-2.0 '\' t11 a b c
("t11" "a" "b" "c")
$ guile-2.0 -s t11 a b c
;;; note: auto-compilation is enabled, set GU
e-2.0 --no-auto-compile t8
5
$ guile-2.0 t8
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t8
;;; WARNING: compilation of /home/zefram/usr/guile/t8 failed:
;;; ER
E=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t9
;;; compiled
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t9.go
(5 . 2)
(5 . 2)
$ guile-2.0 t9
(5 . 2)
(5 . 2)
In the test case, the explicitly-constructed pair aaa i
t happens to the second script in this sequence:
$ echo '(display "hello world\n")' >t10
$ guile-2.0 t10
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t10
;;; compi
oad-stack #]
1650: 4 [#]
In unknown file:
?: 3 [primitive-load "/home/zefram/usr/guile/t6"]
In ice-9/eval.scm:
387: 2 ^Z
zsh: suspended guile-2.0 --no-auto-compile t6
$ jobs -l
[1] + 32574 suspended guile-2.0 --no-auto-compile t6
$ ps vw 32574
PID TTY STAT TIME MAJFL TRS DR
. 58) . 57) . 56) . 55) . 54) . 53) . 52) . 51) . 50) . 49) .
48) . 47) . 46) . 45) . 44) . 43) . 42) . 41) . 40) . 39) . 38) . 37) . 36) .
35) . 34) . 33) . 32) . 31) . 30) . 29) . 28) . 27) . 26) . 25) . 24) . 23) .
22) . 21) . 20) . 19) . 18) . 17) . 16) . 15) . 14) . 13) . 12) . 11) . 10) .
ails (as the file auto-compilation does).
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
x y))
(write (p 2 3))
(newline)
$ guile-1.8 t2
5
$ guile-2.0 --no-auto-compile t2
5
$ guile-2.0 t2
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t2
;;; WARNING: compilation of /home
>On Thu, Jan 02, 2014 at 11:44:09AM +0000, Zefram wrote:
Thomas Dickey wrote:
>which translation was performing the backspace?
I'm not sure what you mean by this question. The relevant item in the
translations resource is
BackSpace: string(0x08)
I have other translation i
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/lucifex/on_guile/t0
;;; WARNING: compilation of /home/zefram/usr/lucifex/on_guile/t0 failed:
;;; ERROR: #. read expansion found and read-eval? is #f.
hello world
$
I can turn off the auto-compilation from within t
e example in a
different section of the doc), and has no mention of translations being
applied differently depending on focus.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
p to xterm.
It seems to only affect xterm translations. But I wouldn't be too
surprised if the bug turns out not to be in the xterm source at all but
in one of the X libraries.
>(nor do I see a way to reproduce the bug)
Yes. It only happens apparently at random.
-zefram
--
To UNSUBS
Package: nvi
Version: 1.81.6-8.2
Severity: minor
The "escapetime" settable option in nvi is not documented in its man page,
unlike the majority of options.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
optimal will depend on the individual. It's a matter
between the human and eir shell; it is not apt-get's place to interfere
with that relationship.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
put at all.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
gcc-4.7-locales 4.7.2-5
gcc-4.7-multilib4.7.2-5
gcc-multilib4:4.7.2-1
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
) have been reorganised between
Debian stable and current github, but still claim that "-o foo.pasm"
will produce pasm output.
(I'm using the github checkout because that gets me a Parrot with the
bigint library built in. Think I'm going to submit a wishlist ticket
about having tha
$P0 = 1234567890123456789
$P1 = $P0 * $P0
say $P1
.end
$ parrot t6.pir
no bigint lib loaded
current instr.: 'main' pc 6 (t6.pir:4)
$ ./from_github/parrot t6.pir
1524157875323883675019051998750190521
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.o
t2.pasm
t2.pasm: Parrot bytecode 106.0, 8 byte words, little-endian, x86 12 byte long
double floats, Parrot 0.0.0
It's producing pbc output regardless of the output filename.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe&q
files elsewhere in the Parrot source
tree (src/ops/*.ops) whereas most of the documentation is stored directly
in the source tree.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
@" moving along as more text is entered before it.
It disappears at the end of text entry (following Esc). There's no
permanent effect on the file content.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dow,
in which it successfully shows the video. This bug report is concerned
with mplayer2's failure to ultimately show the video full-screen.
-zefram
$ mplayer -fs t0.mp4
MPlayer2 UNKNOWN (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to
y the user. The result is that a window manager that applies
its own positioning logic in preference to program-supplied positions,
but honours user-supplied positions, will override the user-supplied
position with mplayer. The same goes for the USSize hint.
-zefram
--
To UNSUBSCRIBE, email to d
cifically want to use it. Applications that turn the
mode on, such as w3m, effectively break normal xterm usage. It would
be nice to have an option that prevents mouse tracking being engaged,
along the lines of the existing allowTitleOps option that can prevent
unwanted changes of window title.
-z
toggling BS/DEL in case there
was some interaction with the state of that option, but apparently the
state of the option is irrelevant, the fix just comes from something
triggered by the process of toggling it.) The fix is only temporary:
it'll later change to ^? again, as mysteriously as the
report is essentially a revival of Bug#617362. That ticket got
closed without actually being resolved, due to confusion with the related
but distinct Bug#617361 that was deemed not-a-bug. See also Bug#187138
concerning nearly-identical behaviour of Galeon, and Bug#668850 concerning
related behav
1 - 100 of 138 matches
Mail list logo
