From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: jit-lock-antiblink-grace Date: Sun, 13 Oct 2019 09:47:24 +0100 Message-ID: References: <834l0enw8c.fsf@gnu.org> <83y2xqm6m4.fsf@gnu.org> <83o8ymlzkk.fsf@gnu.org> <835zktm9o0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000085ae370594c6cdbe" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="99327"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Monnier , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 13 10:47:51 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 1iJZXa-000PbL-II for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 10:47:50 +0200 Original-Received: from localhost ([::1]:38336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJZXZ-0001Rf-FY for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 04:47:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52686) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJZXR-0001RF-K7 for emacs-devel@gnu.org; Sun, 13 Oct 2019 04:47:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJZXP-0006gD-QH for emacs-devel@gnu.org; Sun, 13 Oct 2019 04:47:41 -0400 Original-Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]:37414) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iJZXN-0006aY-Bj; Sun, 13 Oct 2019 04:47:37 -0400 Original-Received: by mail-io1-xd2c.google.com with SMTP id b19so30598834iob.4; Sun, 13 Oct 2019 01:47:37 -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=VLWHTOlTxqjY6QOn7bbqGLYO69ZqaKi3mYfO4Y/t0co=; b=XsM2YA3uVk+/7D5pYtWLdBMwb7OCDRGhdW36N70xDJ37iaCY6gSOVruVv8vfkZQub9 a34bsbtQbuOPsm6wbquadyCsWN7kmCTd28CY+Z3HSk8t89mTd0a3xsq59bjSlFFRTB62 FrbgdsPywGPKzKDiFE/YtGnN4clAA1yetK3iyjMsiZDomG+plewjwdCOixocMvbUAclQ ePKrzPLmLqrxlRpogJD6/gcyL6oIfUfy3pSdUv6wMzTkKHDL6SDVSLJKdwtkPv5XLkXS oQAyI/JqRYmLAiPSQPqp7LRYOf5mz1q9TOlMQ0PLNrI0iiXwBqszZexhLA9UQVryzCe2 e5PQ== 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=VLWHTOlTxqjY6QOn7bbqGLYO69ZqaKi3mYfO4Y/t0co=; b=kMCbadPWt8ScFHzA+CzTAjbZTmpUd1iJaEahR1QhQfl+0LD7lxuuIiyNrxc8aA3CwN V0mTFazaTRVFYcs2N7s+eY6NuOxcEGcXFNvnRBrrNNeYV93VYvmidhTIvZostPm6kFDy Fc3oAOtRoPyttHx+qhvzxpyAfe3eIc0L9oqDNAX3/N27AO7jj3UufFmIjtUay7kagy4u NSLYxzu+/G8VcaslP4FYxTgsTXP74Doj5e4v8QVhK53vYmTar1SQekogu4nCqZvIQ6G2 lJDlGiSgHT55emP269dUwHkJMVLaelaKksv1xXQ0jxd31R6amqurcEbLEWArp8SJxSXh XAdA== X-Gm-Message-State: APjAAAUJNKCtNslAj8dENOcLdbXVoIPqpVjzfuE7QwH+KtgLBylFFXQV aHkd0AfWYbcj8qzXXD+9RIn6HA86pFCwUtGSZmUe1Or8UDI= X-Google-Smtp-Source: APXvYqw8L/3jQrgg7aIZdTlwc/ZGI4b8hEPjrsm7SoLddLk2wJflcgFgGnaeG9gbGkd3vMyEOSu4qgqr3mKOJj/NwtA= X-Received: by 2002:a02:3081:: with SMTP id q123mr30023222jaq.24.1570956456077; Sun, 13 Oct 2019 01:47:36 -0700 (PDT) In-Reply-To: <835zktm9o0.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2c 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:240949 Archived-At: --00000000000085ae370594c6cdbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 13, 2019 at 7:39 AM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Sat, 12 Oct 2019 22:55:29 +0100 > > Cc: emacs-devel , Stefan Monnier < monnier@iro.umontreal.ca> > I didn't figure out the details, I thought it should be easy to do. > Don't we already do something like that in all kinds of places? The > :set attribute of a defcustom comes to mind, for example. > Alternatively, the timer you add could notice the change and take that > action. And I'm sure there are more ways of doing that. Or maybe I'm > missing something. I had already mentioned :set, but iiuc it only works via customize. The other techniques you mention are the (relatively) hacky ones I had in mind, too. > > > When I find a backward-incompatible change, I usually do try to see i= f > > > it's justified. So I think I already do what you ask me to do in > > > those other cases. > > > > From what I can remember, you didn't weigh in on the specific case I wa= s > > referring to (the one being brought up again in the side thread), where > > c-mode was modified in a truly backward-incompatible, uncustomizable wa= y > > to address a related problem. > > I don't remember the particular case, but I can make mistakes, can I? > Anyway, I'm not sure I understand what you are trying to say here. > Are you saying that I treat you differently from others? If so, > that's not the case, and if I said something that could be interpreted > otherwise, I apologize. All I'm trying to say is one of the motivations for my proposed feature A is to be an alternative to another feature B in Emacs (which I consider harmful) and you are holding my feature to a higher standard (regarding backward compatibility, performance, doc, etc) than you did the other one. In absolute terms, that's just fine, but in relative terms there is a discrepancy that was trying to understand. If it was simply an oversight, it's perfectly OK. > > Furthermore, calling my proposed change > > "backward-incompatible" is something I don't fully understand. Perhaps > > you can clarify: what behaviours, actions, etc. were observed before > > that aren't observed now? > Very simply: the behavior is different from what we had previously. Of course, there is different behaviour in every feature except a refactorization. > Previously, starting a new comment would give me an almost immediate > visual feedback; now that feedback is delayed by 2 sec (more, or even > not at all, if I continue typing). How can we know that everybody > will instantly like this new behavior? Hmmm. We might be miscommunicating (or you might be seeing a bug). When you start to type a comment or a string, you still get "almost immediate visual feedback" just you did before. This has not changed at all. If the command you just performed, say, insert or delete a quote: 1. _created_ a situation if unbalanced quotes at EOL, then the typical "flipping" of the fontification of many lines _after_ the current is delayed, because the system believes you will probably solve the situation within jit-lock-antiblink-grace seconds; 2. _restored_ a situation of balanced quotes, then everything should be as before. A core assumption here is that the user very rarely wants to create deliberate unbalance of strings. Those users, were they to exist in great numbers, would probably be bothered by the grace delay. Anyway, it is only in situation 1 that the amplitude of "visual feedback" is reduced, because the system considers the extra visual feedback related to the real possibility of inserting a multi-line string, is alarmist/premature/unjustified. Do I explain myself? > > > > Run-time consistency assertions are useful, right? > > > Only as a debug option, > > Yes, I agree. But there is really no "debug" in Emacs, only > > debug-on-error. > That's not so: various packages define their own debug facilities. I meant Emacs-wide, of course. There is display-warning-minimum-level and warning-minimum-log-level tho, which I wish were easier to control. > Examples include Tramp and smtpmail.el. We could add a debug facility > to jit-lock.el as well, if you think it's important for this feature. I don't (and I don't like these package-specific solutions). And that's precisely why I settled on a 'message' as a middle-of-the-road solution. Anyway, your point seems to be to minimize the probability of incessant debug chatter in *Messages* which would supposedly render an Emacs with a buggy jit-lock.el unusable. I can use a suitably parameterized 'warn', a cl-assertion, an error, or just get rid of it. Jo=C3=A3o --00000000000085ae370594c6cdbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Oct 13, 2019 at 7:39 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > F= rom: Jo=C3=A3o T=C3=A1vora <joao= tavora@gmail.com>
> > Date: Sat, 12 Oct 2019 22:55:29 +0100=
> > Cc: emacs-devel <em= acs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> I didn't figure= out the details, I thought it should be easy to do.
> Don't we a= lready do something like that in all kinds of places?=C2=A0 The
> :se= t attribute of a defcustom comes to mind, for example.
> Alternativel= y, the timer you add could notice the change and take that
> action.= =C2=A0 And I'm sure there are more ways of doing that.=C2=A0 Or maybe I= 'm
> missing something.

