gnu/usr.bin/ptx/TODO

   1 TODO file for GNU ptx - last revised 05 November 1993.
   2 Copyright (C) 1992, 1993 Free Software Foundation, Inc.
   3 Francois Pinard <pinard@iro.umontreal.ca>, 1992.
   4
   5 The following are more or less in decreasing order of priority.
   6
   7 * Use rx instead of regex.
   8
   9 * Correct the infinite loop using -S '$' or -S '^'.
  10
  11 * Use mmap for swallowing files (maybe wrong when memory edited).
  12
  13 * Understand and mimic `-t' option, if I can.
  14
  15 * Sort keywords intelligently for Latin-1 code.  See how to interface
  16 this character set with various output formats.  Also, introduce
  17 options to inverse-sort and possibly to reverse-sort.
  18
  19 * Improve speed for Ignore and Only tables.  Consider hashing instead
  20 of sorting.  Consider playing with obstacks to digest them.
  21
  22 * Provide better handling of format effectors obtained from input, and
  23 also attempt white space compression on output which would still
  24 maximize full output width usage.
  25
  26 * See how TeX mode could be made more useful, and if a texinfo mode
  27 would mean something to someone.
  28
  29 * Provide multiple language support
  30
  31 Most of the boosting work should go along the line of fast recognition
  32 of multiple and complex boundaries, which define various `languages'.
  33 Each such language has its own rules for words, sentences, paragraphs,
  34 and reporting requests.  This is less difficult than I first thought:
  35
  36  . Recognize language modifiers with each option.  At least -b, -i, -o,
  37 -W, -S, and also new language switcher options, will have such
  38 modifiers. Modifiers on language switchers will allow or disallow
  39 language transitions.
  40
  41  . Complete the transformation of underlying variables into arrays in
  42 the code.
  43
  44  . Implement a heap of positions in the input file.  There is one entry
  45 in the heap for each compiled regexp; it is initialized by a re_search
  46 after each regexp compile.  Regexps reschedule themselves in the heap
  47 when their position passes while scanning input.  In this way, looking
  48 simultaneously for a lot of regexps should not be too inefficient,
  49 once the scanning starts.  If this works ok, maybe consider accepting
  50 regexps in Only and Ignore tables.
  51
  52  . Merge with language processing boundary processing options, really
  53 integrating -S processing as a special case.  Maybe, implement several
  54 level of boundaries.  See how to implement a stack of languages, for
  55 handling quotations.  See if more sophisticated references could be
  56 handled as another special case of a language.
  57
  58 * Tackle other aspects, in a more long term view
  59
  60  . Add options for statistics, frequency lists, referencing, and all
  61 other prescreening tools and subsidiary tasks of concordance
  62 production.
  63
  64  . Develop an interactive mode.  Even better, construct a GNU emacs
  65 interface.  I'm looking at Gene Myers <gene@cs.arizona.edu> suffix
  66 arrays as a possible implementation along those ideas.
  67
  68  . Implement hooks so word classification and tagging should be merged
  69 in.  See how to effectively hook in lemmatisation or other
  70 morphological features.  It is far from being clear by now how to
  71 interface this correctly, so some experimentation is mandatory.
  72
  73  . Profile and speed up the whole thing.
  74
  75  . Make it work on small address space machines.  Consider three levels
  76 of hugeness for files, and three corresponding algorithms to make
  77 optimal use of memory.  The first case is when all the input files and
  78 all the word references fit in memory: this is the case currently
  79 implemented. The second case is when the files cannot fit all together
  80 in memory, but the word references do.  The third case is when even
  81 the word references cannot fit in memory.
  82
  83  . There also are subsidiary developments for in-core incremental sort
  84 routines as well as for external sort packages.  The need for more
  85 flexible sort packages comes partly from the fact that linguists use
  86 kinds of keys which compare in unusual and more sophisticated ways.
  87 GNU `sort' and `ptx' could evolve together.
  88
  89 \f
  90 Local Variables:
  91 mode: outline
  92 outline-regexp: " *[-+*.] \\|\f"
  93 eval: (hide-body)
  94 End: