From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs master + org Wrong type argument: number-or-marker-p Date: Thu, 04 Aug 2022 12:06:45 +0300 Message-ID: <831qtw4btm.fsf@gnu.org> References: <83tu6v27yh.fsf@gnu.org> <6F871C02-AC26-4B89-B64B-E9F4ACACDBE7@acm.org> <83sfmf26b6.fsf@gnu.org> <835yja7o7j.fsf@gnu.org> <83v8ra5uee.fsf@gnu.org> <87wnbqcebn.fsf@yahoo.com> <83o7x259wg.fsf@gnu.org> <87edxyc5ds.fsf@yahoo.com> <83iln95yd7.fsf@gnu.org> <83o7x04kul.fsf@gnu.org> <87tu6sa5uf.fsf@yahoo.com> <83czdg4h7p.fsf@gnu.org> <87k07oa2ie.fsf@yahoo.com> <837d3o4eyn.fsf@gnu.org> <87v8r88kna.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26389"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, mattiase@acm.org, philipk@posteo.net, silent2600@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 11:09:34 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oJWrG-0006gk-6y for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 11:09:34 +0200 Original-Received: from localhost ([::1]:53554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJWrF-0006ou-6a for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 05:09:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJWoi-0004X1-3w for emacs-devel@gnu.org; Thu, 04 Aug 2022 05:07:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36856) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJWoe-0002Mv-LL; Thu, 04 Aug 2022 05:06:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TntdeV6i326f2LtHxGWN8hClX1pBW0nx9TZ6RTG19pw=; b=fCva8QPep3qe HHhTcL7fbTLQuMt6gaBgv+WbOJIicRaS48kbobS+i31j0bbhMR0vMz4lTTTVxzEkXEDPStqO+GYZu FrRYj02KpcHZ+kzmehsA8TEzmwp8onI56tgAutUWt8RjW807cKHwm6Qe1u6MTpTjws2Rn/1fh13At Tq5p9tu2yj4FcqFireAtc7w7h9EJXJNPJAUN85qcPf4rPAxgtS+ltdAEAHrHnKKsAh5updi3teZQE Mz+tMNyPUhsyKNU3cBCcA1ZscZ6Kzf+EfMCTl7G7b9AeXPuzKEoS3G4TWVzMpsaG7agtwgQIcJ/LN /oYVMbbao1B6yDiUs5fyrg==; Original-Received: from [87.69.77.57] (port=2038 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJWod-0001el-CP; Thu, 04 Aug 2022 05:06:52 -0400 In-Reply-To: <87v8r88kna.fsf@yahoo.com> (message from Po Lu on Thu, 04 Aug 2022 16:42:33 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293047 Archived-At: > From: Po Lu > 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 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.