Bug #11484

[Scott Kostyshak]

On Fri, Apr 23, 2021 at 06:58:16AM +0200, Jürgen Spitzmüller wrote:
> Am Donnerstag, dem 22.04.2021 um 13:18 -0400 schrieb Scott Kostyshak:
> > I wonder if using branches would be a better way to achieve the
> > desired workflow above. I believe we should preserve the previous
> > default behavior of giving an error in the GUI when there is a
> > missing included file.
> 
> But only since warnings are not salient enough on the command line,
> right? If so this fix is at the wrong place.

I think the command line issue is separate from the GUI issue. Sorry for
conflating the two in my initial email. We can always adapt the
command-line behavior from what I understand (as the patch you just made
suggests). I started this discussion with the command-line motivation
because that is how I encountered it, but I do not think the new GUI
behavior is good.

I do not think the new GUI behavior is good because (a) I think the
distinction between an error and a warning is important and (b) I think
that a missing file should be an error. I guess this is a disagreement
partly in semantics, which I wonder is difficult to have a constructive
debate. But we can try.

Should we do the same thing for included graphics that we can't find?
What about a .bib file that does not exist? Perhaps a distinction can be
made for why we do something special for an included child document and
not other files, but to me the line seems blurry.

Regarding workflow, I propose three ways to achieve the workflow you
mentioned as motivation for the patch that I think are better than what
the patch implemented:

1. Use branches.

2. Just create empty .lyx files for the includes.

3. Proceed with compilation and give an error if there is a missing
   include but the user can click on the "Show Output Anyway" button to
   see the file that omits the missing include.

(3) is not currently achievable in LyX but presumably we could consider
this enhancement.


> > A couple of notes on issues related to the above. I think that they
> > could be worked around if we decide that a warning is better than an
> > error:
> > 
> > 1. I think that LyX should try its best to export the same LaTeX code
> > on
> >    different systems. I understand that in some cases it is difficult
> > to
> >    avoid different exported code on different systems (I think we
> >    sometimes condition on which features are available?), but it
> > would
> >    be nice to keep those cases to a minimum. After this commit, if
> > the
> >    file exists on one system but does not exist on a different
> > system,
> >    LyX exports different LaTeX code. Perhaps as an alternative LyX
> > could
> >    add code to the preamble to redefine the \include command for
> > LaTeX
> >    to check if the file exists and condition accordingly. I really
> > don't
> >    like this idea but at least the same .tex code would be exported
> > in
> >    all cases.
> 
> 
> Thus the warning to indicate that something is unusual. I think an
> error is much too brute here, as it disallows people to work with this
> file.

I think that the workflows proposed above allow people to work as desired.

> > 2. Starting with this commit, if you view the source code (e.g., set
> > to
> >    "Complete Source"), every time you type a character you get the
> >    warning.
> 
> This also can be addressed at the core I think.

Agreed. This is not a major concern. I only mentioned it in case we
decide to keep the new behavior in c41df5b671e.

Scott


> > > Can we have warnings on the cl that require user prompts before the
> > > process continues?
> > 
> > Perhaps we could try to emulate what LaTeX does. They have prompts
> > for
> > undefined commands and if you press return the compilation tries to
> > continue. They also have a batch mode where there is no prompt and it
> > just errors out. I don't really like this idea of adding this
> > prompt-like behavior to LyX's command-line export and an additional
> > batch mode (preference?), but perhaps we could consider it if that's
> > what the majority prefers. In any case, we might want to figure this
> > out
> > after we figure out the GUI behavior discussed above.
> 
> Note that I mean this as an option for warning which we think require
> attention (but are not errors). We could add an option
> "cl_confirmation" to alert::warning, defaulting to false and enabled
> for this particular warning.
> 
> Jürgen
> 
> > 
> > Scott
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20210423/e919e2d1/attachment.asc>