Re: Midnight Commander mod with Colorer-take5 syntax engine


On Mon, 26 Jun 2006, Igor Russkih wrote:

For me this patch looks fine, its good idea for MC to detect colorer's
library presence in runtime.

However the implementation is not rather straightforward because of
that separate glue library.

Yes, it adds another level, but at the moment it is the only working solution. By using this library we avoid linking to libcolorer at
build time.

If such a dynamic loading is best case for MC, maybe it is worth
implementing it in more 'valid' way? I mean I can develop a set of
'neutral' C API, which will be included directly into libcolorer

The dynamic loading is desired since it drops the dependency on
libcolorer. For the package maintainer this means that she/he can
build MC with colorer support but the package will not pull libcolorer
unless specifically requested to do so (by the user). This is very
important IMHO.

Then MC can dynamically load libcolorer and import all the required
API functionality as it imports 'colorer_get_interface' via gmodule in
Pavel's version.


Surely it will require additional efforts as on my side, as on MC
side, but with this we'll get better colorer's integration with MC.
Moreover colorer will get a general C-based API, which it doesn't have

Pavel, whats your opinion on this?

If you are willing to change colorer so that it will become C-friendly
you are more than welcome. Providing a generic interface seems a better
solution than writing a new plugin for every editor in the wild. Of course
custom plugins could be tuned better to fit the specific requirements of
XYZ editor. I think it is up to you after all - either way I'll try to
help getting colorer support into MC.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]