From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: mvar Newsgroups: gmane.emacs.bugs Subject: bug#39277: 26.3; Tcl font lock does not understand quoting Date: Tue, 03 Nov 2020 21:47:53 +0200 Message-ID: <87k0v2w7bq.fsf@cnu407c2zx.nsn-intra.net> References: <20200125100009.33e3cpgmjszmpwzq@gentoo-zen2700x> <87lffs1zvw.fsf@cnu407c2zx.nsn-intra.net> <875z6v36lv.fsf@gnus.org> <87sg9ze6yj.fsf@cnu407c2zx.nsn-intra.net> <87y2jmr763.fsf@cnu407c2zx.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5295"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: mvar , Lars Ingebrigtsen , 39277-done@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 03 20:49:41 2020 Return-path: Envelope-to: geb-bug-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 1ka2JF-0001BL-RE for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Nov 2020 20:49:37 +0100 Original-Received: from localhost ([::1]:41648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ka2JE-00021W-NK for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Nov 2020 14:49:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ka2Ig-0001zn-NW for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2020 14:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34963) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ka2Ig-0000iA-EX for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2020 14:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ka2Ig-00065u-DJ for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2020 14:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: mvar Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Nov 2020 19:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39277 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 39277-done@debbugs.gnu.org id=D39277.160443288623340 (code D ref 39277); Tue, 03 Nov 2020 19:49:02 +0000 Original-Received: (at 39277-done) by debbugs.gnu.org; 3 Nov 2020 19:48:06 +0000 Original-Received: from localhost ([127.0.0.1]:46505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka2Hm-00064N-FE for submit@debbugs.gnu.org; Tue, 03 Nov 2020 14:48:06 -0500 Original-Received: from mail-ej1-f42.google.com ([209.85.218.42]:38042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka2Hk-00063q-3h for 39277-done@debbugs.gnu.org; Tue, 03 Nov 2020 14:48:04 -0500 Original-Received: by mail-ej1-f42.google.com with SMTP id za3so26038426ejb.5 for <39277-done@debbugs.gnu.org>; Tue, 03 Nov 2020 11:48:03 -0800 (PST) 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; bh=Bk+eD4kaR+0qS9l3fw2oeJi17F4IYI2O3bFIrvd5czU=; b=CKdBlhs5tjOcmZxlkfislaPLD9tc2KYGKy4HhOSrPUG0G8As994v6MMcn/Z0jfo5Vx gavfLTZ1I+IhhbFE6qmhk1Tsh+N4tUdhvjSBzuAXVzXl4GWsHUq9v2s6kg+dWEBwDFoF SzYVreyHuW5SzXAsrERF2TWyIq9gZXfZHk7npmAaRFrqL1YG5Lrk3TR4lI2QFui9JMLk HYagZxFJN2zf6W8NX96T/fqI3c0EwWbwIuq/mU+tdvzfmZyab2mCWtakAY1al2hu6IwB Tt7I3/Ol0OUHuSOy8X8DjJG5bDAhzwJb6AR8aaJxFVfpbr8mRQWRZsigh//XYJhjLDmQ hfPw== 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; bh=Bk+eD4kaR+0qS9l3fw2oeJi17F4IYI2O3bFIrvd5czU=; b=nXK0WJQCqVK68asZtHqLEBTb4q+RD65pNlUqcf/4qo9t/EefgXIHV9Dmk8iB8BUWxU KhLjeqo42hnhfAkf8Yaap1IQ1MXFI2a3nkYrGjCectOwwVaxegGnrn8q5qna2Fz0DpFM iXk18JS89+8XDpq0H6R8BYBC4wYEQ5sgh45AKVxumApGOdLnTCCaXcxa3Bf68ZbiccEG EC33JT2E8CAUp/LN8l/Vi9qsWpo+PceY8JXCeN25rJT6HNJMV0BlaH1HSnGe+NiRik+y 0gDNpYxndP6nlcUryrtpUNNyfywe7SO8PHpkN5/bsP6+s8lIPHXEnO34sKr0BJIRy6Cc da3Q== X-Gm-Message-State: AOAM530cBEcRAKTTr6Df5lcG41irOdQTeF6CZSAQkJ1pZ6AJ2Jm6E0Db O/fdWoZHy1eZXL9tfbeUyx8V1K/zSn3sbsfu X-Google-Smtp-Source: ABdhPJzS1nFOsqSuICEXZUsLir9lDq3z60ouI3VTadXUArD7MUAq2s7jHLiLll2ZscE3ki3aPTu7Sg== X-Received: by 2002:a17:906:31c1:: with SMTP id f1mr22476120ejf.253.1604432877709; Tue, 03 Nov 2020 11:47:57 -0800 (PST) Original-Received: from cnu407c2zx.nsn-intra.net ([2a02:2149:8883:1d00:5078:f6d:4914:61bf]) by smtp.gmail.com with ESMTPSA id d10sm8977808ejw.44.2020.11.03.11.47.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 11:47:57 -0800 (PST) X-Google-Original-From: mvar In-Reply-To: (Stefan Monnier's message of "Sat, 31 Oct 2020 09:20:12 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192645 Archived-At: Stefan Monnier writes: >> The original case is solved >> (although the enclosed {"string} is not font-locked as string but I >> wouldn't consider it an error) > > Yes, this is a separate problem and I can't see how to fix it: since > "everything's a string" in Tcl, it's really not clear what > `font-lock-string-face` should apply to and what it shouldn't apply to. > > The current design is to use it only where "..." is used. When the code > is fully under your control it lets you choose (to some extent at least) > what is highlighted and what is not (by choosing "..." vs {...}), but > clearly it won't be "right" in all cases. > >> plus it fixes the following: >> >> proc foo4 () { >> puts "hello}" >> } >> >> this was marked as valid before your changes but tclsh won't accept it >> as such - the bracket } inside the string needs to be escaped when >> inside a proc context (but as a plain statement there's no such >> requirement). > > Indeed. > hi again, i stumbled upon a not-so-rare case where this fix breaks a previously valid syntax locking. Example: set a "Testing: [split "192.168.1.1/24" "/"] address" the closing ] is marked as unmatched (no matching parenthesis found) notice how the above statement is evaluated by tclsh/wish: % set a "Testing: [split "192.168.1.1/24" "/"] address" Testing: 192.168.1.1 24 address % the problem with the unmatched ] can only(?) be solved by escaping both inner "strings" set a "Testing: [split \"192.168.1.1/24\" \"/\"] address" but then this is evaluated into an array % set a "Testing: [split \"192.168.1.1/24\" \"/\"] address" Testing: {} 192.168.1.1 24 {} address i still consider the previously applied fix as an overall improvement, so perhaps i should open a new bug report for this problem? btw i tried to come up with some fix but i'm still a looong way from grasping those syntax & parsing mechanisms (syntax-ppss and friends) thanks, Michalis