From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: A read-based grep-like for symbols (el-search?) (was Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)) Date: Fri, 1 Oct 2021 14:15:35 +0100 Message-ID: References: <25d8d72022b571db5291@heytings.org> <87h7e2xsl5.fsf@gmail.com> <25d8d72022e1ea7ed022@heytings.org> <87fstl7lzw.fsf@web.de> <87a6jt7ilx.fsf@web.de> <87fstlzlaq.fsf@gmail.com> <20211001070242.GC16352@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11819"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 01 15:21:12 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 1mWITQ-0002pq-Lc for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Oct 2021 15:21:12 +0200 Original-Received: from localhost ([::1]:46232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWITP-0002Zb-IP for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Oct 2021 09:21:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWIOD-0005lI-FW for emacs-devel@gnu.org; Fri, 01 Oct 2021 09:15:50 -0400 Original-Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]:44589) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mWIOB-0002TI-17 for emacs-devel@gnu.org; Fri, 01 Oct 2021 09:15:49 -0400 Original-Received: by mail-pf1-x42c.google.com with SMTP id 145so7873611pfz.11 for ; Fri, 01 Oct 2021 06:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZkVlm/+ys9173YIG7TRQ1lPJO6BWDaeIy9dmio1W108=; b=DWuH3GezAmRMA+UJEGobSJgZAEHE4doxc8fdcU2JMviRkjzLSKCoo7mvjILtXE1ue3 F3526DvFA7zLF6Yo1u4SrwLPGhDBj0BtALDmV+gMam+yBNJg8mLtzV/28z0MUi+Cx92I jbE8YCmnaSKaciX9oTqwDNw6y5AkSsP/gSOtAlNEJpOpTt4Mm8O3S1NCgmB/6vtjT+FP k4ZxRmWNSIzaurInOezQh5MRpF3XJPheZi6Lgrpd1r/LweaqpGLh15H4oFUlvp2gXYdU +CGJbLHYAiSeoyzH+i2Kc/QCdUHUxi0bfoqU8RJffASO7I38UGivb1GPcli/9/k6G790 KhMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZkVlm/+ys9173YIG7TRQ1lPJO6BWDaeIy9dmio1W108=; b=E+zJX8j0SPssqdPnP1ELvkKROl/ROu/ty0iC6YwKGSeozgQ8meru9Jy2oS8n8gtIgN 6WRGVI9PNEhrm/svgdxlSHeIYifTYxCqA1ubjwhYxhUAUODGd3J4JqUd2eeDmOgK5AK1 3jLAqoLZNhyB2sP5u3shDJkB4Bo4PCP1LzvsaRbG6YYSTioJooHwNuBDV6XK+w4ZIljo UWwXBjXZvAbl1eFGrP6cFfaYwKaleZCpQbrFVPqYgLJKnFzjud4+5z29mdn8OWAqyVOV HStAOAXB+TpgiB1+eHkhvSGcUocP5i3nOIwTYFkhc/zTjCeEJ2O3w7RS7RKi8tM2H6eO zzkw== X-Gm-Message-State: AOAM5304rHWt9IOntR5hLf5mRQyX+5d/9ywZSohW1slesuXHuGKMbDrm ogIsjVk4Wvfxu69M5zsYj75zcCCC85IbB8boYTT3AaOTn/o= X-Google-Smtp-Source: ABdhPJx8c4OOk0Jvk3Xy/iMhDqxNiZ527vuc21wOl0WwkXE7/wOnQL44Q7DSuay0hH9nrlZMgwBxi2jGik17fbwipK0= X-Received: by 2002:a62:7f01:0:b0:43c:ecef:98dd with SMTP id a1-20020a627f01000000b0043cecef98ddmr10261372pfd.50.1633094144309; Fri, 01 Oct 2021 06:15:44 -0700 (PDT) In-Reply-To: <20211001070242.GC16352@tuxteam.de> Received-SPF: pass client-ip=2607:f8b0:4864:20::42c; envelope-from=joaotavora@gmail.com; helo=mail-pf1-x42c.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 autolearn=ham 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:275979 Archived-At: On Fri, Oct 1, 2021 at 8:03 AM wrote: > All those "magic action at a distance" things (and name prefix > goes in that direction, but many things you see in contemporary > Web frameworks do this too) make life harder for the "grep > crowd". Yes, of course. So-called higher-level languages are all about indirection. Pointers, function pointers, late binding, garbage collectors, duck typing, namespaces,,, they all give us something and they take something away. Every time. Grep is a tool, a tool to search text. It is only able to respond to questions about a program's source when that source is written in text files (which it normally is) and when the programming language is relatively poor on indirection. Or to put it another way: the usefulness of grep as a program-related question-answering machine is inversely proportional to the indirection mechanisms in the language in question and its expressive power (aka the power to say more with less). That doesn't mean that one can't devise tools to answer questions about programs in a way that makes _less_ assumptions about the multiple ways in which these program's sources are encoded. And the 'read' based tools that we're discussing in this thread are efforts in that direction. They will still be fallible, no doubt, but not in the ways grep is. And grep will still be useful. I'll only be slightly _less_ useful because a new language feature has increased the number of questions that can be asked about a source. But that is what indirections ALWAYS do. "What is this pointer pointing to?", "What version of this C lib am I linking against?", "What the heck is the GC doing", "Is this object that responds to .quack() really a duck?", etc etc. (Curiously, this is _exactly also_ the reason why these features are also culpable for performance degradations, something that we're much more trained into accepting, because we experience them less directly) Language design never has been held back by the particular assumptions of a search tool, popular and ubiquitous as it may be. And it's frankly a bit bonkers to even conceive that. When I can, I _do_ pu= t the C brace on the function definition line so that grep tells me if it's the definition or the declaration I'm looking at, but how crazy would it have been to force C not to have forward declarations BECAUSE it could hurt grep?? (as it quite obviously does!). That's why these "modern web frameworks" are causing you "grep pain". But programs today (and for a good number of years) and even more, the ever complex programs in the higher-level languages of the future will even cause you more pain! It's the job of development tools -- with the Editor at the center -- to help the programmer navigate these things. Hence M$ IntelliSense, hence SLIME, hence LSP, hence xref.el, etc, etc, etc. Emacs is in a very good place in this regard, to be honest. We have incredible talent and Elisp is a very good language, way waaayy better than JS, for example. > Now the question: does it also find things hidden away in comments? > This is one feature I wouldn't like to miss, as part of the "grep > crowd". The first iteration of the tool I'm thinking of answers questions like what is referenced by source code, today. It doesn't answer "what could someday be referenced when one uncomments lines". A symbol name stuck in a comment probably shouldn't be there, at least not in Shorthand form. And anyway Shorthands don't operate on comments, so the point may be moot. So the answer is that it can be done, but not in this first iteration. I will think about it, though. > Now I don't think this is in itself a reason to not do it. I've > missed some kind of name space mechanism in Emacs for ages. Of course! > But taking the grep crowd into consideration is a nice touch; you > might find yourself in that place some day, while wading through the > swamps of a foreign country :-) Yes. The things that said here are taken into consideration ;-) And yes I use grep. To "wade" into your delightful image, it's like using made-up sign language in a foreign country: it'll get you places, but you won't be reading the classics or chatting up the bear that wants to eat you. Jo=C3=A3o