all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: jit-lock-antiblink-grace
Date: Sun, 13 Oct 2019 12:22:11 +0300	[thread overview]
Message-ID: <83o8ylknjw.fsf@gnu.org> (raw)
In-Reply-To: <CALDnm52Y-6PrO9zABOHrMkPEMGAOOr6+XKxDNrSyPChyZZGzdw@mail.gmail.com> (message from João Távora on Sun, 13 Oct 2019 09:47:24 +0100)

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 13 Oct 2019 09:47:24 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > > 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 side thread), where
> > > c-mode was modified in a truly backward-incompatible, uncustomizable way
> > > 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.

All I can say is that I consider each proposal on its own terms, and
try to apply the same considerations in all cases.  There's no higher
standard for you or anyone else, and lower standards for others, at
least not intentionally.

> > Very simply: the behavior is different from what we had previously.
> 
> Of course, there is different behaviour in every feature except a
> refactorization.

No, bug fixes make changes that don't change behavior, not in general.
New features do change behavior, and we normally don't turn them all
on by default, not unless we have a very good reason.

> Do I explain myself?

Yes, but I already knew all that, so there's no misunderstanding on my
part.

> 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.

It's not just the *Messages* buffer: each call to 'message' causes
redisplay, so we will have a flood of redisplays, which is not nice.

> I can use a suitably parameterized
> 'warn', a cl-assertion, an error, or just get rid of it.

Thanks.



  reply	other threads:[~2019-10-13  9:22 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 22:34 jit-lock-antiblink-grace João Távora
2019-10-11 14:26 ` jit-lock-antiblink-grace Stefan Monnier
2019-10-12  9:34 ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-12 10:57   ` jit-lock-antiblink-grace João Távora
2019-10-12 13:02     ` jit-lock-antiblink-grace Juanma Barranquero
2019-10-12 13:14       ` jit-lock-antiblink-grace João Távora
2019-10-12 14:50         ` jit-lock-antiblink-grace Juanma Barranquero
2019-10-12 15:11           ` jit-lock-antiblink-grace João Távora
2019-10-12 15:30             ` jit-lock-antiblink-grace Juanma Barranquero
2019-10-12 13:32     ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-12 14:13       ` jit-lock-antiblink-grace Stefan Monnier
2019-10-12 14:23         ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-12 14:34           ` jit-lock-antiblink-grace Stefan Monnier
2019-10-12 15:57             ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-12 17:16               ` jit-lock-antiblink-grace Stefan Monnier
2019-10-12 17:50                 ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-12 15:47         ` jit-lock-antiblink-grace Alan Mackenzie
2019-10-12 14:23       ` jit-lock-antiblink-grace João Távora
2019-10-12 16:04         ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-12 21:55           ` jit-lock-antiblink-grace João Távora
2019-10-13  6:39             ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-13  8:47               ` jit-lock-antiblink-grace João Távora
2019-10-13  9:22                 ` Eli Zaretskii [this message]
2019-10-13 10:28                   ` jit-lock-antiblink-grace João Távora
2019-10-13 10:45                     ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-14 23:29                       ` jit-lock-antiblink-grace João Távora
2019-10-15  6:48                         ` jit-lock-antiblink-grace Eli Zaretskii
2019-10-15 18:28                           ` jit-lock-antiblink-grace João Távora
2019-11-24  1:04                             ` jit-lock-antiblink-grace João Távora
2019-11-24 16:16                               ` jit-lock-antiblink-grace Eli Zaretskii
2019-11-25 18:46                                 ` jit-lock-antiblink-grace Alan Mackenzie
2019-11-25 19:02                                   ` jit-lock-antiblink-grace João Távora
2019-11-25 19:26                                     ` jit-lock-antiblink-grace Alan Mackenzie
2019-11-25 19:45                                       ` jit-lock-antiblink-grace João Távora
2019-11-25 20:11                                         ` jit-lock-antiblink-grace Alan Mackenzie
2019-11-25 20:23                                           ` jit-lock-antiblink-grace João Távora
2019-11-25 21:07                                             ` jit-lock-antiblink-grace João Távora
2019-11-26  2:30                                               ` jit-lock-antiblink-grace João Távora
2019-11-26 17:58                                                 ` jit-lock-antiblink-grace Eli Zaretskii
2019-11-30 19:11                                                   ` jit-lock-antiblink-grace João Távora
2019-11-30 19:22                                                     ` jit-lock-antiblink-grace Eli Zaretskii
2019-11-30 20:12                                                       ` jit-lock-antiblink-grace João Távora
2019-11-30 20:16                                                         ` jit-lock-antiblink-grace Eli Zaretskii
2019-11-30 20:19                                                           ` jit-lock-antiblink-grace João Távora
2019-11-30 20:41                                                             ` jit-lock-antiblink-grace Eli Zaretskii
2019-11-30 22:00                                                               ` jit-lock-antiblink-grace João Távora
2019-12-01 18:13                                                                 ` jit-lock-antiblink-grace Eli Zaretskii
2019-12-04 22:45                                                                   ` jit-lock-antiblink-grace João Távora
2019-12-05 15:40                                                                     ` jit-lock-antiblink-grace Eli Zaretskii
2019-11-26 13:43                                           ` jit-lock-antiblink-grace Stefan Monnier
2019-11-25 19:47                                       ` jit-lock-antiblink-grace Dmitry Gutov
2019-11-25 20:03                                         ` jit-lock-antiblink-grace João Távora
2019-10-12 16:14         ` jit-lock-antiblink-grace Alan Mackenzie
2019-10-12 22:26           ` jit-lock-antiblink-grace João Távora
2019-10-13 10:18             ` jit-lock-antiblink-grace Alan Mackenzie
2019-10-13 10:48               ` jit-lock-antiblink-grace João Távora
2019-10-13 12:02 ` jit-lock-antiblink-grace Alan Mackenzie
2019-10-13 19:57   ` jit-lock-antiblink-grace João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83o8ylknjw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.