Did you already have a look at
http://www-uxsup.csx.cam.ac.uk/java/jdk-1.2.2/demo/jfc/Notepad/ or
file:///yourJDKdirectory/demo/jfc/Notepad/ ?
But I don't know whether the undo/redo implementation there deals with
things like paragraph beginnings. May you can see whether it does, when
playing with its menu item "Debug - Show elements".

Oh, that almost undocumented atrocity ...

Something like this in the event handler:

public void undoableEditHappened(UndoableEditEvent ue) {
   if(ue instanceof AbstractDocument.DefaultDocumentEvent) {
      AbstractDocument.DefaultDocumentEvent de =
                            (AbstractDocument.DefaultDocumentEvent)ue;

      //
      // Apply whatever heuristics you need, to figure out to continue
      // UndoableEdit consolidation in a separate
      // CompoundEdit, to add the separate CompoundEdit, or to add a new
      // edit.
      //
      DocumentEvent.EventType type = de.getType();
      int len = de.getLenght();
           :
           .

   } else {
      //
      // Didn't get specific Document Event, continue to add the
      // otherwise unknown UndoableEdit
      //
      undo.addEdit(ue.getEdit());
   }
}

/Thomas

Instead of having the listener evaluate the edits and decide what to
do with them, I find it's better to have the edits themselves make the
call.  The key is that, when the UndoManager receives an UndoableEdit,
it presents the new edit to the last edit it received and gives it a
chance to absorb the new one.  CompoundEdit only absorbs new edits if
isInProgress() returns true, but you can subclass it and override
addEdit() to change its criteria.  By wrapping all incoming edits in
this subclass, you can have certain edits chain themselves together
automatically, *after* they've been added to the UndoManager.

It still isn't simple, though.  While subclassing CompoundEdit gives
you access to the "edits" field, that doesn't do you much good.  The
actual edit information is still very difficult to get at, and there
isn't really enough of it.  It won't tell you, for instance, whether a
single-character insertion was the result of a keypress or a paste
operation, and a replacement will be seen by the listener as a
deletion followed by an (apparently unrelated) insertion.

What I do is wrap every user-initiated edit in a CompoundEdit subclass
that allows me to assign a unique presentation name to each kind of
operation.  I do this in the Action objects that actually perform the
operations, so there's never any doubt about which "atomic" edits are
part of what operation.  For example, in DefaultKeyTypedAction,
instead of:

   target.replaceSelection(content);

...I would have:

   target.beginCompoundEdit("typing");
   target.replaceSelection(content);
   target.endCompoundEdit();

...where "target" is now an instance of my custom JTextComponent.
Here are the actual methods:

 public void beginCompoundEdit(String name)
 {
   _compoundEditCount++;
   if (_compoundEdit == null)
   {
     _compoundEditNonEmpty = false;
     _compoundEdit = new NamedCompoundEdit(name);
     _compoundEdit.addEdit(
         new CaretEdit(getCaret().getMark(), getCaret().getDot()));
   }
 }

 public void endCompoundEdit()
 {
   if (_compoundEditCount > 0)
   {
     if (--_compoundEditCount == 0)
     {
       _compoundEdit.end();
       if (_compoundEditNonEmpty && _compoundEdit.canUndo())
       {
         _undoer.addEdit(_compoundEdit);
       }
       _compoundEdit = null;
     }
   }
 }

