Geert Bosch [off-list ref] writes:
It would seem that just looking at the line length (stripped) of
the last line, might be sufficient for cost function to minimize.
Here the some would be 3 vs 0. In case of ties, use the last
possibility with minimum cost.
-- 8< --
#ifdef A
some stuff
about A
#endif
#ifdef Z
some more stuff
about Z
#endif
-- >8 --
If you insert a block for M following the existing formatting
convention in the middle, your heuristics will pick the blank line
after "about A" as having minimum cost, no?
You inherently have to know the nature of the payload, as your eyes
that judge the result use that knowledge when doing so, I am afraid.
I think your "define a function that gives a good score to lines
that are likely to be good breaking points" idea has merit, but I
think that should be tied to the content type, most likely via the
attribute mechanism.
In any case, I consider this as a low-impact (as Michael Haggerty
noted, it is impossible to introduce a bug that subtly break the
output; your result is either totally borked or is correct) and
low-hanging fruit (it can be done as a postprocessing phase after
the xdiff machinery has done the heavy-lifting of computing LCA), if
somebody wants to experiment and implement one. As long as the new
heuristics is hidden behind an explicit command line option to avoid
other "consequences", I wouldn't discourage interested parties from
working on it. It is not just my itch, though.
I think the idea of being preferable to have a blank line at the end
of the added/deleted block is key in this case.
Javier Domingo
2012/12/13 Junio C Hamano [off-list ref]:
Geert Bosch [off-list ref] writes:
quoted
It would seem that just looking at the line length (stripped) of
the last line, might be sufficient for cost function to minimize.
Here the some would be 3 vs 0. In case of ties, use the last
possibility with minimum cost.
-- 8< --
#ifdef A
some stuff
about A
#endif
#ifdef Z
some more stuff
about Z
#endif
-- >8 --
If you insert a block for M following the existing formatting
convention in the middle, your heuristics will pick the blank line
after "about A" as having minimum cost, no?
You inherently have to know the nature of the payload, as your eyes
that judge the result use that knowledge when doing so, I am afraid.
I think your "define a function that gives a good score to lines
that are likely to be good breaking points" idea has merit, but I
think that should be tied to the content type, most likely via the
attribute mechanism.
In any case, I consider this as a low-impact (as Michael Haggerty
noted, it is impossible to introduce a bug that subtly break the
output; your result is either totally borked or is correct) and
low-hanging fruit (it can be done as a postprocessing phase after
the xdiff machinery has done the heavy-lifting of computing LCA), if
somebody wants to experiment and implement one. As long as the new
heuristics is hidden behind an explicit command line option to avoid
other "consequences", I wouldn't discourage interested parties from
working on it. It is not just my itch, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Javier Domingo [off-list ref] [121214 13:20]:
I think the idea of being preferable to have a blank line at the end
of the added/deleted block is key in this case.
For symmetry I'd suggest to make it preferable to have blank lines
at the end or the beginning.
{
old
+ }
+
+ {
+ new
}
vs
{
old
}
+
+ {
+ new
+ }
is just the same case in blue.
(Although empty lines alone feels not quite optimal, it is at least a
good start).
Bernhard R. Link
If just empty lines alone, then it is forced to say there is a new
line. That is beyond this use-case.
Javier Domingo
2012/12/14 Bernhard R. Link [off-list ref]:
* Javier Domingo [off-list ref] [121214 13:20]:
quoted
I think the idea of being preferable to have a blank line at the end
of the added/deleted block is key in this case.
For symmetry I'd suggest to make it preferable to have blank lines
at the end or the beginning.
{
old
+ }
+
+ {
+ new
}
vs
{
old
}
+
+ {
+ new
+ }
is just the same case in blue.
(Although empty lines alone feels not quite optimal, it is at least a
good start).
Bernhard R. Link