emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs master + org Wrong type argument: number-or-marker-p


From: Eli Zaretskii
Subject: Re: emacs master + org Wrong type argument: number-or-marker-p
Date: Thu, 04 Aug 2022 12:06:45 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  acm@muc.de,  gregory@heytings.org,
>   mattiase@acm.org,  philipk@posteo.net,  silent2600@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 04 Aug 2022 16:42:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We decided that we do want to impose our opinion, because not doing so
> > results in Emacs being unusable, which is a long-standing gripe of our
> > users.
> 
> Since this problem wasn't bad enough for major mode developers to care
> about in the past, what makes you think they will fix it now?

Nothing.  I actually don't really expect them to do anything in this
regard, which is why solving that in display code sounds like a much
better alternative.

> IMHO, it is much better to make what can be fixed right now (by being
> present in the Emacs repository) explictly use the "new" narrowing, and
> not interfere with user code that does not concern us.

I cannot parse this, sorry.  What do you mean by "being present in the
Emacs repository"? who or what should be present there?  And what do
you mean by "the new narrowing"?  And what does "user code", whatever
that is, have to do with this issue?

> And what if someone wants to write a fontification function whose
> results depend, for example, on a single character at a known position
> outside of the accessible region? That cannot result in a freeze

I cannot reason about something as abstract and theoretical.

One thing you need to keep in mind: fontifications never have only a
local effect.  If some part of the buffer is re-fontified, it can
potentially affect all the rest of the buffer, because display layout
calculations are affected.  So "cannot result in a freeze" is
extremely optimistic, IME.  But again, unless you show some code and
explain how is that a real-life use case that should be of interest,
this discussion is not useful.

> > fontification-functions are not user code.
> 
> Anything not under our control is user code that we are forcing
> restrictions onto.

Not in my book.  At least the major modes that come with Emacs are not
"user code" and are under our control.

> > Long-running timer functions, if they are not interruptible, are a
> > clear bug in the package that does such things, so any such timers
> > will come back as a boomerang to those developers.
> 
> I'm just trying to demonstrate what will happen once the forced
> narrowing starts to interfere with the operation of various pieces of
> third party code, which might possibly be discovered some time after
> Emacs 29 is released.  Long-running fontification was not a significant
> source of complaints for their developers in the past, and things are
> likely to remain that way.

Users did and do complain about locked-up Emacs when they try to edit
files with long lines.  They just didn't realize one of the reasons
was font-lock (or syntax-ppss), so they didn't complain specifically
about that.  But every complaint you see about these situations is
basically a complaint about font-lock and its syntax-parsing parts.

Anyway, this discussion doesn't lead anywhere.  We have decided to try
this way of solving a long-standing problem in Emacs, and no amount of
talking will cause us to change that decision.  Only code that makes
font-lock and syntax.c significantly faster, and/or reports about
specific issues (as opposed to general semi-philosophical concerns)
caused by these changes, can affect both the implementation of these
changes and our future decisions about its defaults.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]