From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#11068: 24.0.94; Face-remapped background does not extend to end of window Date: Fri, 30 Mar 2012 09:35:20 +0200 Message-ID: <4F756238.1080004@gmx.at> References: <1BE52A40-0403-433F-8164-DFDBD6771F80@gmail.com> <83ty1fvc28.fsf@gnu.org> <83obrmtbsy.fsf@gnu.org> <4F6DCF31.3060609@gmx.at> <83fwcyt7f0.fsf@gnu.org> <4F6E24FD.2070907@gmx.at> <83wr69sp4e.fsf@gnu.org> <4F6F1574.2090904@gmx.at> <83r4wgsii6.fsf@gnu.org> <4F6F6FCF.30806@gmx.at> <837gy8s64w.fsf@gnu.org> <4F701547.6070003@gmx.at> <4F718710.4040203@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1333092959 3345 80.91.229.3 (30 Mar 2012 07:35:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2012 07:35:59 +0000 (UTC) Cc: darthandrus@gmail.com, 11068@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 30 09:35:58 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SDWNG-0005Zc-3c for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2012 09:35:54 +0200 Original-Received: from localhost ([::1]:42136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDWNF-0008Ae-GR for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2012 03:35:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDWN8-00088w-3f for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 03:35:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SDWMz-0000if-SF for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 03:35:45 -0400 Original-Received: from [140.186.70.43] (port=39090 helo=debbugs.gnu.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDWMz-0000gI-P7 for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 03:35:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SDWrO-0001MQ-Ca for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2012 04:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Mar 2012 08:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11068 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11068-submit@debbugs.gnu.org id=B11068.13330948175218 (code B ref 11068); Fri, 30 Mar 2012 08:07:02 +0000 Original-Received: (at 11068) by debbugs.gnu.org; 30 Mar 2012 08:06:57 +0000 Original-Received: from localhost ([127.0.0.1]:45922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SDWrI-0001M6-Ie for submit@debbugs.gnu.org; Fri, 30 Mar 2012 04:06:57 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:34909) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SDWrG-0001Lz-Jr for 11068@debbugs.gnu.org; Fri, 30 Mar 2012 04:06:55 -0400 Original-Received: (qmail invoked by alias); 30 Mar 2012 07:35:22 -0000 Original-Received: from 62-47-46-219.adsl.highway.telekom.at (EHLO [62.47.46.219]) [62.47.46.219] by mail.gmx.net (mp031) with SMTP; 30 Mar 2012 09:35:22 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX193M0M84TJ3/yQlj8OJ2/y30YN07sbvisqD1K/OI8 J7HuoqJ/evZW1I In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:58315 Archived-At: > ... By putting the > integer property on the string itself, you allow the > cursor-positioning code to find out how many buffer positions are > covered by the overlay string, without knowing what overlay is that. > >> "this way, >> Emacs will display the cursor on the character with that property >> regardless of whether the current buffer position is actually >> covered by the overlay." >> >> doesn't make it clearer for me because what is "the character with that >> property" and what is "the current buffer position" here? > > "the character" is the one from the overlay string on which you put > the `cursor' property; "current buffer position" is point (which > normally determines where to display the cursor). I still don't get it. Suppose I have the following code in a buffer, no spaces before the first visible character, one newline after the last: (defvar my-overlay nil) (defvar my-string nil) (progn (when (overlayp my-overlay) (delete-overlay my-overlay)) (setq my-overlay (make-overlay 0 0)) (setq my-string (propertize " " 'face 'lazy-highlight 'cursor 1)) (overlay-put my-overlay 'display my-string) (move-overlay my-overlay (- (point-max) 1) (point-max))) Evaluating this and moving `point' between buffer positions 336 and 337 oscillates the cursor around the overlay. If I instead use the line (propertize " " 'face 'lazy-highlight 'cursor 2)) in the above and reevaluate, moving `point' doesn't oscillate the cursor any more. But if I additionally replace the last line as (move-overlay my-overlay (- (point-max) 2) (point-max))) the cursor oscillates again (but now between positions 335 and 337). I find the behavior good but am too silly to understand what's going on. What do I really specify when I write a form like (propertize " " 'face 'lazy-highlight 'cursor 1)) Apparently the "1" doesn't refer to a position within the " " but to some position within the buffer from (- (point-max) 1) (point-max)) where that string is eventually placed by the overlay movement. So apparently that specification neither serves to (1) move the cursor visually to some position within the string (it always remains before or after it), nor to (2) move `point' to some position within the buffer (it's always at the start and end positions of the overlay). But what does it do? > You can see > this feature in action in cua-rectangle; after you play with it, > perhaps you could suggest how to improve the documentation. IIUC in the Emacs sources the 'cursor property is never used in connection with overlays. martin