On Mon, Mar 31, 2014 at 10:40 PM, Tommaso Cucinotta <tomm...@lyx.org> wrote:
> On 29/03/14 17:50, Vincent van Ravesteijn wrote: > > Tomasso's patch was not improving the situation, but was somehow hiding > the underlying mess by building some messy function on top of it. > > well, I have to some-what disagree here: > - removing from the program the possibility of an infinite loop leaving > the user with a "damn!" > I was talking about merging the two functions. And about the bug-fix, I'm missing a huge FIXME to warn anyone not to remove "AS_STR_SKIPDELETED". If you leave the underlying bugs and just cover them up, it should at least be documented. > - replacing two nearly identical methods with only one and a slight > variation on the params, > preserving substantially the same API and all seamless for any caller > Except that Text::asString(AS_STR_INSETS | AS_STR_PLAINTEXT) now asserts, and Paragraph::asString(AS_STR_INSETS|AS_STR_PLAINTEXT) now asserts. Furthermore, I doubt whether the function behaves as advertised. > > these are, IMHO, an improvement of the situation :-). > > But we can argue about whether we should refactor entirely the whole > string export machinery of LyX, and/or the whole Advanced F&R. For me, > OO-wise, a generic visitor/double-dispatching interface should have been > introduced long ago, to support generic walk-through the entire objects > graph, where different visitors would have realized various things: save, > export as this, export as that, even search or perhaps the diff function! > How many methods across all insets basically replicate a recurrent visiting > structure? > > Still, we can start that in the new branch for 3.0 that will go out in 1 > year, for what it matters, refactoring the LFUN dispatching as we're at it, > as the computer that formats and parses back human strings somewhat hurts > my sensibility :-), and why not plug on top the XML or git based export :-) > ?..., and still leave any 2.x further release with the infinite loop :-) ?!? > > Apart from jokes, yes, it could have been fixed in other ways (removing > the replace all button, among others :-)!). Namely, I plan a final one with > an accompanying additional checkbox on the GUI allowing me to decide > whether I want to consider change tracking or not in the search, as > discussed. > > Bye, > > T. > I'm not going to react to this. Vincent
