Significant .lyx EOL White Space Inquiry

[José Abílio Matos]

Hi Joel,
  I am revisiting this because I think that of points you raise are worth of 
further, although not necessarily immediate attention. :-)

On Sunday, May 31, 2020 6:30:56 PM WET 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.

Sometimes it is just an historical accident. :-)
I have been thinking about this issue since your first message in May (?).

The first note is that we allow our paragraphs to end with a (white) space, 
how would we represent this in the new format?
I have no good solution for this?

In terms of editor does it makes sense for us not to allow them? If we did not 
allow them the previous point would be moot.

I think that the real reason that we use this scheme is due to how we 
represent insets in the file format, we always change line.
That is what IMO forbids the equivalence between spaces and newlines in the 
lyx file format.

If we find a solution for the previous questions this can be implemented in 
lyx2lyx.

> [...] 
> 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

The last couple of paragraphs are likely candidates for track, if they are not 
there yet. That way they do not get lost in the mailing list.

Thank you for all your comments and insights. :-)

Best regards,
-- 
José Abílio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20201214/a3588815/attachment.html>