When creating many Windows (e.g. B *.go) and then attempting to manipulate Windows, we get black regions.

The presence of the thin black rectangle in the margin shows that new content is being added with Frame.Insert but that Text.Redraw has not been invoked to fill the entire padded rectangle.

I think this might be a problem in the column code?

Frame has some bugs. Make it more robust.

Untested: main.plumbthread(): /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/look.go:48 +0x204
Got a message: &{B edit /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood text 0xc4204de2a0 [47 85 115 101 114 115 47 114 106 107 114 111 101 103 101 47 116 111 111 108 115 47 103 111 112 107 103 47 115 114 99 47 103 105 116 104 117 98 46 99 111 109 47 114 106 107 114 111 101 103 101 47 101 100 119 111 111 100 47 46 103 105 116 47 67 79 77 77 73 84 95 69 68 73 84 77 83 71]}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1139453]
goroutine 7 [running, locked to thread]:
github.com/rjkroege/edwood/frame.nrune(...)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/frame/util.go:144
github.com/rjkroege/edwood/frame.(*Frame).strlen(0x12d8ac0, 0x1, 0x13e)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/frame/draw.go:278 +0x43
github.com/rjkroege/edwood/frame.(*Frame)._draw(0x12d8ac0, 0x4ed, 0x13e, 0xc4204de300, 0x4ed)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/frame/draw.go:248 +0x1f0
github.com/rjkroege/edwood/frame.(*Frame).bxscan(0xc420338d80, 0xc420200000, 0x5f, 0x5f, 0xc4202b97f0, 0x0, 0xc4202b9740)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/frame/insert.go:104 +0x88e
github.com/rjkroege/edwood/frame.(*Frame).Insert(0xc420338d80, 0xc420200000, 0x5f, 0x5f, 0x0)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/frame/insert.go:165 +0x16c
main.(*Text).Fill(0xc4202c8418)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/text.go:545 +0xc0
main.(*Text).Redraw(0xc4202c8418, 0x4ed, 0x122, 0x800, 0x15a, 0xc420188000, 0xc4200c48c0, 0x334)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/text.go:143 +0x268
main.(*Text).Resize(0xc4202c8418, 0x4ed, 0x122, 0x800, 0x15a, 0x1, 0x5d4)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/text.go:165 +0x1c0
main.(*Window).Resize(0xc4202c8400, 0x4cc, 0x122, 0x800, 0x2e4, 0xc420160000, 0x0)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/wind.go:254 +0x549
main.(*Column).Add(0xc420001800, 0x0, 0x0, 0xffffffffffffffff, 0x1)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/col.go:140 +0x45c
main.makenewwindow(0x0, 0x4e)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/util.go:225 +0x2b6
main.openfile(0x0, 0xc4201628c0, 0x4)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/look.go:765 +0x8b
main.plumblook(0xc4200b2ae0)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/look.go:248 +0x121
main.mousethread(0xc4200ce0c0)
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/acme.go:291 +0x310
created by main.main
        /Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/acme.go:168 +0x8a1

Some of the files have not been run through gofmt. Enabling automatic testing with something like Travis CI may be helpful here. Also, the tests should not require running go build before running go test, and they should not require a $DISPLAY being available.

Edwood could stand to have a new and improved text storage system. We've talked about various notions. A piece table with deltas would seem to be the most reasonable choice.

• Create internal/dumpfile package which uses JSON to store dump data. This breaks compatiblity with acme. However, this will make it easier to extend the dump file, storing more data, adding support for things like multi-line tags. There is a proposed solution to add multi-line tags in acme which uses hacks like using unicode PUA: https://github.com/9fans/plan9port/pull/153

• We can now save and load multi-line tags

• Fix loading dump file with no windows (see #206)

• Remove temporary file containing window body after loading Unsaved window

• Move LoadFont into internal/dumpfile package

• Remove lookid (commened out C code) because it's already been implemented as Row.LookupWin.

Fixes #206

It seems that (*Window).body.file can be nil when a writing to an error window. I get the following panic when Deleting an error window while a program is writing to it:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb8 pc=0x1401cc2]

goroutine 50 [running]:
main.(*File).AllText(0x0, 0xc000095d18)
	/go/src/github.com/rjkroege/edwood/file.go:309 +0x22
main.(*Window).Lock(0xc000325800, 0x58)
	/go/src/github.com/rjkroege/edwood/wind.go:323 +0x8b
main.errorwin(0xc0000e4100, 0x58, 0x0)
	/go/src/github.com/rjkroege/edwood/util.go:154 +0x84
main.xfidwrite(0xc0000d8160)
	/go/src/github.com/rjkroege/edwood/xfid.go:438 +0x399
main.xfidctl(0xc0000d8160, 0x15cffe0, 0xc0001880e0)
	/go/src/github.com/rjkroege/edwood/xfid.go:39 +0x9c
created by main.xfidallocthread
	/go/src/github.com/rjkroege/edwood/acme.go:625 +0x221

It seems to be dependent on how fast the program is writing. If I run the program below with Button 2 in a directory window (so output goes to +Errors), and then close the +Errors window, The panic above happens.

package main

import (
	"fmt"
	"time"
)

func main() {
	var i int
	for {
		fmt.Printf("%d, ", i)
		i += 1
		time.Sleep(200 * time.Millisecond)
	}
}

