From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Mon, 26 Jul 2021 23:46:10 +0200 Message-ID: <87tukgg34t.fsf@telefonica.net> References: <83h7gw6pyj.fsf@gnu.org> <533BD53B-4E85-4E9E-B46A-346A5BBAD0F5@gmail.com> <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <8335s64v10.fsf@gnu.org> <5380C92B-6C15-4490-A1E0-1C3132DBB16A@gmail.com> <83k0li2shw.fsf@gnu.org> <86wnpg82v3.fsf@stephe-leake.org> <83lf5wyn0z.fsf@gnu.org> <86pmv66yqg.fsf@stephe-leake.org> <83a6maw705.fsf@gnu.org> <83r1fluikh.fsf@gnu.org> <83mtq8vqmn.fsf@gnu.org> <87y29sg7rt.fsf@telefonica.net> <2a75e32a-796e-837d-7215-aceead84fb52@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14246"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:KwYOm+z4WbssnavN742s88Sg1H0= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 26 23:46:56 2021 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 1m88R5-0003XP-MT for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 23:46:55 +0200 Original-Received: from localhost ([::1]:41790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m88R4-0001d4-OS for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 17:46:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38642) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m88QW-0000yW-0C for emacs-devel@gnu.org; Mon, 26 Jul 2021 17:46:20 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:34432) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m88QU-0005Eh-3m for emacs-devel@gnu.org; Mon, 26 Jul 2021 17:46:19 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1m88QS-0002ns-IY for emacs-devel@gnu.org; Mon, 26 Jul 2021 23:46:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:271674 Archived-At: Clément Pit-Claudel writes: > On 7/26/21 4:05 PM, Óscar Fuentes wrote: >> Think of an Org file with some code blocks. It makes no sense to >> expose the whole Org file to TS and, I guess, it would just >> complicate things for no benefit. On that scenario, it might make >> sense to deal with the code blocks as independent entities instead of >> parts of something else. > > Isn't this example actually in favor of *not* narrowing before giving > the buffer to TS? Consecutive org code blocks often build upon each > other, so you'd want to give the whole buffer to TS and restrict its > analysis to just the code blocks (multiple disjoint ranges), a results > that you couldn't achieve with narrowing. I don't know from where you got your "often" :-) Of course it is a possibility, but I've seen plenty of Org files containing loosely related code snippets (and those who build on each other tend to be written on dynamic languages, which benefit a lot less from static code analysis.) As far as my personal experience goes, I very much prefer that each block is treated indepently, because my Org files contain code recipes for specialized tasks, bug reproducers, multiple variations of experiments, etc. They are not related at all. So it is desirable to support both modes well.