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?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Tue, 9 Jul 2019 12:05:09 -0400 Message-ID: References: <20190703105804.GA11238@ACM> <20190704165846.GF5564@ACM> <20190704190100.GG5564@ACM> <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <9d579361-cc1e-d2c0-e4f2-a0e62dba32f2@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="232101"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Cc: emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 09 18:14:27 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 1hksl2-000xq1-6g for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 18:14:25 +0200 Original-Received: from localhost ([::1]:51558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkseQ-0001zG-Do for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 12:07:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54899) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkscV-0000K1-PX for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:05:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkscU-0001A9-4k for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:05:31 -0400 Original-Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]:41907) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkscR-0000wI-Dp for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:05:28 -0400 Original-Received: by mail-qt1-x844.google.com with SMTP id d17so20741654qtj.8 for ; Tue, 09 Jul 2019 09:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qxkei9imxOk7czLti+62j4X54rUlngcTC6CtK2YHy9w=; b=O2SUq7lE5o+wHo6zT4b0rVqe4i4oWfOnVJavNOCxNAMGxVxlICLeUsTvGJd7Xyecll Mdk5TttoDkt13GqFbSBZs9d5tJ0B3N4w2kv8LPPWJtQgzX5uvn4OP8r3+4/cFUPKAxqB atB26KVmelzjJCaNoWGuVZMJlhbLFRT/GVOEkgBPPlIsdIu/DCMzC+PgvXo1l4cvOZCF r5sQD7kEJBQEEouVZ6Wcruw65n91Bn+Zw3aI/pnCHxC71w1ra+HfT2tN/WwelLy1FO+9 zTKLnH2kvY3R+AxdMGaR84tthWaRDChWRwMmWclg6G/R6z9i4F8n+U7pdaAWYWKiM0VU +8CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qxkei9imxOk7czLti+62j4X54rUlngcTC6CtK2YHy9w=; b=dZntxjYSTVqmgtyUEmOAgyXE0jWEurPr3fw1oLIfIRgiCTeciTczgqpyTj8RmROa4r vKwdaZh+ZMr0HXQKGgXLR4c2tK9onvPB1FA7EMxrQ0JWGi9tiL2gj0fD98Ju380acSay VMolyhmwiNhi1Q8A0zK59ZQmeG6doILcchPxDV595puAbRN+TfWjgz1YINHox2aSb8Vm SNMhRo6ocM2F2eKvgRgnkgrimxi7xBwmdrQuU1X0imh/Q30hsWqFqY3MDJv69Qi7D2WO ZAoVP29zrrkV+9jAD/a3U6blrLAPS64UqSw9EBnFWeUtMotgvckMlOOmM5IvHB8Ln4q/ Fr7Q== X-Gm-Message-State: APjAAAUPpEY6dgEr/IdGV2bKoOcNUHXawR3v91J8DXXGRvJkYoR69jGY kicKp5TRLMwG1IOc2pRLJgPmf6sL X-Google-Smtp-Source: APXvYqyR5cbn9PQ4b7B88SCYTed517dG/bMmDSGnXR85SO6Ha9s0XLP+jdhXkkf5N2BYas5A/yuUmg== X-Received: by 2002:ac8:45d0:: with SMTP id e16mr19145726qto.337.1562688310487; Tue, 09 Jul 2019 09:05:10 -0700 (PDT) Original-Received: from [128.30.93.97] (30-93-97.dynamic.csail.mit.edu. [128.30.93.97]) by smtp.googlemail.com with ESMTPSA id y9sm8620508qki.116.2019.07.09.09.05.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 09:05:09 -0700 (PDT) In-Reply-To: Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::844 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:238462 Archived-At: On 2019-07-09 10:28, João Távora wrote: > > On Tue, Jul 9, 2019 at 1:33 PM Clément Pit-Claudel > wrote: > >> * Fontifying to the end of the line and not past it minimizes refontification in that case >> >> Is that controversial? > > I didn't say it was. You wrote "No, it doesn't". > I don't know what that amounts to" care about: > > - consistency: this is not consistent with how the rest of Emacs works. Which rest of Emacs? I'm saying I'd happily use an option all major modes to work the way Alan did it in cc-mode. > - distraction: this is just as "distracting", and I actually like the current "global > switch" more as it helps me spot the error easily; For me there's no error to spot: in the course of typing a string, I type its opening ", then its contents, and then its closing ". The rest of the buffer being painted in string color is distracting, and it doesn't help me spot any error. >> > Both situations are wrong, and neither is "more wrong" than the other. >> I'm glad we agree. That's why I wrote 'That's not more "correct", of course' > > You seemed to imply there was some kind of advantage. I don't see which, But I told you, didn't I? I said I'd like it better because I don't like my buffers blinking :) > or at least I don't see any advantage that outweighs the fact that this > breaks consistency to virtually all other emacs major modes. It would break consistency with those major modes that allow multi-line unescaped strings, indeed. I'm not too bothered by that. >> > But the version you propose is much harder to implement, likely less >> > efficient, >> Strong words :) Are you saying refontifying the whole screen after the >> point is faster than just refontifying to the end of the line? > > In your model, you are not refontifying "to the end of the line". > You may have meant to say "to the next closing double quote", which may > happen after the end of the screen. No, I meant what I say: to the end of the line. If I have this text: s = "xyz def main(): I prefer def main() to be highlighted as if it wasn't inside a string. > While that may be less text, I would > expect perfomance of (re)fontification to vary according to the thing being > fontified. In the model I'm describing, you don't have to refontify anything except the current line. Am I missing something? >> > It is also >> > useless in languages which do allow unescaped multi-line strings >> And more strong words :) I'm saying it's an option I'd like to have while conceding >> it's not universally better, so it surely wouldn't be useless to me ^^ > > Perhaps I'm not following. What use would it be in a language that > does allow unescaped multi-line strings? Say, what use would it > be in elisp or ruby? That's a good point. I misunderstood your original statement. >> Do we know what behavior is standard in other IDEs, and whether it is configurable?  >> On my machine I have vim, geany, gedit, and vscode, and all of the behave like Emacs >> currently does (but they refontify immediately, without a jit-lock idle delay). > > What are you doing with those other editors installed, you heretic?  > Joke aside, do any of those editors have a paren-matching solution that also > does paren-balancing? I remember searching a bit and not finding anything > interesting. I'm not sure.