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 "
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>