Significant .lyx EOL White Space Inquiry

[Joel Kulesza]

On Fri, May 29, 2020 at 9:49 AM Pavel Sanda <sanda at lyx.org> wrote:

> On Thu, May 28, 2020 at 10:27:54AM -0600, Joel Kulesza wrote:
> > Finally, significant EOL white space seems unidiomatic in a "source
> file,"
> > which is what a .lyx file effectively is.
> >
> > This is an expert-use situation, but *I wonder if we have a way to
> overcome
> > the need for significant EOL white space.*
>
> Well, it's all in the code, so one could certainly write patch witch moves
> the whitespace to the next line.


I understand.  I was mainly asking to see whether there is a historical
reason for "needing" EOL white space, or whether it came along at some
point and has persisted.


> The issue is that any oversight in such
> patch would lead to catastrophic dataloss bugs for everyone else and one
> has to ask whether this cornercase is worth the risk.
>

Perhaps not, but it still begs the question whether steps are worth taking
to become a more idiomatic format.


> My take is that
> - if you mess with .lyx you need to respect its whitespacing and
>   set your editor accordingly
>

A fair point, and that's what I've done.  But, it's easy for someone to not
take this step and get burned by it at least once.


> - the real solution would be to actually do document comparison
>   feature right, so one does not need to edit raw .lyx file...
>

Agreed.  I see a few areas for improvement here.  First, I've seen "Track
changes" flag false positives and give false negatives.  So, improving
robustness in this markup would be good.  Second: the ability to provide
comment/replies as wording is iterated upon would be valuable.  That is the
main behavior I seek when performing document review: the ability to
provide specific actionable feedback (perhaps with discussion) on specific
components of the text.  That's why a git-based review system is nice
(Gitlab, Github, Bitbucket, etc.).

Finally, improving the integration with revision tracking would be good.  A
recent criticism I heard was "why do I have to count the number of
revisions back; why not just specify a commit/branch point to compare
with?".  I explained why, but that is valid feedback from a git-centric
view.  I wonder if specializing the version control behavior for git would
be valuable to augment the more generic interface currently available.

Thanks,
Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200531/2be6e3ba/attachment.html>