Re: [screen-devel] alias support for GNU Screen

[Steve Kemp]

On Sun Oct 19, 2008 at 11:41:20 -0700, Micah Cowan wrote:

> I had the opportunity to look tscreen over yesterday (mainly, just
> reading the FAQ and feature list), when Tony Bernard pointed it out to
> the list yesterday. I'm guessing that's probably also how you came to
> post here, from queries generated from that post. :)

  Right.

> But from the beginning, I made it clear that my limited free time, and
> priority of focus on GNU Wget, would mostly mean I'd be limited to
> administrative roles; managing the bug tracker and project tools more
> than active development. Meanwhile, Sadrul's pace has been limited
> recently by the demands of educational institutions. ;)

  That's completely understandable. 

> Nevertheless, development is taking place, and we're open to patch
> suggestions and such.

  Great.

  Some of the changes I'd like for myself, such as the aliases are
 obviously suitable for inclusion in GNU screen, and I'm always going
 to be happy to offer patches.

  Other changes I think might be more Steve-specific and make less
 sense for other people.

> >     1.  Mere synonyms.
> >     2.  Constant calls to other functions with a list of arguments.
> 
> AFAICT, (1) is a subset of (2)? Unless you mean that you would be unable
> to follow on those arguments with additional arguments.

  Indeed the former is a subset of the latter.


> >   In terms of implementation the code is pretty straightforward, and
> >  some of the actual details show through.  We maintain a global linked
> >  list of aliases.
> 
> A hash or self-balancing tree could be more scalable, of course.

> I thought I remembered seeing something about a limit of 20 to the total
> number of aliases yesterday, but I don't see that any more, and the code
> doesn't show that. Am I crazy, or was that there yesterday? :)

  You're not crazy.  Initially I had an array of 20 static aliases.
 Once I had things working nicely I switched to a linked list.  Of
 course a fancier structure would be faster, but I don't see that
 being absolutely required just yet.

> BTW, GNU Screen now has tilde expansion as well, but only for one
> command (I forget which one). The logic, IIRC, is currently inline to
> that function, rather than farmed out for use by other functions.

  I saw it being used in do_source - I moved that out to a standalone
 function so that more places could use it.

  /*
   * naive tilde expansion for filenames.
   *
   * NOTE:  Caller frees.
   */
  char * expand_tilde( char *input )

> At the moment we're in feature freeze, preparing the sources for
> eventual release. Probably in a couple of days I'll set up a new branch
> (or perhaps a separate repository) to hold changes targeted for after
> the release. William Pursell has contributed a number of patches to
> bring in the use of autoconf; that would go in there as well.

  Great.

  Do you have a list of features that you're planning on working on?

  I see several wishlist bugs, but I don't see any obvious statement
 of which are there because somebody once suggested it, or which were
 added by developers..

> Bringing in the use of autoconf also means we could start taking
> advantage of gnulib facilities, which already has several useful mapping
> structures (trees and hashes) we could avail ourselves of.

  Indeed there are several parts of the codebase that could be made
 more generic in such a fashion.

  Since the subject of autotools has been mentioned I think it would
 be a lot nicer to work with the code if we could juggle the tree
 around some:

    ./screen/{README FAQ COPYING LICENSE HACKING}
    ./screen/src/*.[ch]
    ./screen/etc/{screenrc completer.zsh}
    ./screen/utf8encodings/
    ./screen/terminfo/

  Basically put the source in a subdirectory and keep it out of the
 way.

  My autofu is weak, but I guess it shouldn't be too difficult to move
 things around with git..


Steve
-- 
Managed Anti-Spam Service
http://mail-scanning.com/