path: root/TODO
diff options
authorGravatar Rob Landley <rob@landley.net>2005-10-31 23:52:02 +0000
committerGravatar Rob Landley <rob@landley.net>2005-10-31 23:52:02 +0000
commitdbc608b5687ebe1b828f921c70573280d6c3e313 (patch)
tree0df0bcda4b5c6014f8b20d775b766cd6cde0c1b7 /TODO
parentc63fe9137fbdf83794d1ea5a3e000238816cba94 (diff)
We've got fuser, fix some typos, and move Vodz's comment about UTF8 into
a new "internationalization" section, with some related concerns.
Diffstat (limited to 'TODO')
1 files changed, 25 insertions, 7 deletions
diff --git a/TODO b/TODO
index d179529e8..727fbbadf 100644
--- a/TODO
+++ b/TODO
@@ -11,19 +11,14 @@ sh
work all that well (especially not in a chroot environment), due to apps not
being reentrant. Unifying the various shells and figuring out a configurable
way of adding the minimal set of bash features a given script uses is a big
- job, but it be a big improvement.
+ job, but it would be a big improvement.
Note: Rob Landley (rob@landley.net) is working on this one, but very slowly...
- Support unicode for cmdedit.
We should have a diff -u command. We have patch, we should have diff
(we only need to support unified diffs though).
- Would be nice. The basic susv3 options, plus fuser -k.
Should have simple fuzz factor support to apply patches at an offset which
shouldn't take up too much space.
@@ -51,7 +46,30 @@ Do a SUSv3 audit
Even better would be some kind of automated compliance test harness that
exercises each command line option and the various corner cases.
+ How much internationalization should we do?
+ The low hanging fruit is UTF-8 character set support. We should do this.
+ (Vodz pointed out the shell's cmdedit as needing work here. What else?)
+ We also have lots of hardwired english text messages. Consolidating this
+ into some kind of message table not only makes translation easier, but
+ also allows us to consolidate redundant (or close) strings.
+ We probably don't want to be bloated with locale support. (Not unless we can
+ cleanly export it from our underlying C library without having to concern
+ ourselves with it directly. Perhaps a few specific things like a config
+ option for "date" are low hanging fruit here?)
+ What level should things happen at? How much do we care about
+ internationalizing the text console when X11 and xterms are so much better
+ at it? (There's some infrastructure here we don't implement: The
+ "unicode_start" and "unicode_stop" shell scripts need "vt-is-UTF8" and a
+ --unicode option to loadkeys. That implies a real loadkeys/dumpkeys
+ implementation to replace loadkmap/dumpkmap. Plus messing with console font
+ loading. Is it worth it, or do we just say "use X"?)
Unify archivers
Lots of archivers have the same general infrastructure. The directory
traversal code should be factored out, and the guts of each archiver could