Il 14/09/2011 00:20, Julien Rioux ha scritto:
On 13/09/2011 1:52 AM, Tommaso Cucinotta wrote:
- bool doExport(std::string const& format, bool put_in_tempdir,
+ bool doExport(std::string const& target, bool put_in_tempdir,
bool includeall = false) const;
Can we keep format ("latex") and target ("thisfile.tex") separated?
And in fact would it not make it easier to do so, since the
command-line parser has already done the work?
the issue is keeping compatibility with the current code, trying to
avoid the need for subverting entire parts of the code, e.g., the whole
LFUN dispatching mechanism.
Let me summarize:
1) you're right: the shell command-line parser invokes our program with
distinct options (-E <format> <filename>)
2) they are immediately merged into a single string by the current
parser: in LyX.cpp, while parsing, a
vector<string> batch_commands;
is filled, which is merely a list of LFUNs, along with their
argument(s), to be dispatched
3) these are dispatched like this:
vector<string>::const_iterator bcit =
pimpl_->batch_commands.begin();
vector<string>::const_iterator bcend =
pimpl_->batch_commands.end();
DispatchResult dr;
for (; bcit != bcend; bcit++) {
LYXERR(Debug::ACTION, "Buffer::dispatch: cmd: " << *bcit);
buf->dispatch(*bcit, dr);
final_success |= !dr.error();
}
i.e.:
void Buffer::dispatch(string const & command, DispatchResult & result)
{
return dispatch(lyxaction.lookupFunc(command), result);
}
and lookupFunc can only distinguish the LFUN string-code from the
subsequent string, which is treated as a single string argument.
FuncRequest LyXAction::lookupFunc(string const & func) const
{
string const func2 = trim(func);
if (func2.empty())
return FuncRequest(LFUN_NOACTION);
string cmd;
string const arg = split(func2, cmd, ' ');
FuncMap::const_iterator const fit = lyx_func_map.find(cmd);
return fit != lyx_func_map.end()
? FuncRequest(fit->second, arg)
: FuncRequest(LFUN_UNKNOWN_ACTION);
}
Would you really like me to touch this part of code :-) ?
Should I really invent now LFUNs which take additional arguments,
besides their first string argument, and introduce a more complex
command-line parsing making use of quotes and escapes and the like ?
Or, should I get rid of the LFUN dispatching logics, only for handling
this very particular command-line option ?
By the way, the batch_command as a single string may not be too bad,
because it ends up into a unified management, along with the management
of the commands issued through the mini-command buffer (Alt-x
buffer-export-to <format> <filename>). Is that related to handling
multiple "-x ..." with different target buffers ? (is that possible?)
The second issue is that this export request may be handled as an
asynchronous one (when done from the GUI), making use of pointers to
methods (with a fixed prototype) in GuiView.cpp. AFAICS, this last issue
can be overcome someway with some more replication of this logics around
functor-objects, so that to introduce an asyncBufferProcessing() that
may allow for an additional string-like argument.
Though, I have a couple of concerns: first, why all of this logic
escapes the usual LFUN dispatching mechanism, and instead performs a
direct all of the method in the "model", which is invoked directly from
QtConcurrent::run() ? Why don't we program QtConcurrent::run() to invoke
a local method to GuiView, which in turn dispatches an LFUN ?
Second, should we really have all this code replication or refactory,
instead of a simple argument splitting inside the Buffer::exportTo()
method :-) ?
I guess we have to live with this. What happens with the current code,
actually? Do we output e.g. .eps files to parent directories?
Yes, I just tried:
a.fig
nested/source.lyx (including a.fig)
and, after the export, we get:
nested/source.tex: \includegraphics{\lyxdot \lyxdot /a}
a.eps (created)
Probably I missed some additional check on export_folder.empty(), and as
a side effect, in my patched code a.eps is actually created inside the
nested/ folder, and referenced without the "\lyxdot \lyxdot /" (to be
fixed, in order to restore the current behavior).
IMHO, I can still see the original approach (argument splitting inside
doExport()) as the simplest one, with almost half of the needed
additions in terms of code lines, no need for refactoring (but it's not
precluded -- if anyone wants to refactor later, it's always possible),
and for touching code that simply works for now.
Bye,
T.
