From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: [External] : forward-sexp Date: Sun, 20 Aug 2023 05:50:36 +0200 Message-ID: <87lee6bcdv.fsf@dataswamp.org> References: <53741ea9-b3ac-67a6-519f-b8977df30bf9@easy-emacs.de> <0a70992a-8daf-b14b-09a4-d4b89ef29639@easy-emacs.de> <87350pibf2.fsf@dataswamp.org> <87msyvkihg.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11127"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:mbPkOcbiRw08QHMmVZxRuL0j44c= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 22 14:14:18 2023 Return-path: Envelope-to: geh-help-gnu-emacs@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 1qYQH3-0002dq-K9 for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 22 Aug 2023 14:14:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYQGy-0004G4-5T; Tue, 22 Aug 2023 08:14:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXZSi-0008TG-KM for help-gnu-emacs@gnu.org; Sat, 19 Aug 2023 23:50:48 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXZSf-0001zu-VD for help-gnu-emacs@gnu.org; Sat, 19 Aug 2023 23:50:48 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qXZSd-0000qz-Jc for help-gnu-emacs@gnu.org; Sun, 20 Aug 2023 05:50:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 22 Aug 2023 08:14:10 -0400 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:144903 Archived-At: Pierre Rouleau wrote: >> No, that would be the way to do it, if there is no notion >> of symbolic expressions, one would fall back to some other >> behavior, preferably something not to far away from both >> the name of the function or the usual way it is used in >> practice, i.e. what would be thought to be expected to >> reflect that in the supposed sexp-less setting ... >> >> So either one would have a small set of functions that >> would work everywhere, but differently depending on the >> context, _or_ one would have a huge, always growing set of >> functions and every one of those would work in one and only >> one context ... >> > > Would it not help to have a selectable behaviour: - by > default the end of a balanced expression expects inner > expressions to also be balanced (ignoring nested comments) - > another mode would try to match the starting character to > the matching end character, ignoring comments and > unbalanced/partial expressions made of other characters. For programming one could absolutely think of such an idea, a default behavior. Because there is so much that are based on the parenthesis, brackets and such delimiters. And it would be harmless to since if the local modes didn't like it, they could overwrite the functions with local ones. And it would be even cooler if the local variation would be a local variation of the sexp, local to that mode, and then the navigation would not have to be reset, just the local sexp! Maybe difficult to do so overwriting the navigation would still be allowed ;) -- underground experts united https://dataswamp.org/~incal