#424 File position reverted by other joe instances

[Egmont Koblinger]

Create a file using joe A. Type in some contents. Save it, and exit joe with the cursor staying in let's say row 5.

Optionally re-execute joe A to confirm that the cursor is automatically placed in row 5. Quit joe again.

In another terminal, type joe B, or even just simply joe, to start editing a new file.

Back in the first terminal, type joe A to again edit that file. Type something, move the cursor to let's say row 10, and quit joe.

Optionally execute joe A again to confirm that the cursor is in row 10. Quit it.

In the second terminal, exit from that joe B. You don't even have to save that file.

In the first terminal, again execute joe A. The cursor is in row 5, except of the expected row 10.

Apparently at startup joe remembers the full contents of .joe_state's file_pos, and upon exiting it updates its own record and writes out everything, including the state of other files from a long ago.

It should, upon exiting, re-read that file and only update its own record, leave everything else at their possibly updated states.

[Joe Allen]

Right now there is an in-core database of file positions which is loaded at startup and then updated whenever someone closes a window. So one way to fix this problem is to update the file position part of the state file whenever someone closes a window- basically eliminate the in-core clone of the file positions and have only one global copy of this information. Likewise, when you open a file, the editor would get the most recent file position instead of what it was when the editor was invoked.

I'm thinking of it this way because it might be nice if other things in the state file were continuously updated like this. For example, it might be nice if search and file history were instantly shared between all running instances of the editor- it's similar to the problem of shared command line history with bash. I say "might be" because sometimes shared history like this is annoying - in bash you hit up arrow and not get the command previously entered in that window.

[Egmont Koblinger]

Joe, you are incredible... you keep disappearing for ~10 years and then come back and do another batch of work. I can hardly wait for an improved 4.7 (or 5.0?) release :)

I personally hate bash's shared command line idea, and would similarly hate it in joe. I expect the Up arrow to bring up the previous entries of that joe instance. Shared history just isn't a good match for my workflow.

So my bugfixing request is simply: When joe writes .joe_state, it should read the most recent state of things and only updates its own stuff.

What I did not realize so far: the same goes for the search history, too. Start joe A, start joe B. In joe A search for aaa, in joe B search for bbb. Quit joe A, then quit joe B. The search history only contains bbb.

Again, when writing the search history, it should read back the current state of the file and append the entries that were newly created in its own session.

This should hopefully be easier to implement than a full-blown shared history.

If you implement shared history, I'd still strongly prefer to be able to turn that off, yet receive the fix for these bugs. Thanks a lot in advance! :)