From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ralf Angeli Newsgroups: gmane.emacs.devel Subject: Re: [reveal-mode] Hiding short expressions Date: Sat, 03 Jul 2004 20:03:29 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1088877799 6206 80.91.224.253 (3 Jul 2004 18:03:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Jul 2004 18:03:19 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Jul 03 20:03:13 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bgor3-0005To-00 for ; Sat, 03 Jul 2004 20:03:13 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bgor3-0002ch-00 for ; Sat, 03 Jul 2004 20:03:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bgosv-0000EM-Ju for emacs-devel@quimby.gnus.org; Sat, 03 Jul 2004 14:05:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bgosr-0000Ae-Dd for emacs-devel@gnu.org; Sat, 03 Jul 2004 14:05:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bgosp-00009K-TS for emacs-devel@gnu.org; Sat, 03 Jul 2004 14:05:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bgosp-00008z-I4 for emacs-devel@gnu.org; Sat, 03 Jul 2004 14:05:03 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bgoqo-0000Rt-W2 for emacs-devel@gnu.org; Sat, 03 Jul 2004 14:02:59 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bgoqn-0005an-00 for ; Sat, 03 Jul 2004 20:02:57 +0200 Original-Received: from iwi190.iwi.uni-sb.de ([134.96.72.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Jul 2004 20:02:57 +0200 Original-Received: from angeli by iwi190.iwi.uni-sb.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Jul 2004 20:02:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 62 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: iwi190.iwi.uni-sb.de Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:4bTGGq0hAwXHCl8GJemk4Ft6YFA= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25415 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25415 * 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