> Any ideas, remarks ?
First of all, the BASE FUNCTIONALITY of xtla.el is still poor to build
the big things on the top of it.
Let's talk about my code as the first example.
tla-archive-tree-* written by me is the kernel of completion in xtla.el.
However, it is not efficient. You can find some place in where tla-archive-tree
is set to nil; the data cache is force to be made cool down. The data cache
should be hot everytime.
The 2nd one is in tla-run-arch and tla-process-sentinel.
These two functions will be the kernel of xtla muil process/buffer strategy.
However, it is not abstracted yet. The code is complex and depends on clients.
Look at the code tla-process-sentinel:
(defun tla-process-sentinel (process event)
...
(archive-mirror (tla-show-process-buffer-internal t)...
(star-merge (tla-show-process-buffer-internal t)...
(delta (let ((no-changes))...
(missing-list (tla-bookmarks-missing-parse-missing)...
(changes-list (tla-bookmarks-missing-parse-changes)...
(changes (message "No changes in this working copy"))...
Currently tla-process-sentinel does what the client want.
So. star-merge for example code must be written separately in two places.
1. Process launching part
(defun tla-star-merge (from &optional to-tree)
...
2. Real job part in tla-process-sentinel
(star-merge (tla-show-process-buffer-internal t)...
What we need is something like this (from emacs-w3m):
(defmacro w3m-process-do (spec &rest body)
"(w3m-process-do (VAR FORM) BODY...): Eval the body BODY asynchronously.
If an asynchronous process is generated in the evaluation of the form
FORM, this macro returns its object immdiately, and the body BODY will
be evaluated after the end of the process with the variable VAR which
is set to the result of the form FORM. Otherwise, the body BODY is
evaluated at the same time, and this macro returns the result of the
body BODY."
We can write our code like:
(defun tla-star-merge (from &optional to-tree)
...
(tla-process-do :args (star-merge arg1 args2...)
(body-executed-when-the-process-is-completed
...)) )
I think xtla.el should be split into some xtla-*.el during development.
The BASE FUNCTIONALITY should be in xtla-core.el. xtla-core.el should
provide services for other xtla-*.el. So you can concentrate on
xtla-core.el and do big jobs in the file.
I'm talking about development. When xtla is released, single. xtla.el
is good for users.
