From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= Newsgroups: gmane.emacs.devel Subject: Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Wed, 03 Jul 2019 20:25:34 +0200 Message-ID: <87wogz561t.fsf@gmail.com> References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@ACM> <20190702182811.GC30597@ACM> <20190703105804.GA11238@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="50833"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Alan Mackenzie , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 21:16:21 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hikjs-000CyO-0F for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 21:16:20 +0200 Original-Received: from localhost ([::1]:38700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hikah-0001Jj-S8 for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 15:06:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60010) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hijwu-0004xs-Va for emacs-devel@gnu.org; Wed, 03 Jul 2019 14:25:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hijwt-0004Ql-GJ for emacs-devel@gnu.org; Wed, 03 Jul 2019 14:25:44 -0400 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:52054) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hijwt-0004P2-6g for emacs-devel@gnu.org; Wed, 03 Jul 2019 14:25:43 -0400 Original-Received: by mail-wm1-x336.google.com with SMTP id 207so3210677wma.1 for ; Wed, 03 Jul 2019 11:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=aUFhrD1AV0HNCIA8FkBa+LeNyBulENl1bcrCEtIdOd8=; b=R6RBnJEK47HgJSwaQBUo8mfIY7pDoDC+hfm/E70xyX/U/q7YZVX3Idyb+7Lnedi0HN qGiwf3vPasfp0RWBCTn/aYNadxtgYtZavmzu8wbVkHn4xlnic7XwJQy1VMHo4ENsDIOB RWBXSpQd3G/978WI5+AeUz+oOiDn8BIC8yDZJRC5ozNThxgTxCi+Yv82kwWds652zaSW SfHOATGdnKbnGpjqSvbLeEw630IIyOQi81xhrfCHNH0o1YlH9QJu/3Vh7/5sT53lt2L1 bg7HqgGNXT+6A6FuUrpupDseCafNHXIoH7OqIpstHS8JHTsUcE3kyjUKKWlL2lcLY477 3vkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=aUFhrD1AV0HNCIA8FkBa+LeNyBulENl1bcrCEtIdOd8=; b=LOx5ykMP5xxjrteUKdYJ1N6urOReS4otAP7P59WMx2RyXKj2i2ZGTJwbADR/KaVkNJ feijzNhy136KshM5dQcBz/G6vgECe1nPBTfDXcVSdWZwoOovG8OftiHN6ftglDp7BaPE lXghSfkaZkbaGsFwYNzGhi+9RduJo8FoldgvU1cygNDa8BhyHaF92QWCl7x4fuRUX+a0 t1HDM11RaCLazqkKCHnnTYDHBaazroaxbXJlBALGzjodNKvAJIcJt2mVOz0YfTolus8V 7/BmflMc1/H5BCOQBPEYQRFSYqzwzBA/f5DakCrXrbJui5ASI2m3/B1qp/sy6a0z+H8V NHtg== X-Gm-Message-State: APjAAAVNgzxxIQls1C20OyEAXB9gT4+PvahSl2CTW/BVIJvWuRz17N4M OblDF1oAD/OqYWWfGpwbqfObmXy9q5xJhg== X-Google-Smtp-Source: APXvYqxZTnzmkiyFc8Dl8KfYRt0FTHFgL0qD0ZiTlQD8HYsDmY5vleUXfwy68Vb71cZkFdy3s6tw/w== X-Received: by 2002:a05:600c:2199:: with SMTP id e25mr8504418wme.72.1562178339943; Wed, 03 Jul 2019 11:25:39 -0700 (PDT) Original-Received: from my-little-tumbleweed (71.142.13.109.rev.sfr.net. [109.13.142.71]) by smtp.gmail.com with ESMTPSA id h11sm3911915wrx.93.2019.07.03.11.25.38 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 03 Jul 2019 11:25:39 -0700 (PDT) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Wed, 3 Jul 2019 14:31:58 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::336 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238338 Archived-At: Jo=C3=A3o T=C3=A1vora writes: >> can you suggest some other mechanism by >> which CC Mode can create the required font-locking? If you can, and >> it's workable, we all win. > > No, I can't, but I've asked others to chime in. I would personally do it > (in fact I already do do it) via flymake-mode. To expand on that a bit=E2=80=A6 AFAICT from its documentation, flymake aims to be "a universal on-the-fly syntax checker for GNU Emacs". It is distributed as a core Emacs library, and as an ELPA package requiring Emacs 26.1. Looking at this situation from afar[1], invalid-syntax highlighting sounds exactly like the kind of feature that could be implemented as a flymake backend[2]. ( Although I guess the question then moves to "How would the *backend* implement this feature?" to which I have no answer, knowing nothing of either flymake's API or CC mode's invalid-syntax detection process. Abstractly, I guess that would imply - lifting some fontification code off CC mode since I assume the flymake frontend would handle the presentation, - keeping the invalid-syntax detection code, - marshalling the information it gathers into flymake "diagnostics". ) >From this excerpt of the discussion of bug#36474[3]: Alan Mackenzie writes: >> 4. Someone reinvents electric-pair-mode in cc-model.el. >> Let's not do this. > > No, let's not do that! :-) =E2=80=A6 I understand that it is a shared principle that there is no intrinsic value to CC mode implementing features that another library already provides[4], as that complicates maintenance. Anyway, this was my very abstract reading of the situation; if I knew the actual code better, I could probably come up with a truckload of reasons why *as things stand now*, tearing the highlighting feature apart and banging on it until it fits flymake's API is not the path of least resistance. Therefore, feel free to disregard. [1] "Long-time-user-long-time-lurker-no-contribution-to-speak-of"-kind of afar. [2] Quoting (flymake) Backend functions: > A backend=E2=80=99s responsibility is to diagnose the contents of a > buffer for problems, registering the problem=E2=80=99s positions, typ= e, > and summary description. This information is collected in the > form of diagnostic objects created by the function > =E2=80=98flymake-make-diagnostic=E2=80=99 (*note Flymake utility func= tions), and > then handed over to Flymake, which proceeds to annotate the > buffer. [3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36474#8 [4] Although in this particular case, CC mode strives to support Emacs =E2= =89=A5 24.5, so depending on flymake would limit the feature to Emacs =E2=89=A5 26.1.