Re: Midnight Commander mod with Colorer-take5 syntax engine

[Pavel Tsekov <ptsekov gmx net>]

Hello,

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.

Yes.

> 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
> now.
>
> 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.