Re: [lmi] Return of the secret decoder ring

[Greg Chicares]

On 2018-11-07 23:17, Vadim Zeitlin wrote:
> On Wed, 7 Nov 2018 22:56:20 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> It's handy to modify data files in (by default) /opt/lmi/data
> GC> experimentally during an lmi session. MST->XST obfuscation
> GC> has made that less convenient.
> 
>  Yes, I've already run into this too. I was thinking of writing a Vim
> autocommand to decode the .xst files on load and encoding them back on save
> but haven't got round to doing it just yet.

[My original idea for obfuscation was rot128, for which vim's 'g?'
encodes and decodes. But I was afraid that some word processors
might strip the high bit, which would enable end users to make
noncompliant modifications while plausibly denying bad intent.]

> GC> To restore convenience, I'll soon push a 'gwc/invert.sh' script that
> GC> does this:
> [...]
> 
>  I wonder if we this is really much more convenient though.

Run it, and everything's unlocked. Modify an MST file and rerun it,
and Bob's your uncle. But tools seem most obviously useful to those
who create them without intending to use them, so maybe it really
isn't much more convenient. Me, I just edit /opt/lmi/src/lmi/foo.mst
and then run this command from zsh history:
  $make $coefficiency install check_physical_closure 2>&1 | less -S
and, provided I haven't changed any C++ file, I can just switch to
an already-running lmi session and Ctrl-I or whatever. That doesn't
work as well for Kim, who juggles multiple distributions.

> I thought to
> propose accepting both encoded and non-encoded files (perhaps we could use
> the presence of "{{!" in the beginning of the file for the check whether
> the file is encoded?) which would allow editing files directly in the data
> directory.

That's a natural way to handle it, but I hesitated to do that because
of the danger that '*.mst' files would escape into userland. That
danger could be mitigated by requiring the Black Speech incantation
to load an '.mst' file as such; but that's the sort of thing that's
so obviously easy that it's hard to get it right--last time I tried
to do something like that, it took seven commits to get it right:

68b9a5dc Without developer-only password, preserve old PDF behavior exactly
457d1b06 Allow creating scaled old and new PDFs at the same time
d73dd4a7 Use AutoScale() for new as well as old PDF code
9a2149f2 Refine logic for PDF implementation choice
db6278ed Conditionally suppress old or new PDF code
9b14f6fb Permit old XSL code to fail more gracefully
a3d2bf28 Permit old XSL code to fail