I had already mentioned :set, but = iiuc it only works via customize.=C2=A0 The
other techniques you mention= are the (relatively) hacky ones I had in
mind, too.

> > &g= t; When I find a backward-incompatible change, I usually do try to see if> > > it's justified.=C2=A0 So I think I already do what you= ask me to do in
> > > those other cases.
> >
> = > From what I can remember, you didn't weigh in on the specific case= I was
> > referring to (the one being brought up again in the sid= e thread), where
> > c-mode was modified in a truly backward-incom= patible, uncustomizable way
> > to address a related problem.
&= gt;
> I don't remember the particular case, but I can make mistak= es, can I?
> Anyway, I'm not sure I understand what you are tryin= g to say here.
> Are you saying that I treat you differently from oth= ers?=C2=A0 If so,
> that's not the case, and if I said something = that could be interpreted
> otherwise, I apologize.

All I'= m trying to say is one of the motivations for my proposed feature
A is t= o be an alternative to another feature B in Emacs (which I
consider harm= ful) and you are holding my feature to a higher standard
(regarding back= ward compatibility, performance, doc, etc) than you did
the other one.= =C2=A0 In absolute terms, that's just fine, but in relative
terms th= ere is a discrepancy that was trying to understand.=C2=A0 If it was
simp= ly an oversight, it's perfectly OK.

