1. 15 Mar, 2005 4 commits
  2. 13 Mar, 2005 2 commits
    • Aleksandar Bakic's avatar
      Line-oriented persistent buffer (binseq2). Warning: Need to fix minor · 94f6939a
      Aleksandar Bakic authored
      bugs (related to number-of-lines-in-region, I believe).
      base.lisp: Added faster methods on previous-line, next-line,
      pane.lisp, cl-syntax.lisp, html-syntax.lisp, text-syntax.lisp:
      Replaced some calls to make-instance to calls to clone-mark and (setf
      offset), in order to avoid passing climacs-buffer to marks. This also
      made possible to get rid of delegating methods on syntax.
      climacs.asd: Added Persistent/binseq2.
      packages.lisp: Added binseq2-related symbols.
      Persistent/binseq.lisp, Persistent/obinseq.lisp: Cleanup.
      Persistent/persistent-buffer.lisp: Added code for binseq2-buffer and
      related marks. Also some minor fixes.
    • Robert Strandh's avatar
  3. 11 Mar, 2005 3 commits
  4. 10 Mar, 2005 1 commit
    • Robert Strandh's avatar
      More progress on html-syntax, which may eventually become a model · 5c330694
      Robert Strandh authored
      for many different language syntax modules.
      The display function now traverses the parse tree up as long as a
      valid parse tree exists.  The rest of the display is done from the
      token sequence.  It is likely that all of this can be abstracted out
      and put into syntax.lisp so that html-syntax would just become a
      client among others for this traversal.
      Not only is the cursor still not displayed, whitespace is not handled
      during the traversal of the parse tree.  This will likely be fixed in
      the next few day.
  5. 07 Mar, 2005 1 commit
    • Robert Strandh's avatar
      First attempt at a display function (for html syntax) that uses the · 4f8663ce
      Robert Strandh authored
      output of an incremental lexer and parser.  This code is not complete
        * right now, it uses only the lexer output, and not the parser
        * the cursor is not displayed yet
        * it is too slow, most likely because the output records are all in
          one big bag, as opposed to being tree structured, such as the
          lines of basic syntax.
      The slowness is not a serious problem, because one day, McCLIM will
      have tree-structured output records itself, and because most syntax
      modules (including this one, very soon) will have some tree structure
      itself.  It might be worthwhile to display the part of the buffer
      beyond a parse error in some artificially structured way, such as by
      lines as in the current basic syntax.
  6. 05 Mar, 2005 5 commits
  7. 04 Mar, 2005 1 commit
  8. 02 Mar, 2005 3 commits
  9. 01 Mar, 2005 1 commit
  10. 28 Feb, 2005 1 commit
  11. 27 Feb, 2005 8 commits
  12. 26 Feb, 2005 1 commit
  13. 25 Feb, 2005 2 commits
  14. 24 Feb, 2005 1 commit
  15. 23 Feb, 2005 2 commits
  16. 22 Feb, 2005 4 commits