unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ralf Angeli <angeli@iwi.uni-sb.de>
Subject: Re: [reveal-mode] Hiding short expressions
Date: Sat, 03 Jul 2004 20:03:29 +0200	[thread overview]
Message-ID: <cc6scf$5vb$1@sea.gmane.org> (raw)
In-Reply-To: m1smc92fty.fsf-monnier+emacs@gnu.org

* 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

  reply	other threads:[~2004-07-03 18:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-02 21:05 [reveal-mode] Hiding short expressions Ralf Angeli
2004-07-02 21:37 ` Stefan
2004-07-03 12:07   ` Ralf Angeli
2004-07-03 17:01     ` Stefan
2004-07-03 18:03       ` Ralf Angeli [this message]
2004-07-03 18:56         ` Stefan
2004-07-03 19:26           ` Ralf Angeli
2004-07-06 19:07         ` Kevin Rodgers
2004-07-06 19:34           ` Ralf Angeli
2004-07-06 19:56             ` David Kastrup
2004-07-07 13:32             ` Stefan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='cc6scf$5vb$1@sea.gmane.org' \
    --to=angeli@iwi.uni-sb.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).