From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs master + org Wrong type argument: number-or-marker-p Date: Wed, 03 Aug 2022 04:57:56 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33292"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Alan Mackenzie , Eli Zaretskii , 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 Wed Aug 03 11:00:46 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 1oJAFB-0008Sy-LC for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 11:00:45 +0200 Original-Received: from localhost ([::1]:43416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJAF9-0004Kc-S4 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 05:00:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJACi-0002tF-73 for emacs-devel@gnu.org; Wed, 03 Aug 2022 04:58:12 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55615) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJACa-0004OZ-6p; Wed, 03 Aug 2022 04:58:10 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A6D3E44064E; Wed, 3 Aug 2022 04:58:01 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 752C2440097; Wed, 3 Aug 2022 04:58:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659517080; bh=Af136b4jlWJ+XTDwMiATFYsPDutX+9JqpXJ/Nsmu/Zs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=l8PYSdacED0fbFB9JOavkGx8qCo0Zjbs5bVyMdICuss9UVhz63XLr6VyDDqLAnozj 5WVQQCB8ViTs0MAsAPO/R2STxG1Ri8Rh6hwfZ9Dt8g3U0bidWmXRtpPOwQSfBPmEYZ HKQNL40UxfzIOunHSAv8S5ZUbZkjrbGCLTm1K8ISusbg3KmTbfOKg3duTJ91ZmGwWX 9HKfWYAzWAFP0tgKXmTBxz3zexFNJHETMlYEx6MJF47YxD67nve9dgL+K/yoB1YiVt DzcfY/ejZSPOT5/Q/g260BfhvXHVAHRy/G+Ubs27IamuAsncpi5blVEb4rcrdktDE5 Lr2Xl0NnKzb8Q== Original-Received: from milanesa (unknown [46.44.221.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 12F461203D4; Wed, 3 Aug 2022 04:57:58 -0400 (EDT) In-Reply-To: <87wnbqcebn.fsf@yahoo.com> (Po Lu's message of "Wed, 03 Aug 2022 09:21:00 +0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:293007 Archived-At: > Is there really a slowdown associated with allowing code to widen > outside the bounds specified by redisplay long-line "optimizations"? Or > are we speculating about a hypothetical problem that doesn't exist > again? There is a real problem here: currently font-lock will widen right back. There might be a few more cases where widening will happen currently, but I think font-lock is the main one. IMO we should specifically fix those few cases we encounter, rather than add to the narrowing complexity (which tends to encourage major modes to widen since they basically can never know why a narrowing is in effect) by imposing a "locked narrowing". Stefan