Leonard, all, Here attached the patch over mc-2006-06-17-02 (snapshot from ibiblio.org). Please don't make direct diffs between mc-colorer and cvs snapshot since they are different versions. Use this patch for reviewing. I've separated the patch for easier understanding: build.diff - make/configs changes edit.diff - changes in existing edit/* files mccolorer.diff - new colorer's code edit/syntax-colorer-* lang.diff - ru.po additions for colorer
> Colorer library can be disabled either during compilation time Switching at run time would be nice. At least as a startup option.
"either during compilation time or in runtime" - I meant this is already implemented.
These are comments and fixes in your mccolorer, not available in CVS. Are you using patches from others?
No, just clean mc snapshot from ibiblio.org.
> > odd whitespace changes, but there appear to be some hunks at the top and > > bottom to actually do something. Please submit (not the whitespace) :) . These are patches you seem to be using that are not in CVS. This is why I ask you to submit them for review.
Sorry, it seems to be a difference in our original MC tarballs. I didn't touch it. See the patch attached for all the files changed.
> The main problem with this is that syntax-colorer.cpp file makes > direct connection between mc editor data and colorer's code. > Technically it is possible to extract a kind of 'generic' C API and > include it on library side. In this case MC will have pure C codes. Is it technically possible to reimplement that c++ code in c? (This is just theoretical question, I don't ask you to do it.)
It is possible to move this code to libcolorer side and implement plain C API from library side - however this'll take more time and I see no reason in doing this.
Yes, I guess you are right. We might want to put the colorer code in a different directory though.
That's easy. -- Igor
Attachment:
mccolorer.diff.tgz
Description: GNU Zip compressed data