On Fri, 15 Sep 2006, Nicolas Duboc wrote:
On Thu, Sep 14, 2006 at 06:30:17PM +0100, Reuben Thomas wrote:
You're basically right, but I'm not going to because I don't have the
will to write and debug the code. I should perhaps instead have
bumped the version number to 2.4.
It would not
On Sun, Sep 17, 2006 at 03:09:13PM +0100, Reuben Thomas wrote:
I'm making a new release, 2.2.22, which adds an entry to the FAQ and
mentions the change in boolean syntax in NEWS.
Ok, I will be offline for one week from now. I will look at this when I
come back.
Thanks,
--
Nicolas
On Thu, Sep 14, 2006 at 06:30:17PM +0100, Reuben Thomas wrote:
On Thu, 14 Sep 2006, Nicolas Duboc wrote:
I think a better solution is to support, or at least detect, previous
file format.
You're basically right, but I'm not going to because I don't have the will to
write and debug the
On Wed, Sep 06, 2006 at 11:46:13PM +0100, Reuben Thomas wrote:
On Wed, 6 Sep 2006, Robert Millan wrote:
It's likely that many other users have some variant of the old ~/.zile and
run
into problems. Given the situation, I think some warning should be added.
Some
suggestions:
-
On Wed, Sep 13, 2006 at 08:59:07PM +0100, Reuben Thomas wrote:
I've found and fixed this bug in zile 2.2.21 (out imminently).
I confirm the bug is not reproducible with 2.2.21 on pergolesi.d.o
(amd64) and merulo.d.o (ia64).
Thanks,
--
Nicolas Duboc [EMAIL PROTECTED]
pgpLhPQgwMU11.pgp
On Thu, 14 Sep 2006, Nicolas Duboc wrote:
Debconf warning are supposed to be for really important notes. I
don't think that this problem is important enough. Don't remember that
the user is warned through the minibuffer of the bad configuration of
the config file. Also this solution would
On Tue, 12 Sep 2006, Nicolas Duboc wrote:
However it seems that the caracter (0xFF) is inserted when the
error message is deleted from the minibuffer.
Got it. Thanks for the clarification. I'll try to find the cause.
--
http://rrt.sc3d.org/ | think tank, n. a safe container for noxious
I've found and fixed this bug in zile 2.2.21 (out imminently). It was
only 64-bit specific because of a(n un)lucky combination of
circumstances; basically, I was assuming an int was positive, but it
didn't matter on 32-bit machines because the only negative value it ever
took was -1, which ==
On Wed, Sep 13, 2006 at 08:59:07PM +0100, Reuben Thomas wrote:
I've found and fixed this bug in zile 2.2.21 (out imminently).
Nice :)
It was
only 64-bit specific because of a(n un)lucky combination of
circumstances; basically, I was assuming an int was positive, but it
didn't matter on
On Wed, 13 Sep 2006, Robert Millan wrote:
On Wed, Sep 13, 2006 at 08:59:07PM +0100, Reuben Thomas wrote:
I've found and fixed this bug in zile 2.2.21 (out imminently).
Nice :)
It was
only 64-bit specific because of a(n un)lucky combination of
circumstances; basically, I was assuming an int
On Mon, Sep 11, 2006 at 07:48:33PM +0100, Reuben Thomas wrote:
I've now investigated this bug with zile 2.2.20 and the sample .zile file
from 2.2.13 (as per the report) on an x86_64 machine (sadly,
not Debian, I couldn't arrange that; it's running CentOS 4.1).
I do of course get the no
On Fri, 8 Sep 2006, Robert Millan wrote:
Funny. Seems like it only happens on amd64. More details:
- It happens a few (~3) seconds after you save your file.
- If during this period you hit another key (arrows, type stuff, etc),
then the spurious 0xFF byte won't be inserted.
I have no
I've now investigated this bug with zile 2.2.20 and the sample .zile
file from 2.2.13 (as per the report) on an x86_64 machine (sadly, not
Debian, I couldn't arrange that; it's running CentOS 4.1).
I do of course get the no such file or directory message, but that is
a normal minibuffer
On Wed, Sep 06, 2006 at 11:44:30PM +0100, Reuben Thomas wrote:
On Wed, 6 Sep 2006, Robert Millan wrote:
On Wed, Sep 06, 2006 at 06:22:55PM +0100, Reuben Thomas wrote:
I also can't see why a character should be inserted by save-buffer, and
I can't make it happen either.
If you can repro
On Mon, 4 Sep 2006, Robert Millan wrote:
Please could this be reverted? It causes zile to print a No such file
or directory error during runtime, adds a weird char to your buffer
(0xff), and your usual /tmp/foo~ file is not there anymore.
I'm puzzled by the above behaviour. I can't repro it
On Mon, 4 Sep 2006, Robert Millan wrote:
$ strace zile /tmp/foo 2 /tmp/strace.log
$ grep ENOENT /tmp/strace.log
[...]
rename(/tmp/foo, /home/rmh/.backup/!tmp!foo~) = -1 ENOENT (No such
file or directory)
[...]
I think you've been caught out by the change in booleans: true is now
t and false
On Wed, Sep 06, 2006 at 06:12:02PM +0100, Reuben Thomas wrote:
On Mon, 4 Sep 2006, Robert Millan wrote:
$ strace zile /tmp/foo 2 /tmp/strace.log
$ grep ENOENT /tmp/strace.log
[...]
rename(/tmp/foo, /home/rmh/.backup/!tmp!foo~) = -1 ENOENT (No such
file or directory)
[...]
I think
On Wed, Sep 06, 2006 at 06:22:55PM +0100, Reuben Thomas wrote:
On Mon, 4 Sep 2006, Robert Millan wrote:
Please could this be reverted? It causes zile to print a No such file
or directory error during runtime, adds a weird char to your buffer
(0xff), and your usual /tmp/foo~ file is not
On Wed, 6 Sep 2006, Robert Millan wrote:
It's likely that many other users have some variant of the old ~/.zile and run
into problems. Given the situation, I think some warning should be added. Some
suggestions:
- Detect the old syntax and abort.
- Add a debconf warning (with high
On Wed, 6 Sep 2006, Robert Millan wrote:
On Wed, Sep 06, 2006 at 06:22:55PM +0100, Reuben Thomas wrote:
I also can't see why a character should be inserted by save-buffer, and
I can't make it happen either.
If you can repro either bug in 2.2.19 (released about now) I'd be most
grateful for
Package: zile
Version: 2.2.18-1
Severity: important
$ strace zile /tmp/foo 2 /tmp/strace.log
$ grep ENOENT /tmp/strace.log
[...]
rename(/tmp/foo, /home/rmh/.backup/!tmp!foo~) = -1 ENOENT (No such
file or directory)
[...]
Please could this be reverted? It causes zile to print a No such file
or
21 matches
Mail list logo