Making sure thatw.body.file is not nil prevents the panic.

The B command failed to open anything.

Console output (possibly suspect) at roughly the same time:

9pserve: announce unix!/tmp/ns.rjkroege.:0/acme: Address already in use
acme: can't post service: 9pserve failed

Hi there,

I'm new to edwood, it's a great project, thanks for your work.

I'm trying to figure out how to set up the plumber and plumb rule with my edwood.

As on plan9, I can used cat rules.txt | 9p write plumb/rules, but not sure how to do this on Windows 11.

Can you please give me some direction for this?

Go 1.10 is more than 1 year old now and it's no longer supported upstream. Go's release policy is to support last two major releases with critical bug fixes.

This will also give us quicker results from Travis CI.

The current release v0.1 is not a semantic version. It should be v0.1.0. The go command only works with semantic version:

$ echo $GO111MODULE 
on
$ go get github.com/rjkroege/edwood  # go can't find latest release
go: finding github.com/rjkroege/edwood latest
go: downloading github.com/rjkroege/edwood v0.0.0-20190601162916-aabee0854dca
go: extracting github.com/rjkroege/edwood v0.0.0-20190601162916-aabee0854dca
$ go get github.com/rjkroege/[email protected]
go get github.com/rjkroege/[email protected]: no matching versions for query "v0.1"
$ go get github.com/rjkroege/[email protected]
go: finding github.com/rjkroege/edwood v0.1.0
go: finding github.com/rjkroege/edwood v0.1.0
go: finding github.com v0.1.0
go: finding github.com/rjkroege v0.1.0
go get github.com/rjkroege/[email protected]: unknown revision v0.1.0
$

A v0.1.0 tag should be added. Also, I think we're due for a new release, maybe v0.2.0?

in Acme, win would regularly lock up in some fashion. Like 1/week.

In Edwood, win also regularly locks up. It just does it a lot more frequently: like every few commands.

It looks to me like the event file does not report chorded events as it does in acme, and as it says in acme(4).

acme(4):

[The event flag will contain bit] 8 if the command has an extra (chorded) argument; if so, two more complete messages will follow reporting the argument (with all numbers 0 except the character count) and where it originated, in the form of a fully-qualified button 3 style address.

In acme, selecting an Edit replacement, e.g. ,s|foo|bar|g and then chording the edit command Button3-1, results in the following events:

Event: [Mx19 23 9 4 Edit]
Event: [Mx0 0 0 12 ,s|foo|bar|g]
Event: [Mx0 0 0 0 ]

This matches the description in the manual page.

In Edwood however, the 8th bit of the flag is not set when chording, and no subsequent messages are received:

Event: [Mx21 25 1 4 Edit]

To be clear, chording appears to behave correctly in Edwood windows, but the events don't show up in the events file as expected.

Stack trace: goroutine 363 [running]: runtime/debug.Stack() /usr/local/go/src/runtime/debug/stack.go:24 +0x65 runtime/debug.PrintStack() /usr/local/go/src/runtime/debug/stack.go:16 +0x19 main.(*cmdParser).atnl(0xc000190340?) /Users/flux/dev/edwood/edit.go:328 +0x9c main.(*cmdParser).collecttext(0xc000190340) /Users/flux/dev/edwood/edit.go:430 +0x166 main.(*cmdParser).parse(0xc000190340, 0x0) /Users/flux/dev/edwood/edit.go:535 +0x579 main.(*cmdParser).parse(0xc000190340, 0x0) /Users/flux/dev/edwood/edit.go:526 +0x6bf main.editthread(0x6500000070?) /Users/flux/dev/edwood/edit.go:155 +0x2b created by main.editcmd /Users/flux/dev/edwood/edit.go:229 +0x2fa panic: runtime error: slice bounds out of range [9753:0]

Was in win, did a git command that pokes edwood via the E edit command, and poof. The file being opened was only 1628 characters, so that's likely not it. I do, however, have a Watch window going which refreshes furiously, all the time, and is the source of most of my crashes, I think.

Open edwood (top of tree, master) on a file containing

            <data inType="win:AnsiString" name="Description" />
            <data inType="win:Int32" name="Depth" />
            <data inType="win:AnsiString" name="Description" />
            <data inType="win:Int32" name="Depth" />
            <data inType="win:Float" name="Duration (ms)" />
Edit ,x/^[^"]*"/d

Execute the edit command, then Undo.

Changing window sizes (e.g. as a result of going fullscreen / not-fullscreen in response to an altered screen configuration seems to round the column widths in an unstable way. This is annoying. (While I'm at it, Edwood should be able to add / remove columns based on the width of the window. Ideally via an external helper.)

On Windows, the standard line ending is CrLf. Although edwood is a solid Windows application, I think it should handle native Windows line endings more gracefully than by showing them as "unknown character".

@rjkroege, Based on our discussion in #417, I created this proof-of-concept for editing things remotely in Edwood.

It's pretty rough, but it's somewhat working. I don't expect this to ever be merged, but wanted to get your opinion.

My export9p needs to be installed on the remote host, since it uses that to serve 9p back through ssh to edwood.

Commands are also run through ssh in a somewhat ugly way. The Setenv doesn't seem to work for me.

Forwarding a unix connection for $(namespace)/acme is required for win commands and other acme stuff to work, which I haven't included yet.

You should be able to test it with edwood -R "user@host:22"