Re: [lmi] Paths in configuration file (was: [lmi-commits] master 0c2d6b4 30/33: Revert "Revert "Trap exceptions from filesystem library"")

[Greg Chicares]

On 5/14/21 7:37 PM, Vadim Zeitlin wrote:
> On Fri, 14 May 2021 16:21:43 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 5/14/21 1:38 PM, Vadim Zeitlin wrote:
[... ... ...]
> GC> The problem is that the "Input defaults" came out this way:
> GC>   /opt/lmi/bin/Z:/etc/opt/lmi/default.ill
> GC> That's just wrong.
> 
>  Yes, I think we can all agree with this.
> 
> GC> After closing lmi-msw and starting lmi-gtk, the dialog shows:
> GC>   Input defaults:     /opt/lmi/bin/Z:/etc/opt/lmi/xyzzy.ill
> GC>   Printout directory: /opt/lmi/print
> GC> as before. "Input defaults" is obviously wrong on the face of it.
> GC> None of my experiments has prevented that.
> 
>  What confused me was that having, or not having, 0c2d6b415 (Revert "Revert
> "Trap exceptions from filesystem library"", 2021-05-02) and/or,
> equivalently, dab074e38 (Revert "Trap exceptions from filesystem library",
> 2020-11-27), doesn't change anything neither. OTOH it's reassuring that it
> doesn't, because at least I don't have to understand how it could.

I just didn't want to simplify something that contains a
demonstrable error.

If we fix the demonstrable error first, then we can simplify
the code.

Alternatively, although I don't have time for it now, I'm
pretty sure we decided a while ago that the whole design is
poor. (I think it had something to do with automatically
saving modified settings--perhaps the call to save() in a
configurable_settings::configurable_settings() catch clause).
If we want to replace it with a new and better design, then
we can throw away code that contains a demonstrable error.

> GC> I didn't check whether that commit had any causal relationship
> GC> with the reported error. But something is demonstrably wrong
> GC> and needs to be fixed.
> 
>  The surface fix is simple: we just need to apply remove_alien_msw_root()
> to default_input_filename_ too.

Sounds simple enough, in concept. It could take hours to
test--hours that I cannot spare right now--but is does
sound simple.

> As you yourself wrote in the commit message
> of 550da79ad (Remove alien msw root-name from configurable print directory,
> 2020-11-11), which added it for the print directory, it should also be done
> for the other path unless some other solution is found.

Thanks. I don't have time to look into that now.

>  Should I make a patch doing this?

Okay, but I won't have time to consider it now.

> I'd also still like to revert 0c2d6b415
> if I do this.

Okay, as long as I can take "if" as meaning "after".

> In fact, I'd like to revert it even if I don't, because it
> just doesn't seem to do anything useful while making the code longer and
> more complicated.

We're not going to agree on that. Maybe you're absolutely
correct and they're independent, but I'm not convinced and
cannot make time to be convinced right now.

> GC> If we're going to step back and redesign anything, then IIRC
> GC> we should step back farther and do a deeper redesign--I think
> GC> I cited some older email thread on that topic, somewhere earlier
> GC> in the present thread. I have no time to work on that myself now.
> GC> But either we fix the problem at the surface, or at the root--not
> GC> anywhere in between.
> 
>  I don't know if you'd like to discuss this now,

No, I'm working on some other things that require my full
attention.

>  FWIW I don't see how can we make this work reasonably well if we keep
> using the same configuration file for both versions. I think this file must
> be (logical) machine-specific and lmi-gtk and lmi-msw

That sounds sensible, but I don't have time to think about it
right now. And I think we had some other discomfort with the
design; all I remember right now, off the top of my head, is
that it a ctor should call load(), and for it to call save(),
in a catch-clause, seems weird. But I really think we had a
good discussion of this, maybe a few years ago, and if we're
going to change this code, I'd like to reopen that old
discussion in order to make sure we make the best decision
using all the (recorded but forgotten) information available.