Re: [dev] another text user interface for sam

From: Connor Lane Smith <cls_AT_lubutu.com>
Date: Fri, 26 Feb 2016 15:56:17 +0000

You certainly aren't alone. I expect I'm the local expert on trying to
draw blood from that stone.

The problem, aside from my not having enough time to do any worthwhile
hobby programming at the moment, is that communication between sam and
samterm is an ad hoc binary protocol, with absolutely zero
documentation (as confirmed by Rob Pike), which is quite specifically
tailored to those two programs' needs. I did manage to get the two to
communicate enough to open new windows and do basic editing of text,
but it's pretty fiddly, and I'm not sure I ever got the locking quite
right. (Certain actions cause the terminal implicitly to 'lock' so
that the user cannot interact with it, after which the editor proper
sends an 'unlock' message. I'm not sure exactly when this happens.)
Someone with more time on their hands may be able to get further than
I did with this, although there are certain UI limitations inherent in
the protocol.

This is a source of continual frustration for me. It's got to the
point where if I need to make some trickier changes to a structured
file format like BibTeX, I'll open up samterm and make the changes
with that. Literally the best tool for the job is an editor from the
'80s that hasn't been supported by anyone in god knows how long.
Beggars belief. I do think a better longterm solution would be to
implement a whole new editor with sregexps, as a reimplementation
could also support proper streaming and maybe even an awk dialect (as
described in Pike's paper on structural regular expressions), but
obviously that would require a good deal of work.

In any case, if there *were* an attempt, with more manpower, either to
reverse engineer the binary sam protocol or to implement a new editor,
then I'd be very happy to lend a hand.

Thanks,
cls
Received on Fri Feb 26 2016 - 16:56:17 CET

This archive was generated by hypermail 2.3.0 : Fri Feb 26 2016 - 17:00:12 CET