> > Furthermore, calli= ng my proposed change
> > "backward-incompatible" is som= ething I don't fully understand.=C2=A0 Perhaps
> > you can cla= rify: what behaviours, actions, etc. were observed before
> > that= aren't observed now?
> Very simply: the behavior is different fr= om what we had previously.

Of course, there is different behaviour i= n every feature except a
refactorization.

> Previously, starti= ng a new comment would give me an almost immediate
> visual feedback;= now that feedback is delayed by 2 sec (more, or even
> not at all, i= f I continue typing).=C2=A0 How can we know that everybody
> will ins= tantly like this new behavior?

Hmmm. We might be miscommunicating (o= r you might be seeing a bug).=C2=A0 When
you start to type a comment or = a string, you still get "almost immediate
visual feedback" jus= t you did before.=C2=A0 This has not changed at all.=C2=A0 If
the comman= d you just performed, say, insert or delete a quote:

1. _created_ a = situation if unbalanced quotes at EOL, then the typical
"flipping&q= uot; of the fontification of many lines _after_ the current is
delayed, = because the system believes you will probably solve the
situation within= jit-lock-antiblink-grace seconds;

2. _restored_ a situation of bala= nced quotes, then everything should be
as before.

A core assumpti= on here is that the user very rarely wants to create
deliberate unbalanc= e of strings. Those users, were they to exist in
great numbers, would pr= obably be bothered by the grace delay.

Anyway, it is only in situati= on 1 that the amplitude of "visual
feedback" is reduced, becau= se the system considers the extra visual
feedback related to the real po= ssibility of inserting a multi-line
string, is alarmist/premature/unjust= ified.=C2=A0 Do I explain myself?

> > > > Run-time consi= stency assertions are useful, right?
> > > Only as a debug opti= on,
> > Yes, I agree.=C2=A0 But there is really no "debug&quo= t; in Emacs, only
> > debug-on-error.
> That's not so: v= arious packages define their own debug facilities.

I meant Emacs-wid= e, of course.=C2=A0 There is display-warning-minimum-level
and warning-m= inimum-log-level tho, which I wish were easier to control.

> Exam= ples include Tramp and smtpmail.el.=C2=A0 We could add a debug facility
= > to jit-lock.el as well, if you think it's important for this featu= re.

I don't (and I don't like these package-specific solutio= ns).=C2=A0 And that's
precisely why I settled on a 'message'= as a middle-of-the-road solution.
Anyway, your point seems to be to min= imize the probability of incessant
debug chatter in *Messages* which wou= ld supposedly render an Emacs with
a buggy jit-lock.el unusable.=C2=A0 I= can use a suitably parameterized
'warn', a cl-assertion, an err= or, or just get rid of it.

Jo=C3=A3o
--00000000000085ae370594c6cdbe--