It seems that there is another person interested in this project? OK, here is my opinion:
I understand there will be plenty of classes modified this way, but to most of them, the change is minor, and share a common pattern. What we need for an inset class is (1) its type and (2) its child nodes. If there is already methods to get those information, no problem remains. On the other hand those methods should be added to each class. The idea of using export to latex feature is to do some preprocessing before matching to reduce the involved insets, that should be done definitely, or else we will write another separate method for ignore format matching. And many commands in latex is also useless in matching, they should be ignored too. I am not familiar with Compare Document feature, I think it's different from this project. Since in Find and Replace, we should simply ignore all the cases that doesn't match, but in Compare Document, we should also calculate the difference, which is more complicated. Also, compare document doesn't involve uncertainty of wildcards or regular expressions. But surely they can share some code, just need some refactoring. On Tue, Apr 30, 2013 at 6:36 AM, Tommaso Cucinotta <tomm...@lyx.org> wrote: > On 19/04/13 21:35, Tommaso Cucinotta wrote: >> Improving the situation may go along the lines of: >> A) either creating within LyX a kind of visitor interface able to >> recursively match insets against other insets, so that we make a sort of >> graph matching between the LyX text (I mean, the internal LyX C++ data >> structures -- insets) as available in the text to search, versus as >> available within the main document being edited. Such a change seems to be >> quite invasive, and risks to touch each and every inset... > > Anyway, I think in a proposal for going this way, we should really get > clarified how many classes would need to be touched by the functionality. For > example, is there a need for a new *::match() method in each and every inset > ? Can we take some short-cut, and, for example, compare by default insets > based on their text/latex export, then later refine the comparison with more > sophisticated means ? (e.g., to handle correctly the regexp part ?) > > That would be helpful for getting an idea of the effort. > > For example, in a sense, it might resemble or be comparable to the effort > needed for the Compare Document feature realized some time ago ? Vincent, any > "feeling" about this ? > > Thanks, > > T. >
