On Wed, 28 Jul 2004, Tim Jenness wrote:
> On Wed, 28 Jul 2004, Peter W. Draper wrote:
>
> > On Tue, 27 Jul 2004, Tim Jenness wrote:
> >
> > > 2. ADAM applications clearly now have command line editing
> > > and history. (not provided by readline library - presumably
> > > an issue with GPL licence). Would it be preferable to use
> > > that scheme instead? Is that the code in pcs/misc/icl_reada.c?
> > > [emacs key bindings aren't supported though...] It seems to
> > > be re-implementing the readline library and doesn't look
> > > to be as easy to use as get_aline. It seems like if this
> > > approach is adopted, that this code should be factored out
> > > of pcs/misc.
> > >
> > > Comments?
> >
> > Are you saying that your readline function wouldn't reproduce all the
> > features of the current system? (I agree this does look complex and
> > incidently has some non-portable parts -- Cygwin doesn't have TIOCSTI.)
> > If so it would seem politic to just leave this alone -- for instance I
> > like to be able to press <tab> and edit the current value or get filename
> > completion, as a user I'd need a better answer than the code has been
> > improved to loose this functionality.
> >
>
> Actually I was suggesting the complete opposite :-)
Good, nice to be wrong.
> I thought I was asking whether, for the help app, I should try to use the
> pre-existing starlink-supported readline functionality by using pcs-misc
> or whether I should import Remo's getaline library which does readline
> handling (and sane fallback).
>
> Now that you mention it, it probably makes sense for me to pull the
> command line editing code out of pcs and put it in a separate library
> (so that it is obvious Starlink have a command-line eiditing interface).
> I could then incorporate a configure test that will treat icl_reada as
> the fallback code if readline is not available and even fallback to fgets
> if TIOCSTI isn't available (which is what get_aline does).
>
> Readline does support filename completion. The only problem that I need to
> sort out is that it doesn't drop the ".sdf" extension [1]
>
> Again the problem is the name: srl? ("Starlink Read Line")
>
> [1] I still can't think of a sane reason why HDS can't open a file with
> the .sdf included. All that had to be documented was that ".sdf" is a
> special string that should never be the name of a HDS component. How hard
> is that? Then it's a one line patch to strip the .sdf from the end if it
> exists and everyone is happy. The amount of confusion and anguish
> associated with the dropping of .sdf in starlink apps is incredible (I see
> that gaia allows the .sdf).
Yes, I was probably the first to start using this convention, and no one
has ever complained about that, just the reverse in fact. So I agree it's
long overdue. If one was being really careful, you might see if the
component .sdf existed in the container file.sdf, before just throwing it
away (but that's probably over the top).
Peter.
|