From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.bugs Subject: bug#15312: Info (point-entered, point-left): Doc incomplete, hence incorrect Date: Fri, 13 Sep 2013 10:52:25 +0530 Message-ID: <877gel1ejy.fsf@gmail.com> References: <87ppsiw22k.fsf@gmail.com> <83sixej6iz.fsf@gnu.org> <878uz573kr.fsf@gmail.com> <83fvtck8mv.fsf@gnu.org> <87hadrel77.fsf@gmail.com> <83zjrjiifl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1379049675 11033 80.91.229.3 (13 Sep 2013 05:21:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Sep 2013 05:21:15 +0000 (UTC) Cc: 15312@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 13 07:21:18 2013 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 1VKLoj-0007Ei-9W for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Sep 2013 07:21:17 +0200 Original-Received: from localhost ([::1]:44828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKLoi-0006tR-JE for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Sep 2013 01:21:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKLoa-0006s8-Ac for bug-gnu-emacs@gnu.org; Fri, 13 Sep 2013 01:21:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKLoU-00086c-D8 for bug-gnu-emacs@gnu.org; Fri, 13 Sep 2013 01:21:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKLoU-00086Y-9q for bug-gnu-emacs@gnu.org; Fri, 13 Sep 2013 01:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VKLoT-0001Ru-Pq for bug-gnu-emacs@gnu.org; Fri, 13 Sep 2013 01:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jambunathan K Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Sep 2013 05:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15312-submit@debbugs.gnu.org id=B15312.13790496185511 (code B ref 15312); Fri, 13 Sep 2013 05:21:01 +0000 Original-Received: (at 15312) by debbugs.gnu.org; 13 Sep 2013 05:20:18 +0000 Original-Received: from localhost ([127.0.0.1]:60452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VKLnk-0001Qn-V2 for submit@debbugs.gnu.org; Fri, 13 Sep 2013 01:20:17 -0400 Original-Received: from mail-pa0-f51.google.com ([209.85.220.51]:50213) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VKLng-0001QX-H6 for 15312@debbugs.gnu.org; Fri, 13 Sep 2013 01:20:13 -0400 Original-Received: by mail-pa0-f51.google.com with SMTP id lf1so2075284pab.10 for <15312@debbugs.gnu.org>; Thu, 12 Sep 2013 22:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=vq/5IJQ4YIYOEXsaxpfcinI5rEo5xwXHMy6uwZXxsDE=; b=oU5/mfFyEopaHdEZztA1V4rZDyn7teZHmg9SECh0s4gNj7jqBmWe+XG/N5Hvn3G8uN t8s41SGaXrKAp46u08yF058go524WCUNCs5lHTd5ZFFchjE9KwcOHvUWvtTs6pBZ0a2z WMBBizAXlvvLONqp0NrwVHeNGWkQneJzCrsW1SzpmhZFuFR0YxKYDC8Ev2eoIAeY2Fro BnAPbiD7zfII6uoXXM3OqmmPdC94RIRAgY1hyPPk/PUYNKcqDTj0JvqC0imSfETfG3ng hMPjMzG+/TcHcmc7GKNzqN4vsuH1jPWWLJOcPj3ozUNwFGYWSfBiqapzimaWmmQLHQyL +ToA== X-Received: by 10.68.212.106 with SMTP id nj10mr11475155pbc.74.1379049606601; Thu, 12 Sep 2013 22:20:06 -0700 (PDT) Original-Received: from porunai ([115.242.146.7]) by mx.google.com with ESMTPSA id qp10sm15241487pab.13.1969.12.31.16.00.00 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Thu, 12 Sep 2013 22:20:05 -0700 (PDT) In-Reply-To: <83zjrjiifl.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 11 Sep 2013 16:42:06 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:78315 Archived-At: Eli > Info (point-entered, point-left): Doc incomplete, hence incorrect You asked for a wall-of-text. Here you go. ---------------------------------------------------------------- Imagery: If a hotel is interested in taking visitors why should it even care how it is painted or that it be painted differently from the neighbouring hotels? ---------------------------------------------------------------- Unask the question: Consider the following scenario? 1. The WHOLE buffer has the SAME point-visited property. 2. The whole buffer has NO OTHER text properties applied to it. Under the above conditions, can the user use the point-visited property achieve a sensible behaviour. The answer is an emphatic YES. Read on. ---------------------------------------------------------------- On relevance and expedience: You are making a WRONG ASSUMPTION that text properties MUST flip-flop. The flip-flopping of text properties is a mere chunking trick to rate-limit point visited calls. It is a requirement IMPOSED FROM OUTSIDE (and which can usually be met in practice) but is not GERMANE to the problem at hand. ---------------------------------------------------------------- What (usually) are text properties, in this context? In this context, the text properties act as a pre-computed syntactic context. The requirement that properties flip-flop is but a way of saying that a stretch of text be syntactically different from the surrounding text. ---------------------------------------------------------------- Can uniqueness be expressed in other ways, apart from text properties? Yes. With parsers, it is possible to infer a context JUST-IN-TIME. Should parsers be expected to decorated text? Not necessary. There could be reasons why parsers don't decorate text. One reason could be that it is young. One example, is the Org parser. (Font-locking and the ppss stuff is just a poor man's parser) ---------------------------------------------------------------- Stop the bullshit. Give an example? See http://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00425.html (add-hook 'org-mode-hook (lambda nil (setq-local default-text-properties '(point-entered org-link-entered-maybe)))) (defun org-link-entered-maybe (op np) (when (derived-mode-p 'org-mode) ;; (message "In org-link-entered-maybe") (let* ((inhibit-point-motion-hooks t) (ctx (org-element-context))) (when (eq 'link (org-element-type ctx)) (tooltip-show (org-element-property :raw-link ctx) (not 'use-echo-area)))))) In the above example, the context - that the character is part of a link - is computed JIT to pop open a tooltip that shows the underlying URL. ---------------------------------------------------------------- Can text properties express rich context with less OVERHEADS? Text properties (typically) break the text in to pieces. They can express UNIQUENESS. Can they express the much richer, UNIQUENESS and CONTAINMENT - I am an Org link, within the second item, of the third level list within 4 th level heading - in a fully-synced manner. I think the answer is NO. Since Text Properties are pre-computed text, it becomes messy to keep them in SYNC with an ever-changing text. Expressed simply, JIT eliminates the caches and problems associated with it. ---------------------------------------------------------------- In what ways can a character be special? A character can be special for the following reasons 1. Syntactic: It's position in the buffer text - A hyperlink, variable name etc. 2. Spatial: A character that belongs to the margins. i.e., to the left of `left-margin'. ---------------------------------------------------------------- Text properties cannot express spatial uniqueness Can text properties be used for expressing spatial uniqueness? Good luck with it. ---------------------------------------------------------------- Spatial uniqueness and text properties. I am noting this only because this was the primary motivation to explore point-visited properties in first place. How to edit a left-marginned text and make sure that point never rests on the margin area. Think of a diary or a todo item. They are a MIX of indented and un-indented text. Left-marginned text, no problem? (setq left-margin 16) (setq indent-line-function 'indent-to-left-margin) I want C-p and C-n to actively seek indented text. No problem. C-x C-n I want C-a not to actively rest within on text area and NEVER stray in to the margins. I am at a total loss here. How will I do it? 1. Play with tangibility of `\n +'. I need to mess with `indent-line-function'. I don't want to keep decorating and un-decorating a character for spatial reasons. 2. Let me look at other possiblities. Ha! point-entered and point-left looks interesting. ;; Within point-entered property. (if ( < (current-column) left-margin) (goto-char left-margin)) This is very wonderful, I don't even have to set the goal column. 3. Hmm! Doesn't work. Why? Because document sucks? ----------------------------------------------------------------