Xref task used as server for editing commands

Introduction

When xref is invoked with option "-task_regime_server", it acts like a server reading input options from standard input and producing answers on the standard output.

Because on majority of OS, pipes are slower than temporary files, two pipes (standard input and output) are used only for small quantity of datas and their main purpose is synchronisation of editing environment and xref task.

The xref task expects a suite of input options finished by the "end-of-options" string. Options are basically those which can be used on command line (with exception of -I and -D options). Moreover numerous special options not documented in the xref manual page can be used. One of options should specify the output file for the answer. In such case the xref task computes the answer, stores it into the output file and then it writes the "" string on its standard output.

NOTE: If you wish to examine the exact communication between xref task and Emacs editor, you can edit the xref.el file and change the line:


(defvar xref-debug-mode nil)
to:
(defvar xref-debug-mode t)

This will cause that Emacs will display all informations exchanged with xref task.

EXAMPLE

The simplest example of xref comunication protocol is invocation of a completion function. Let's consider that we have a file /tmp/xrefactory.tmp containing the following text:
----------------------------------------------------------------------
struct toto {int x,y;} t;

main() {
  t.
  ;
  ma
}
----------------------------------------------------------------------
following suite of commands will call xref server task, ask for all completions after "t." string at line 4 (offset 40), then it will ask for completion on line 6 (offset 49). In the following, text written by hand is displayed in bold, answers from computer are in plain text.


vittek:~/tmp/test>xref -task_regime_server -xrefactory-II
-olcxcomplet
-olcursor=40
/tmp/xrefactory.tmp
end-of-options


<all-completions nofocus=0 len=19>x  :int x
y  :int y</all-completions>
<sync>

-olcxcomplet
-olcursor=49
/tmp/xrefactory.tmp
end-of-options


<goto>
<position-lc line=6 col=2 len=25>/tmp/xrefactory.tmp</position-lc>
</goto>
<single-completion len=4>main</single-completion>
<sync>


The first answer means that the list:
x  :int x
y  :int y
of possible completions should be displayed. The second answer is asking for moving to the line 6 and column 2 of the file /tmp/xrefactory.tmp and inserting there the string main, which is the only completion.
Using output file
Following example demonstrates usage of a temporary file to get the output from xref task. In this case the answer is not produced on the standard output, but into a file. Only the <sync> record is passed via standard output.


vittek:~/tmp/test>xref -task_regime_server -xrefactory-II
-olcxcomplet
-olcursor=49
-o /tmp/xrefactory.out
/tmp/xrefactory.tmp
end-of-options


<sync>

vittek:~/tmp/test>cat /tmp/xrefactory.out
<goto>
 <position-lc line=6 col=2 len=25>/tmp/xrefactory.tmp</position-lc>
</goto>
<single-completion len=4>main</single-completion>
vittek:~/tmp/test>

Using temporary input file
Usualy when completion is invoked from an editor, the currently edited file is not saved. The completion is not expected to save it neither. However in order to pass it to the xref task, the file has to be stored somewhere in the file system. Xrefactory offers special mecanism for this situation. It allows to specify that a temporary file is storing the current version of a source file. For example:


vittek:~/tmp/test>xref -task_regime_server -xrefactory-II
-olcxcomplet
-olcursor=49
-preload /home/vittek/tmp/test/toto.c /tmp/xrefactory.tmp
-o /tmp/xrefactory.out
/home/vittek/tmp/test/toto.c
end-of-options


<sync>

vittek:~/tmp/test>cat /tmp/xrefactory.out
<goto>
 <position-lc line=6 col=2 len=25>/home/vittek/tmp/test/toto.c</position-lc>
</goto>
<single-completion len=4>main</single-completion>