From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: An issue with electric mode Date: Sat, 18 Apr 2020 20:21:16 +0100 Message-ID: References: <333003530.125426.1587227922906@mail1.libero.it> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000088cf1605a39592f9" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="82690"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Angelo Graziosi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 18 21:27:34 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jPt7m-000LOd-A3 for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Apr 2020 21:27:34 +0200 Original-Received: from localhost ([::1]:60958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPt7l-0002Tm-Bf for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Apr 2020 15:27:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38956) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPt5e-0001UD-Ek for emacs-devel@gnu.org; Sat, 18 Apr 2020 15:26:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jPt1w-0004pR-JV for emacs-devel@gnu.org; Sat, 18 Apr 2020 15:25:22 -0400 Original-Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]:42158) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jPt1v-0004kS-Fj for emacs-devel@gnu.org; Sat, 18 Apr 2020 15:21:31 -0400 Original-Received: by mail-io1-xd36.google.com with SMTP id y17so6259795iow.9 for ; Sat, 18 Apr 2020 12:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HWR24CvWLTJsL1DUkbqnJz8kGDmiWccd1SS1FrtPvsQ=; b=Mk5oTAWBwUDNHwAx4PpqV0poFKJEw1seMtcjDHxVF7CQL1D5OxvLgtF0pZ0hHmlb2D 55Oh22jMJ+ALTu6ONyjHDhrdGdxoq/xSWtzKK2N0AIbIesAlO8yCrmjtUajHu6mg242R 7zo18VmNU3PI4rZdtvL7mONvYlykIZiEaIwNYvBpcVL2yE/GWJkjrd2K3il29LbF8Sno rclDKqqT8AoJGW/4K+kVBqm7NYli9Hm3C3KS8sUjsLWZtC4NTyByVcUaeEW9FGuBHYn8 l+HxsMnOKun3iT3anLbJuP025m0kU5M+H8qde9pT4sAj8AWAi3sQUxYkqfzBWNKCrGtZ ZCbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HWR24CvWLTJsL1DUkbqnJz8kGDmiWccd1SS1FrtPvsQ=; b=HWf2BVWXTDco/hzAsx1T4pSv/bQIg4gaZnX7SVZupdTAsf1fFNHIzhJJXamRbG/jlS 5L8L+ypaOVkVBB3uMU3V/4ULvMVWWIKdyblZYbIO8CQmyXdb6e5evpNJYOsTlGxbZiPc fuWRU8uRvKb7pS9g6023qC0mj/sBU+IvZMgl3rvYXUmEDmOuQ8/v2BYEjbROIlu5RQns ttiQpSGejLXMu6eyZChNro6Y2KpoYkmXD8aqQdQdevssKB+1z1ZXabWgUJC+LkvXf3yC EZyo8y+YlN5uG1KytCG7A8eMspatdyCcdOZPRthSe6ut/S8O6+4Oz4jxlAdEajyZCHqq jyMQ== X-Gm-Message-State: AGi0PuYsbNiL9UTLI5EfIt+YbNqkRBj91qB0wQNjMLJPhKrIpF3iYSti VFziq3YFMncRdkuw4HhFXKAkBhKdOVIKDTL6hmM= X-Google-Smtp-Source: APiQypJ3hu9Cac4WPIhPmbfXzIbdovHeu2HWnyxu3t6OERW6xZ2GQVKINNg7pCg0H+lR5aiKG/evx+wia27Fudr2Z8Y= X-Received: by 2002:a02:58c3:: with SMTP id f186mr9105566jab.120.1587237687446; Sat, 18 Apr 2020 12:21:27 -0700 (PDT) In-Reply-To: <333003530.125426.1587227922906@mail1.libero.it> Received-SPF: pass client-ip=2607:f8b0:4864:20::d36; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd36.google.com X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d36 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247241 Archived-At: --00000000000088cf1605a39592f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is this the right behavior? Yes, I think so. Let me try to remember how I reasoned about this when I implemented this around 2014. In modes whose syntax table defines different types of paired delimiters (braces and parenthesis), such as here, you would want to be notified first and foremost that the closing brace is unmatched. Which is what happens here. As soon as you give the closing brace an opening brace to match against, the opening and closing parenthesis resume the expected matching. But what if the closing brace isn't really an element of the language you're editing, as seems to be the case in your .adoc files? Well, in that case, the major mode has to know about it. So I suspect that if you change the syntax table to define the backtick as a string delimiter, things will magically start working as you intend them. Let me try: (modify-syntax-entry ?` "\"") Yep. Try that in the buffer. It should fix it. Of course such a line should ideally be in a major mode definition for your files. Some: (define-derived-mode asciidoctor-mode prog-mode "Adoc" (modify-syntax-entry ?` "\"") ... likely more stuff ...) Notice that the brace is still unmatched inside the string. That is also by design. Because matching delimiters insider strings and comments follow largely the same logic (but isolated for that domain). If the brace really has no special meaning in your language, the major mode must also know about that (but by default braces have meaning). HTH, Jo=C3=A3o --00000000000088cf1605a39592f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Is this the right behavior?

Yes, I think so.=C2=A0 Let me try to remember how I r= easoned about
this when I implemented this around 2014.
<= /div>

In modes whose syntax table defines different type= s of paired
delimiters (braces and parenthesis), such as her= e, you would
want to be notified first and foremost that the= closing brace is
unmatched. Which is what happens here.=C2= =A0 As soon as you give
the closing brace an opening brace to mat= ch against, the
opening and closing parenthesis resume the e= xpected matching.

But what if the closing brace is= n't really an element of the
language you're editing= , as seems to be the case in your
.adoc files?=C2=A0 Well, in= that case, the major mode has to know
about it.=C2=A0 So I = suspect that if you change the syntax table to
define the backtic= k as a string delimiter, things will magically
start working= as you intend them.=C2=A0 Let me try:

=C2=A0=C2= =A0 (modify-syntax-entry ?` "\"")

Y= ep. Try that in the buffer.=C2=A0 It should fix it.=C2=A0 Of course such
a line should ideally be in a major mode definition for your
files.=C2=A0 Some:

(define-derived-mo= de asciidoctor-mode prog-mode "Adoc"
=C2=A0 (modify-syn= tax-entry ?` "\"")
=C2=A0 ... likely more stuff ..= .)

Notice that the brace is still unmatched inside= the string.
That is also by design.=C2=A0 Because matching delim= iters insider
strings and comments follow largely the same logic = (but
isolated for that domain).=C2=A0 If the brace really has no = special
meaning in your language, the major mode must also
<= /div>
know about that (but by default braces have meaning).
=C2=A0
HTH,
Jo= =C3=A3o
--00000000000088cf1605a39592f9--