[referencer] lyx plugin

[jcspray at icculus.org]

Quoting Aurélien Naldi <aurelien.naldi at gmail.com>:

> Here is a lyx plugin to quote selected documents.
>
> features:
> * reads the path to the lyxpipe in lyx config file. This can be
> overriden in the script, waiting for a configuration mechanism for
> plugins
> * write a "cite" command to the lyx pipe
> * requires a yet unfinished patch to referencer, so that it can add a
> button to the toolbar and know which documents are selected.
>
> quick comments:
> * It doesn't strip UTF-8 characters as my installation of lyx (1.5)
> deals properly with them. I would encourage anyone still using an older
> version of lyx to upgrade. I have not tested it with kile yet.

Really?  Are you sure you're not just happening to give it characters  
in the first 128 byte range?

> * it is lacking in error reporting (only appear on console). Is it OK to
> put a dialog using pygtk directly from the plugin ?I would much prefer
> something less intrusive (i.e. error bar ala firefox/gedit) but this
> requires more work in the core.

Re pyGtk, the short answer is "I don't know".  Initialisation/event  
loops may well conflict.  I would avoid it until we know.  gedit gives  
its plugins PyGtk, perhaps you could see how they do it.  For the  
moment I would have perform_action simply return 0 or 1 and do  
non-specific error reporting from the C++ side.

Being verbose on the console is a Good Thing, since it gives  
straightforward debugging info if the user just runs referencer from a  
console instead of their applications menu.

> * afterwards I have read about a lyxclient in python, maybe we should
> reuse it ? http://wiki.lyx.org/Tools/PyClient

Up to you.  I'm only interested in defining the Python/C++ interface;  
how the plugin works is your prob^H^H^H^H challenge.

 From looking at the attachment:
  - Calling referencer.get_selected should be replaced with an  
argument to the perform_action function.  That way the plugin doesn't  
have to talk to DocumentView, just gets a Document object.
  - In general file operations should be in try{} blocks, although at  
present it's not clear how we're dealing with exceptions.  One  
possibility is to let fatal exceptions propagate to the C++ side where  
they can be munged into an error dialog.  Although dialogs are in  
general not terribly desirable, as long as exceptions really are  
exceptional they shouldn't get in the way.  For instance the metadata  
plugins wouldn't pass "not found" exceptions to the C++ side, they  
would silently fail.  On the other hand, passing a "I can't open the  
lyx pipe" exception up to the C++ side for display would be reasonable.

That's all that springs to mind just now, watch this space for a  
python interface for Document.

John