From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pierre Rouleau Newsgroups: gmane.emacs.help Subject: Re: When is a syntax-propertize-function called when parse-sexp-lookup-properties is t for a current buffer? Date: Tue, 5 Oct 2021 14:45:43 -0400 Message-ID: References: <874k9vz8fx.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6081"; mail-complaints-to="usenet@ciao.gmane.io" To: Emanuel Berg , help-gnu-emacs Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 05 20:51:01 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXpWm-000103-CN for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 05 Oct 2021 20:51:00 +0200 Original-Received: from localhost ([::1]:56866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXpUd-00067H-AF for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 05 Oct 2021 14:48:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXpSx-00065R-7e for help-gnu-emacs@gnu.org; Tue, 05 Oct 2021 14:47:08 -0400 Original-Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]:44010) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mXpRs-000895-8l for help-gnu-emacs@gnu.org; Tue, 05 Oct 2021 14:47:00 -0400 Original-Received: by mail-ed1-x52c.google.com with SMTP id p11so301509edy.10 for ; Tue, 05 Oct 2021 11:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pSiqvCr1+gHGrx2YiIntZTG4BSWC6e8EeiriB9+9ldw=; b=FCMUhBbJVOX4sRprNm6CfYYXKOQCok7aixKlB9R2lJbIDyhxJKJ6A0uhUmOCBOsVxG tjvFIyyrvSqVfJGjovfzCAhgT+NR0uJ4p5+Fj5OEeMRcJtc+d6uo5JK4VqOxKtKuwVrP vhpwD1zEwdtajwjcVua2gGduE3aF5F9Aj2u9AmcTbtBY+yBMEILBA+2EKTtloialixyh lfdFc40HVoSqaNBu2PX799VX/bp5YSbamgGrUpSNk9FMoOFwZJwDrMj39ygQIQLh7J7G 1nnmg1gLz1WnYft+KcuncBmwVy/SwhWYJkkdoyh1Uj1iLZACzZEGuF4Ut5j+OyUBAdvp A3sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pSiqvCr1+gHGrx2YiIntZTG4BSWC6e8EeiriB9+9ldw=; b=thqKM+fEziUa9WcPzXwdXg2HftiNetuzkfD+JL7+FSFjEKztnk3IpGuDKSjCVIBg97 3jPSYf9LhZEW/1oCVShZYsfFCG+h2iXeohHPoeBBNtTPF4pyNh8pEIWkgiNNbKgjYjjr wmsrewDDz1K6a5I5FMmGlHmPRjgarlOB9JevxpuoL8zMNJw1K2bDBpe8nO6/8JFbvCkN dr/AWCU/KQM/B1rmQ+LyayUC36FMKZefDEgGOXnjN6FhcifR5V3nvaE6cmJCKiT/lC3o 07DGCmeZp0qeeAQ8CO9WTXCD/cvCbTQkv6sA4sxZP6WOI39LBrmAqDwPXZDSllFZdYu0 eqsw== X-Gm-Message-State: AOAM5306DTj8Meo+UHddey3BnB1AZNKPuDUhr0BcL3B12g2ixtbQ3gz+ f4gkrbnB7fFI2+Df+8f7zJZButYbd8H5yOo/pd8= X-Google-Smtp-Source: ABdhPJzPH41eA2zGx2uGfsFipmKhin2iB9pW8Nv/x9KOYKDQ6IUo8ZEya1R6NicWvgzipNmoQXWR5jrhZ70o/RXxmEI= X-Received: by 2002:a05:6402:42cd:: with SMTP id i13mr8637609edc.396.1633459554544; Tue, 05 Oct 2021 11:45:54 -0700 (PDT) In-Reply-To: <874k9vz8fx.fsf@zoho.eu> Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=prouleau001@gmail.com; helo=mail-ed1-x52c.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:133584 Archived-At: Well, it never hurts to get the latest Emacs! I'm on GNU Emacs > 29.0.50 so that's quite a difference ... > I want to make it work on all these platforms and 26.1 is a necessary targe= t imposed by non-technical constraints out of my control. > But ... I don't understand 100% what it is you'd like to > happen? Can you describe it in human terms rather? "When I do > ... I'd like this to happen ... and not this ..." ? > No problem. I know the following is long, but I think I need to give some context... I=E2=80=99m trying to add navigation with forward-sexp and backward-sexp inside erlang-mode buffers to support the Erlang Bit Syntax expressions ( https://erlang.org/doc/reference_manual/expressions.html#bit-syntax-express= ions ). Currently, with the latest version of erlang.el, the erlang-mode activates the ability to move to the >> matching the << just after point, but *only* after you just write the Erlang code. So let's say you just wrote the following Erlang statement inside an erlang-mode buffer: Abc =3D << <> || Bin <- [<<3,7,5,4,7>>] >> The statement is not complete, the full-stop has not yet been typed. At this point you can use the backward-sexp command to move the point just before the first < character on the line. And you can also use forward-sexp to come back where you were. Let's say you just type the full-stop (period) to terminate the statement and then hit RET to move point to the next line. From then on, if you place the point just before the first < or after the last >, forward-sexp and backward-sexp do not work: they do not move the point to the matching location. If you save and re-open the file you also lose the matching ability. My understanding of the reason why it stops working is because the erlang.el syntax table, modified by erlang.el `erlang-ensure-syntax-table-is-initialized' does not identify the < and > characters as parens that match another one. The erlang.el code does this: (modify-syntax-entry ?< "." table) (modify-syntax-entry ?> "." table) It assigns punctuation syntax to these characters instead of doing the following: (modify-syntax-entry ?< "(>" table) (modify-syntax-entry ?> ")<" table) The reason the last 2 statements are *not* used is because, > and < are also used, like many other programming languages as comparison operators and in erlang you also have '->', '<-' and '<=3D' operators. Giving open and closing delimiter syntax to the < and > characters would break operations and cause a lot of unbalanced issues. So, I am trying to syntax propertize << and >> to provide ability to navigate across the bit syntax expression by setting the syntax-propertize-function to activate syntax properties to the outer characters of << and >>. To do that I added the following at top level, just before the (defun erlang-ensure-syntax-table-is-initialized ... ) form: (defconst erlang-mode-syntax-propertize-function (syntax-propertize-rules ("\\(<\\)<" (1 "(>")) (">\\(>\\)" (2 ")<"))) "Syntax properties to activate << >> pairing.") And I added the following inside of erlang-ensure-syntax-table-is-initialized after the code that sets up the syntax table for Erlang : (setq-local parse-sexp-lookup-properties t) (setq-local syntax-propertize-function erlang-mode-syntax-propertize-function) After byte compilation and testing I was expecting that I'd see the syntax-table text property of all outer characters of << and >> bit syntax inside the erlang buffer to be activated allowing me to navigate across their edges with forward-sexp and backward-sexp. But that does not work: I still cannot navigate with forward-sexp and backward-sexp and the outer << and >> characters do not have the text properties I thought they would have. I check inside the buffer if parse-sexp-lookup-properies is t and it is. I also check in the buffer if syntax-propertize-function is set and it is set to what I expect. Yet I do not see a change of behaviour from what the non-modified erlang.el code provides. Therefore my question as to *when* the syntax-propertize-function should take effect and how I can see if it is applied. --=20 /Pierre