From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Newsgroups: gmane.emacs.devel Subject: Re: font-lock-syntactic-keywords obsolet? Date: Mon, 20 Jun 2016 08:40:12 +0200 Message-ID: References: <57627D13.5090008@online.de> <5764F25B.4010204@online.de> <20160618171249.GA5796@acm.fritz.box> <20160619133143.GA5875@acm.fritz.box> <20160619145934.GC5875@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466404606 3921 80.91.229.3 (20 Jun 2016 06:36:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 06:36:46 +0000 (UTC) Cc: Alan Mackenzie To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 08:36:38 2016 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 1bEsoz-0002zw-Rf for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 08:36:34 +0200 Original-Received: from localhost ([::1]:41589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEsoy-0005BG-KD for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 02:36:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEsoO-0005B5-HK for emacs-devel@gnu.org; Mon, 20 Jun 2016 02:35:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEsoK-0006p0-BX for emacs-devel@gnu.org; Mon, 20 Jun 2016 02:35:55 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.133]:50352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEsoJ-0006ot-W3 for emacs-devel@gnu.org; Mon, 20 Jun 2016 02:35:52 -0400 Original-Received: from [192.168.178.35] ([77.12.77.196]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0MgCZR-1b0OKh0wlB-00NPtX; Mon, 20 Jun 2016 08:35:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 In-Reply-To: <20160619145934.GC5875@acm.fritz.box> X-Provags-ID: V03:K0:pHrCzcWMIFMjb5YBNsvpzkJhcpgM2pTUqsv1yjQBEZtj6tEYId7 FUHe85ZHx86CmWvVyiH0FMumSMiytpGvYwo1DkG8zyK6JIZ5pqyt8R3g/j0DA0QMZr8EXan C6wM+o0NH/kVDnH5NEHR8b3PXHlQhQiZpHGEWJ8StmCkf9hD85MjmxHjJUTHoK+xNPjtQl+ fzHByTTc/MREYcSbHM4vw== X-UI-Out-Filterresults: notjunk:1;V01:K0:3IGeqPCwNhw=:hYaCm4tZvr39GmIE8eODR+ BjuYlZOppTCf2FD/ZmQv1wy+R1+J224MJBr9vUmjPolZLSnNkms2rqJreOV/KyKZz2yIu8eBb 0SReLTjUEPwwQBSo8T1EYai1gTgto0vgsEIxxVBkpNTfh2BuXen6V5J7Y3nLe/TQi4HYOuo09 1lOLvSB/r32BSlEEiRzce/iyEaFLHtViJVFCmQ4/gi+FOowz7713u/xez4mmFz4FbhecSAfiy LaMS1EqmfaVHE+0Gopw8mGtVNZ0K/tJDblRIAKws1tyAjhIaV8mHXTypsND9YBJ+lUGKiUTcv 8hzG3H5pYx+fpHV1FPMGEUTJPaNz6ro2OqM3qhRtGLV4xfBkpvTYf13Opmjbiz72NP8DYCUem MaBPaFqnN47vN/yI7eNFCCuRnRfMoDGjDrerBGl5ACIXIPCM3+PNS2x8PucR6QRRR3Ws+I43K 0uGDFx/EbGTn3K3UVgAknd+KWn/2OVJrkbfXvixBjF1luHm0087UmF7NJ+NG5KdKp/fkrSIaU 1sD59TBQq9x/jMhuFEpE2RoUimsjO9Z5I0S2qgYZ8NUOyZEiFFoz2d4knkFRkYSlD6N2a171q qaLYgeHVfQsH/43tFsO8O8+JFHsql9MTY7yXJoTw3HDX5dNxrJ96Meck5FcyJHyQeNRximQNu l5fYK1JS1/EVViDBmkRpe929sWi10ASYC/87hyYTVrqHfSKS4lG123nQDjr1mHrupuRIGV7IX oUpCedMyEa0aGI+Y X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.126.133 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:204568 Archived-At: On 19.06.2016 16:59, Alan Mackenzie wrote: > [ ... ] > If you remove (from a C++ buffer) a terminating template > delimiter (">"), that will have the effect of removing the syntax-table > text property from its former matching opener ("<"). > > Hmm, is this reasonable? Quoting from your post later on: ;;; Consider the following non-unusual case. In C++ Mode we have nested template delimiters, thusly: A B C D < < > > They each have parentheses syntax-table text properties such that A matches D and B matches C. You can, for example put point at A, do C-M-n, and you will get to after D. Suppose you delete the < at A, and move point to D. What will now happen if you do C-M-p? At the moment, D no longer has a s-t property, so it will not (mis)match any other character with paren syntax. ;;; If balance is broken by removing "A", why should C-M-p work? It should send an error instead, i.e. the remaining "D" _should_ mismatch. Looks like a suitable issue to reduce complexity - or do I miss the point? Cheers, Andreas