[9fans] acme bug

[9fans] acme bug

[Richard C Bilson]

Consider the 3-line range

xxx
special
yyy

after applying the sam-command

x g/special/ {
i
#top
.
a
#bottom
.
}

In sam, I get the result

xxx
#top
special
#bottom
yyy

which is what I expect.  If I try the same in acme, however, extra
blank lines are displayed.  What's worse is that acme's internal data
structure seems to be corrupted; if I Put and then Get, the file is cut
off after the second line.

Note: I've observed this only on the Unix acme, and I'm not currently
able to test on Plan 9.

Re: [9fans] acme bug

[rog]

> Note: I've observed this only on the Unix acme, and I'm not currently
> able to test on Plan 9.

the same behaviour happens in plan 9 too. definitely looks
like a bug.

a simple workaround is to use:

x g/special/ {
i/#top\n/
a/#bottom\n/
}

instead, which seems to work ok.

Re: [9fans] acme bug

[Rob Pike]

This one is easy. In src/cmd/acme/edit.c, after the line
in collecttext() that reads
		s->r[s->n-2] = '\0';
add a line
		s->n -= 2;
Sam has zero-terminated strings, acme doesn't.  This
was a porting bug.  This needs fixing in Plan 9 as well
as plan9port.

-rob

[9fans] acme bug

[Micah Stetson]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

This is absolutely consistent on my system:
1. Open acme.bug (attached) or any file with three or more CRLF terminated
    lines
2. Button 2 on 'Edit ,x/
/d' (that's ,x/<CR>/d if your mailer messes it up)
3. A +Errors window opens with this message: elogapply: can't happen 4 4 3

I updated from sources this morning.  I'm not sure how long this
behavior has been there, I just noticed it yesterday looking at some
DOS text files.  I should probably have hunted down the problem, but I
figured it would be so obvious to somebody here that I would just be
wasting time.

Thanks,

Micah

[-- Attachment #2.1: Type: text/plain, Size: 308 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=acme.bug
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #2.2: acme.bug.suspect --]
[-- Type: application/octet-stream, Size: 4 bytes --]

Re: [9fans] acme bug

[Russ Cox]

I know what's wrong but I think it's going to be a pain to fix.

[9fans] acme bug

[rob pike]

Russ found a stupid bug in the new Acme edit feature, a failure to
convert some Sam code properly.  The bug is that Acme crashes
instead of just complaining in certain ordinary circumstances.
The fix is trivial: change calls to error into calls to editerror.
This diff might not be exactly right for the released source, but
it'll be close enough to figure out what to do:


acme% diff -n /n/dump/2000/1224/sys/src/cmd/acme/ecmd.c ecmd.c
/n/dump/2000/1224/sys/src/cmd/acme/ecmd.c:570 c ecmd.c:570
< 		error("no name specified for 'w' command");
---
> 		editerror("no name specified for 'w' command");
/n/dump/2000/1224/sys/src/cmd/acme/ecmd.c:956 c ecmd.c:956
< 				error("address");
---
> 				editerror("address");
/n/dump/2000/1224/sys/src/cmd/acme/ecmd.c:965 c ecmd.c:965
< 				error("address");
---
> 				editerror("address");