On Mon, Sep 17, 2001 at 01:12:23PM +0400, Alexander V. Lukyanov wrote:
> > Another issue: terminal settings. (We've been here before ...) There
> > are three: begin color, end color, reset color. I've put them in
> > color:term-color-xxx, but I don't like that--we could end up with a
> Try to use termcap. Readline does already use it.
I can do it with terminfo; it'd mean linking explicitely to it, not just
implicitely via readline.
Unfortunately, it'd mean not being compatible with LS_COLORS; I don't think
the tradeoff is worth it.
The terminfo stuff for colors is explicitely ANSI-color-specific, by
the way. (At least, setaf and setab are; I steer far clear of the
"color pair" mess.) So, it wouldn't really gain us much.
> No, FDStream is not suitable for color handling. I think it is better to
> make a new class which holds current color and has functions like
> SetColor(int color, Buffer *).
None of the classes are really appropriate--anything created based on
the output FDStream in CmdExec will be deleted after it's done, losing
any persistant information. (Including the FDStream.) Also, color
is currently set via actual terminal codes, as are in LS_COLORS, for
obvious reasons.
Oh, and I got completion stuff working. (There's a little-used callback
for it.) It was a little work to keep around completion data, but it works.
(After a completion request, it keeps the glob* info around until the next
completion, and a full glob_res is created for local completion.) I'll
probably try to have it clear this on new commands (not just on the next
completion), since it can be fairly large. This also allows seeing full
ls output on completion, if it's set up to do so. (Well, everything that's
parsed--user, group, etc. isn't. This would be useful at least for output
purposes, but I'll leave that for later.)
This is currently a fairly large patch, mostly due to me moving a few
things around--moving the "make a FileInfo out of a local file" stuff
into its own func, making a "parse backslash sequences" function--needed
it again and there were already two versions--etc.
The only problem I know of is that I had to always enable "quiet" (-q)
for cls, disabling status reports, due to overlap. I'm not sure how to fix
this; it'd be very nice to have. (Perhaps a setting for FileCopy to
tell it to go NoStatus once the source peer has started giving data?)
Status reports work (in the echo area) for filename completion. Adding -q
to cls-completion-default disables this.
Some means to specify a directory to ListInfo would speed this up and
simplify the job to not need a state. (The RFC does specify directories
as an arg to LIST, and I've never seen a server not accept them.)
> Look at how original ls is done. There is data source - FileCopyPeerDirList
> and data destination which is created according to parent->output.
> Then a CopyJob job is created, which does all the work.
Yeah, I was trying to avoid that. :) By the way, completion doesn't do this,
so it'll suffer from blocking problems anyway. (It already had this problem,
of course.)
Considering every job that can take redirections or needs buffering becomes
a FileCopyPeer, FileCopy.cc is going to get larger and larger--it might be
worth pretending the peers are jobs themselves and moving them into their
own files.
I'm having a very strange problem with readline: occasionally, a line
will either be aborted (as if ^C was pressed) or lftp will outright
exit (as if ^D was pressed.) It's completely nondeterministic, doesn't
trigger anything in gdb, and has only started showing up in the last
hour or so. It's happened before, while I was working on another patch;
I don't recall what the fix was (if I did find one at all.) The only
thing I can think that might be shared is enabling profiling, but I
don't know how that could relate.
Let me know when you're back and I'll give you what I have. There's
no centralized color handling at all; there's no pressing need, but
we can figure something out if you want. (The only changes to FDStream
were adding isatty() and width(), the former of which is just a
shortcut.)
--
Glenn Maynard
