Axel Liljencrantz wrote:
On 2/27/06, Netocrat <[EMAIL PROTECTED]> wrote:
[...]
The main legitimate
criticism that I can see is that it probably has a slight average
performance disadvantage compared to a per-file on-demand load (although
the per-file demand-load has a larger latency on first load). But
performance isn't fish's primary goal, and I doubt that the difference
will even be noticeable for normal usage.
The jit solution should be plenty fast enough. The only reason any
translations ever take a noticable amount of time is if they use the
gettext command. By calling the gettext function inside fish, you
avoid a call to fork and a reinitialization of the gettext database,
which are the reasons why things can sometimes be slow when it comes
to translations in fish.
Yar, fair enough: s/The main legitimate criticism/An efficiency nitpick/
If fish already used an event-handling model for completions as we've
discussed as a possibility in the past, then I think the out-of-shell
approach would be a more plausible solution because it would already be
general-purpose. The way that could work is that completion files are
stored such that accessing the definition of a specific completion is
very quick, so that they could be pulled out on-demand (and translated
at the same time) by a completion-event handler. There'd be a
performance penalty, and greater than that of the in-shell solution, but
you'd definitely get to keep all fundie-points.
Right. But a true fundamentalist might mean that it is more important
to keep the shell theoretically and conceptually clean than actually
make the implementation clean per se.
Sure.
I'm fundamentalist-light?
That depends on how the fundamentals are defined, but as I understand
fish's, you're pretty core about them.
The translation of fish function-description strings is still a
special-case to be handled in that situation; that could be solved by
adding a new specifier (e.g. --description-delayed) - using that rather
than --description could indicate that the translation is to be
performed on-demand, either by the shell or a handler (e.g.
"on-translate"). I can't see any other corner-cases but I'm not as
familiar with it all as you.
If no completion is avaliable, then the original string will be
printed. When would it be specifically harmfull to even attempt a
translation?
I'm not sure I understand the question, but in any case, I don't think
it's worth pursuing - the approach you've chosen seems far cleaner, and
there are other strings that I didn't consider, such as for printf's
within functions.
It's been a while since I've compiled/installed fish from darcs repo,
and here are a couple of problems from my recent attempt:
* to Makefile.in, I needed to add fallback.o to MIME_OBJS (for wcsndup,
and another function I didn't make a note of)
* when running make uninstall-legacy, it ended with an error message
indicating unable to remove non-empty directory, due to
/usr/local/etc/fish.d/completions/tokenize.fish not being removed as
that file isn't present in the current share/completions
* make install ends with:
/usr/bin/install -c -m 644 share/fish /usr/local/share/fish
/usr/bin/install: cannot stat `share/fish': No such file or directory
make: *** [install-force] Error 1
--
http://members.dodo.com.au/~netocrat
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
