From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 188f657: Fix false negatives in tex--prettify-symbols-compose-p. Date: Tue, 29 Sep 2015 14:14:53 +0100 Message-ID: References: <20150925210512.18505.12538@vcs.savannah.gnu.org> <8737xxjtkq.fsf@gnu.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1443582532 27028 80.91.229.3 (30 Sep 2015 03:08:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 03:08:52 +0000 (UTC) To: Artur Malabarba , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 30 05:08:51 2015 Return-path: Envelope-to: ged-emacs-devel@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 1Zh7lC-0006d2-Rd for ged-emacs-devel@m.gmane.org; Wed, 30 Sep 2015 05:08:50 +0200 Original-Received: from localhost ([::1]:56711 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh7lC-0004xx-8n for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2015 23:08:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgukC-0005oi-0M for emacs-devel@gnu.org; Tue, 29 Sep 2015 09:14:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgukA-00037D-Tw for emacs-devel@gnu.org; Tue, 29 Sep 2015 09:14:55 -0400 Original-Received: from mail-la0-x22f.google.com ([2a00:1450:4010:c03::22f]:34046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgukA-00035y-Fu for emacs-devel@gnu.org; Tue, 29 Sep 2015 09:14:54 -0400 Original-Received: by labzv5 with SMTP id zv5so8031489lab.1 for ; Tue, 29 Sep 2015 06:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=YjQ4mL0x6cuQffwMwHkuK8bpipL8txKOTKm1z0dmN2Q=; b=FQal1b7uHHDoB3IXdR4v8sumEi138/QS1Ie2k9FGhE9co3yYin3UNLGFh+f2NFwLEn F7yIC8y5vHNpDtlAQaYLM7Uk1tvFMI4J30H8ED6mISHZiN/OYZCxHeiK9oNuE/zvO5WL whX+L/Gcg4+n5lth5PGEblZWvScLV3WWyl22F3jZMcRszjPEvhjrvBDLDL1nVZLkk5m4 UfkPZdcMvJorPgmyTo/kAO+QfAYklLXG6IhI0A5ZavC16FwuhEWd4OSss78QhooLng94 INaAczn60K+kWZTA7dOpFdM0ZowlL6I48g6ZwE7l9iOK3dlpevvJJIFmNJ3S3yQBWZfn LYPQ== X-Received: by 10.112.146.104 with SMTP id tb8mr7384606lbb.35.1443532493633; Tue, 29 Sep 2015 06:14:53 -0700 (PDT) Original-Received: by 10.25.27.78 with HTTP; Tue, 29 Sep 2015 06:14:53 -0700 (PDT) In-Reply-To: <8737xxjtkq.fsf@gnu.org> X-Google-Sender-Auth: VloSyOZbZjqQAbBY44VBkoiP5RE X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190481 Archived-At: 2015-09-29 13:31 GMT+01:00 Tassilo Horn : > Artur Malabarba writes: > >> Would it be possible to also use `tex--prettify-symbols-compose-p' to >> avoid composing the symbol-at-point? (perhaps by checking window-point >> or something). That would toggleable by a user-option, of course. > > You mean, when point enters a prettified symbol the original text would > be shown? Indeed, that sounds like a neat idea. If I think about it, I > don't use prettification in LaTeX exactly because there are so many > prettified symbols which partly overlap and then editing becomes > cumbersome, e.g., when deleting a char from the prettified integral \int > you'll get the prettification of the set membership relation \in. Yes. I like prettify-symbols quite a bit, but this slight inconvenience when editing symbols prevents me from using the mode right now. >> Or maybe that feature should be implemented in `prettify-symbols-mode' >> itself. > > Yes, I think the only thing to be done would be to change the > > (if (funcall prettify-symbols-compose-predicate start end match) ... > > in `prettify-symbols--compose-symbol' to > > (if (and (or prettify-symbols-compose-at-point > (< (window-point) start) > (> (window-point) end)) > (funcall prettify-symbols-compose-predicate start end match))) I was actually thinking of using `<=', so that placing point at the edges would already be enough. > where `prettify-symbols-compose-at-point' would be the user option. I tried something similar, and unfortunately it's not that simple. Firstly, (window-point) didn't seem to work as expected here, so I had to define a variable in font-lock-mode to hold the value of (point) before fontification started. After doing that, the feature sort of works while you're writing. That is, it doesn't prettify a symbol you've just written, but it does prettify a symbol after you hit SPC, which is nice. However, it does not work while navigating. That is, when you move point to a prettified symbol, it doesn't get decomposed. Then I tried adding a post-command-hook function to invalidate the font-locking at point. This correctly decomposes a symbol when you move the cursor to it, but it's still not perfect. When you move the cursor *out* of the symbol, if you move far enough, the symbol doesn't get prettified again until you edit something close to it.