(As you can see, a compound edit may contain other compound edits, or
it may be completely empty--but I don't think either case ever really
happens.  I'll explain about the CaretEdit in a bit.)  While a
compound edit is in progress, it absorbs any atomic edits received by
the listener:

 public void undoableEditHappened(UndoableEditEvent evt)
 {
   if (_undoer != null && !_undoInProgress)
   {
     UndoableEdit edit = evt.getEdit();
     if (_compoundEdit != null)
     {
       _compoundEditNonEmpty = true;
       _compoundEdit.addEdit(edit);
     }
     else
     {
       // never happens
       _undoer.addEdit(edit);
     }
   }
 }

And at last, here's the NamedCompoundEdit class itself:

 /**
  * <p>NamedCompoundEdit allows us to assign a meaningful
  * presentation name to the edit by passing the name to the
  * constructor. Consecutive edits with the same name will
  * automatically be chained together so that they will all
  * be undone at once.</p>
  *
  * <p>Note that, for this to work properly, CaretEdits should be
  * added to the UndoManager whenever the user moves the caret (as
  * opposed to moves that are part of a compound edit or an
  * undo/redo). These insignificant edits will serve as separators
  * between significant edits where appropriate (e.g., if the user
  * types for a while, then moves the caret to another part of the
  * document and types some more, two separate UndoableEdits will be
  * created).</p>
  */
 class NamedCompoundEdit extends CompoundEdit
 {
   private String name;

   public NamedCompoundEdit(String name)
   {
     if (name == null || name.length() == 0)
     {
       throw new IllegalArgumentException("Invalid name: " + name);
     }
     this.name = name;
   }

   public String getPresentationName()
   {
     return name;
   }

   public String getUndoPresentationName()
   {
     return "Undo " + name;
   }

   public String getRedoPresentationName()
   {
     return "Redo " + name;
   }

   public boolean addEdit(UndoableEdit anEdit)
   {
     if (!isInProgress() && !canAbsorb(anEdit))
     {
       return false;
     }

     edits.addElement(anEdit);
     return true;
   }

   private boolean canAbsorb(UndoableEdit anEdit)
   {
     String editName = anEdit.getPresentationName();
     if (editName.equals(name))
     {
       return true;
     }
     else if ("typing".equals(name) &&
         ("Backspace".equals(editName) || "Delete".equals(editName)))
     {
       return true;
     }
     else if ("typing".equals(editName) &&
         ("Backspace".equals(name) || "Delete".equals(name)))
     {
       name = "typing";
       return true;
     }
     return false;
   }
 }

So, if two consecutive edits are received with the same name, the
first one absorbs the second.  I also treat "Delete" and "Backspace"
as equivalent to "typing" because, well, I do a lot of that, and it's
much less annoying this way :/

When an insignificant edit is added directly to the UndoManager, it's
just a placeholder, so CaretEdits serve to separate unrelated edits
without polluting the undo stack. When they're part of a CompoundEdit,
though, UndoManager actually pays attention to them; adding one to the
beginning of every compound edit causes the caret position and
selection to be restored as part or the undo.  I override the
fireCaretUpdate() method to generate the 'dummy' CaretEdits:

 protected void fireCaretUpdate(CaretEvent evt)
 {
   super.fireCaretUpdate(evt);
   _undoer.addEdit(
       new CaretEdit(getCaret().getMark(), getCaret().getDot()));
 }

And here's the CaretEdit class:

 class CaretEdit extends AbstractUndoableEdit
 {
   private int mark;
   private int dot;

   CaretEdit(int mark, int dot)
   {
     this.mark = mark;
     this.dot = dot;
   }

   public boolean isSignificant()
   {
     return false;
   }

   public String getPresentationName()
   {
     return "caret move";
   }

   public void undo() throws CannotUndoException
   {
     super.undo();
     try
     {
       setCaretPosition(mark);
       moveCaretPosition(dot);
     }
     catch (Exception ex)
     {
       throw new CannotUndoException(ex);
     }
   }

   public boolean addEdit(UndoableEdit edit)
   {
     if (edit instanceof CaretEdit)
     {
       edit.die();
       return true;
     }
     else
     {
       return false;
     }
   }
 }

There's a problem with the dummy edits, though.  If I undo an edit,
then move the caret, I can't redo the edit that I just undo'd (dude!).
UndoManager doesn't care that CaretEdits are not significant; it just
throws away the whole redo stack.  I'm going to have to come up with
another way to handle that.