Re: [reveal-mode] Hiding short expressions

[Ralf Angeli]

* Stefan (2004-07-03) writes:

> Indeed, I think it should be decided on an overlay basis rather than for the
> whole buffer.  But I don't like forcing an indirection through `category',
> so I'd just do (overlay-get ol 'reveal-close) which also obeys the
> `category' prop if present.

This would be fine with me.  I'd use the symbol 'reveal-on-cursor-out,
though.

> Also I expect that a heuristic such as "is
> there a linefeed within the overlay" would provide a pretty good
> starting point without needing any extra tag on the overlays.
>
> The rationale for it is that the behavior that "keeps overlay opened when
> point is on same line" is mostly useful to allow the user to use C-p and
> C-n without spuriously closing the overlay because the C-p jumps to just
> a bit before the beginning.  At least that was my experience when working
> on it.

So you want to achieve that if you have a paragraph of text and the
cursor moves downward into an empty line while the paragraph and
therefore the overlay ends at the end of the line before, the overlay
does not get collapsed.  For the downward case you could probably do
it like this (I don't know if there even is a problem with the upward
case):

--8<---------------cut here---------------start------------->8---
--- /usr/local/share/emacs/21.3.50/lisp/reveal.el       2004-07-02 
22:08:23.000000000 +0200
+++ reveal.el   2004-07-03 19:42:46.000000000 +0200
@@ -116,12 +116,10 @@
      (dolist (ol old-ols)
        (when (and (eq (current-buffer) (overlay-buffer ol))
                  (not (rassq ol reveal-open-spots)))
-        (if (and (>= (point) (save-excursion
-                               (goto-char (overlay-start ol))
-                               (line-beginning-position 1)))
-                 (<= (point) (save-excursion
-                               (goto-char (overlay-end ol))
-                               (line-beginning-position 2))))
+        (if (and (>= (point) (overlay-start ol))
+                 (<= (point) (if (= (overlay-end ol) (line-end-position))
+                                 (line-beginning-position 2)
+                               (overlay-end ol))))
             ;; Still near the overlay: keep it open.
             (push (cons (selected-window) ol) reveal-open-spots)
           ;; Really close it.
--8<---------------cut here---------------end--------------->8---

But wouldn't it be cleaner to extend the respective overlay by this
one character instead of trying to code around it with a trickery
like above (which includes the code already inside of reveal.el)?

Additionally a heuristic based on the presence of line breaks in the
overlay may easily produce a wrong result for an overlay inside of a
paragraph of text which coincidently ends at the end of a line.  You
would have to add further logic to cater for these cases.  So
personally I'd prefer working with additional properties or even
better, extending the overlays which would get collapsed too early.

-- 
Ralf