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: Major modes using `widen' is a good, even essential, programming practice. Date: Mon, 08 Aug 2022 14:47:41 +0300 Message-ID: <834jynvtwi.fsf@gnu.org> References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22295"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 13:51:39 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 1oL1II-0005em-MU for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 13:51:38 +0200 Original-Received: from localhost ([::1]:47908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL1IH-00013I-Po for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 07:51:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL1En-0005j9-Bz for emacs-devel@gnu.org; Mon, 08 Aug 2022 07:48:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43578) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL1Eg-0006K2-NF; Mon, 08 Aug 2022 07:48:01 -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=PDiHFHf+B7tbWvpY5iU4ebwbRik0z3qqiTKbN+0F8ic=; b=CNHOp88RKghI cKPKUbz1OL/9CQPV8OvI1zkNH5RawcCa8FdwFTh8QO6JfyBOvyzZcqv9EKIie3e0Ab0RKZVcdOsOM 1RzJn0UnZ10Jl1Xq4+mCG1rkTSCaUVyhYQUnu2uY1LLhOVltPWS11Bppb4V8Cs3Ue87bFBlq9yXvu 4doc4JJPkzeGPb4p/PyaL+3JpPqUu/ZLtUuOuLPcxnoqkVIYPcBgK54WT3XeBnzPNsli9Tp8cmQVh 3tPjYU+Fc9+goOqiJ0uz6bP340kkbRAZILqGH5d4DZoK8/nMd/yrFr5JPlAPmn6rsY7bqaR2t+NUQ DinCi5cun+RZfzbNqDmjug==; Original-Received: from [87.69.77.57] (port=2319 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 1oL1Eg-000508-2U; Mon, 08 Aug 2022 07:47:54 -0400 In-Reply-To: (message from Lynn Winebarger on Mon, 8 Aug 2022 07:16:44 -0400) 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:293259 Archived-At: > From: Lynn Winebarger > Date: Mon, 8 Aug 2022 07:16:44 -0400 > Cc: Eli Zaretskii , Alan Mackenzie , gregory@heytings.org, > emacs-devel > > I know CC mode relies on heuristics to identify syntactic structures, and not a full parser (whether from > semantic or LSP), but it seems the issue is that you don't have a parse state for the beginning of the > narrowed buffer, where an initial parse state is inappropriate. Assuming that text outside the narrowing is > not allowed to change, determining the appropriate parse state should only be required once on narrowing. > So, could there be a pre-narrowing hook to run before narrowing takes effect to allow a major mode to > determine the appropriate parse state for the beginning of the narrowed buffer? Why do you need a hook? When the mode is first enabled in the buffer, there will be no narrowing in effect yet, so the mode could do whatever it wants at that time. Of course, this won't help us to solve the issues discussed here, because scanning the entire buffer at any time is slow and non-scalable. > Also, as I'm not a big user of explicit narrowing, the only place I've noticed it happening is in info mode, where > the focus is narrowed to a particular syntactic unit. > Is there a way for a major mode to let the user signal the syntactic unit that they believe they are narrowing > to, either with command variants or an interrogative(with a list of options supplied by the mode) when > narrowing is performed by the user interactively? With the fall-back of either having the mode determine the > correct initial state or turning off fontification during the narrowing? We are not talking about user narrowing here.