From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Mon, 8 Aug 2022 10:24:38 -0400 Message-ID: References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> <834jynvtwi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6636"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 16:27:25 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 1oL3j2-0001Wr-Is for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 16:27:24 +0200 Original-Received: from localhost ([::1]:38936 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL3j1-0001hn-Lg for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 10:27:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL3gd-0007Km-UZ for emacs-devel@gnu.org; Mon, 08 Aug 2022 10:24:55 -0400 Original-Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]:34334) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oL3gc-0008NY-1C; Mon, 08 Aug 2022 10:24:55 -0400 Original-Received: by mail-pg1-x531.google.com with SMTP id 12so8728408pga.1; Mon, 08 Aug 2022 07:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=RRuu6b9UXlAYi0UZ0BIHzJzRUveLr0CPv6qtM+P1NW0=; b=U33VYmwUc3hBlmGfw+enlJnAAqhkFtbP/32thz/a/gl7Rj8z91eSOxWaKdhGWcZTQF +FBwsfmZZivEyLzZx97drvTqFPQCA5Spo3L8+KajmnXpjb5dMJxQkbxsG82y771YSUoX K+v7g42yA3VBk89fRW+HgMm7doSYGKbwrVwKmErpDH7iK9wiNNIqraC2FpZlXUSN+6Bp nJ7wVBp4ApmsIv8VVO26R84nJ6ICxt/syApP+yNVklSraekq7nlD7KMl2tlQkS41MNjf RXLbMFTkvGjI0x4JxTIIimZRAGtW5FWswBIIU6iBM/iE76qJqA7UQhWtQH9SCYjYqrTb DLRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=RRuu6b9UXlAYi0UZ0BIHzJzRUveLr0CPv6qtM+P1NW0=; b=csAWUq2r1Nb49tSyijnWRp2cRTg/f3YCjHUFOrd1TmLvdD0KUy5GuCTuqEYWMzBu37 RX/0JdB2R5QH0ufNkYkvcmQZ9rrqHP5i7hTiry/CQGV7kDfr1AQBxoOTf+EhCvRPO472 8qg0AHRmsIuScvo9a/QM3OyzEbbLt/9kmWJsYbM0OhnEWbq4jEq0/1hqshKCDYw+tyIU XA5uSQAm/UK2Nm5gDRXppYolayETApLhe+mxX7CAXg9Dljis1TSDGU5cKTKWIAtwuqYS D9bNYrvJSo0S9WgTmvKPgvUOJHK3Z0k6ErSmOub6HW9XDuX6JKwJM0uPJa00RYYSwdoz VuqA== X-Gm-Message-State: ACgBeo1jGNXSHrToNGA3QlYiuAkSFJbhnSaf9vlMLX27BTNhZXyvNfsN +pAGObzZJPOSkt8TKkHnSHIQQNVhls6uiEinHp0MnH7Y X-Google-Smtp-Source: AA6agR7hUtZBMeJ2edLDeDAT7xdUp4BT30An6r6G3CRI2e0CrOQvsCE7Dw/XyRjVOPH/1Dxmo5NX+ybf7kRbv5kSHUc= X-Received: by 2002:aa7:8f0a:0:b0:52d:8135:64e0 with SMTP id x10-20020aa78f0a000000b0052d813564e0mr18921691pfr.0.1659968691755; Mon, 08 Aug 2022 07:24:51 -0700 (PDT) In-Reply-To: <834jynvtwi.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::531; envelope-from=owinebar@gmail.com; helo=mail-pg1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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:293267 Archived-At: On Mon, Aug 8, 2022 at 7:48 AM Eli Zaretskii wrote: > > > 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. > I think you answered your own question - the code (I believe we're discussing jit-lock on arbitrarily long lines in the particular) doing the narrowing would have to identify the starting and ending points via some special variable prior to running the hook, so the thunks would be able to determine the right state *before* narrowing is actually done. > > 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. Maybe not explicit user narrowing, but I don't think we're discussing a piece of code that is just randomly jumping around a buffer, narrowing and then requiring fontification without user interaction. So, one way of handling it would be to have the code doing the narrowing take the place of the user in the above scenario in some programmatic way, perhaps using some prespecified (by the mode) regular expressions to make a best guess at what the user response would be based solely on local conditions. A mode that doesn't specify a way to make a selection could be defaulted to turn off fontifcation while narrowing. An approach that doesn't require cooperation from the mode would be to * open a new buffer in the same mode * insert the characters from the narrowed region linearly in electric mode (or something that would create newlines in "appropriate" places for the user's preferred style), * indent and fontify that buffer in some way so the indentation of the first line is consistent with the indentation of the last line (e.g. if the narrowed region is a series of '}' in CC mode, the first "}" should be indented to reflect the level implied by the number of "}"s therein - if necessary by inserting leading matching delimiters in the reverse order) * copy the fontification back to the region in the original buffer Or to do something equivalent to that without actually opening the additional buffer. This method would have the advantage of being entirely local. Of course, as a user, I would like to have a command that lets me take a point that I *know* the correct syntactic classification of, and specify that from a menu, then have the mode fontify with the constraint that my assertion is held constant, at least until there is a modification at the point I made the assertion. Lynn