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: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Date: Mon, 04 Oct 2021 18:43:08 +0100 Message-ID: <87ilycwus3.fsf@gmail.com> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <831r59kyhf.fsf@gnu.org> <834ka4k15m.fsf@gnu.org> <83y27gijmz.fsf@gnu.org> <8335pmgnjy.fsf@gnu.org> <604da2cb10ac61f2b8b89a02c89056be@webmail.orcon.net.nz> <83a6jtff87.fsf@gnu.org> <5ac7a31cf2959c31c262a3377c736a5a@webmail.orcon.net.nz> <83ilygew7p.fsf@gnu.org> <83fstjdiwl.fsf@gnu.org> <871r534s2o.fsf@gmail.com> <87sfxgx09x.fsf@gmail.com> <83lf3868d5.fsf@gnu.org> 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="17729"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: psainty@orcon.net.nz, acm@muc.de, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 04 19:44:21 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 1mXS0i-0004OQ-8q for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 19:44:20 +0200 Original-Received: from localhost ([::1]:43256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXS0g-0003DC-M7 for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 13:44:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXRzc-000291-5x for emacs-devel@gnu.org; Mon, 04 Oct 2021 13:43:12 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:39843) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mXRza-0001Kf-C9; Mon, 04 Oct 2021 13:43:11 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id r18so4868444wrg.6; Mon, 04 Oct 2021 10:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=72wMViY5OanIesAf8as44UZZuDgoSzhPm19TFqHY308=; b=hXlc11xFoffSoaoHlrTzUJeDS1aIoq1TCgejyJiEI4mntSBn4XH3Qy4Rt/DntSOwmO QB0bNX5B8/cmt3IdF0drkCSR9wE+4fonMUraTJPm4YUcAk2Zri790Er54+FhtIGAalDG QMEklqx4tIyvYj1l5141AetavGGPm+PnKrYQMZvDH1UfegtyNMkjuDio1nhnBNYuWf+c oFkbmyhfrOZwnSTTJgrZYp7M9xN/L0tZOOarX8eMX+1RJ38n1m/HkSndCt1/hC3TSikE ZeO6oVVqV5cBPCBPNFfThh/0RPPaakJKIZ5865F651VC2GC28K6Zhln8tfxa1N68gsAr 9DWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=72wMViY5OanIesAf8as44UZZuDgoSzhPm19TFqHY308=; b=FQoOQEpcg61B9gQH6AMUYgCM6T5zGZaIuuJnpMCQiZk4DFxthevDTSC9F4dOh04Pup 4jovo66QeSw7UFD/O1aqVDmHPYgSCCgvBLP8Skt5bqZXOTy0c1QUYJkYx5y+gtutd20g B5wAuZBagN0Lu1qLLPSea1VUPWa8xwohf2vWo9cH/Xe8DTaNld+Ycl0Qq3O3NAvSC23B Esn71LOtZEV82dBOTlQWGB5rlQSiUvU+0EyZ/5MXnUcVqv9WXPPalGyp7VPYuSvloBqs 9mbL4gQSH3kDmqJF1Ol3rJA3l+jq4oZgV457sxXtfgy4Q1ogoJXD+zcklgYAV+5Hd1EO H5nQ== X-Gm-Message-State: AOAM531t3KpU6QL2MpImt4jS3w9m1BXB40Ip8WAW3Uh/5SKsSyyLIqjQ fZ9dkOA9OeOW1Bo8s4tiXFcFb/FWl60= X-Google-Smtp-Source: ABdhPJyRsSABxFOTweRAwXx0zB7MkJFxj2NApDDFVnxXAzytTp+13K9TKhI182CkZtf6WR7Rg5RJ2A== X-Received: by 2002:adf:a51e:: with SMTP id i30mr15430635wrb.206.1633369387679; Mon, 04 Oct 2021 10:43:07 -0700 (PDT) Original-Received: from krug ([87.196.156.235]) by smtp.gmail.com with ESMTPSA id z17sm14978678wml.24.2021.10.04.10.43.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 10:43:06 -0700 (PDT) In-Reply-To: <83lf3868d5.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Oct 2021 19:51:50 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42a.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:276237 Archived-At: Eli Zaretskii writes: >> The system is behaving as designed. > Famous last words ;-) :-) > Seriously, though: IME, this is not a popular response to user > requests. I understand, I really do. But it's true: the system is behaving as designed. That surely doesn't mean one can't design it differently, or augment it in the direction of those user requests. It _is_ possible (I hope I left that clear). I just don't think it is a good idea, for the reasons I tried to explain. My intuition is that people that are making this request aren't imagining how it would behave if you had two files in your Emacs session (or even across different sessions). read-symbol-shorthands: (("s-" . "magnar-string-")) And another had: read-symbol-shorthands: (("s-" . "joes-system-")) It is my belief that this would bring some level of confusion. The user would have to consider very well the locus of her 'C-h o' request. I don't usually do that, not for functions at least (for variables, yes, to a certain extent). >> In the sequence C-h o s-foo, the last 5 characters typed are not the >> name of a symbol, they are the name of a shorthand (a shorthand is _not_ >> a symbol) that you are seeing (in the sense of "with your eyes"") in >> some buffer. > > If it is impossible, or hard, or inappropriate (in your opinion) to > support s-foo in this use case, would it be possible to have a special > command that would expand the shorthand in the minibuffer? That is, > the user types "C-h o s-foo " and that replaces > s-foo with the expansion, the "real" symbol. Is that feasible? When using some "completion styles" (which see), the completion system already does that, to a large extent. The 'flex' completion style, for example, would do that: it is quite likely that 's-foo' would expand to 'magnar-string-foo'. Note, however, that that expansion is based on the simple string relation between 's-foo' and 'magnar-string-foo', where the former is a subsequence of the latter. If the shorthand were: read-symbol-shorthands: (("x-" . "magnar-string-")) then, 'x-foo' would _not_ expand to 'magnars-string-foo' using the 'flex' completion style. If you nevertheless wish that 'x-foo' expand to 'magnars-string-foo' BECAUSE you invoked 'C-h o' from a buffer where those shorthands are setup, then you are again creating some locality in the 'C-h o' interface. But I presume you are prepared to accept that. So, it _is_ possible to code that. Perhaps using a buffer-local completion-style. At first sight, this new idea of yours is more elegant than the first request, because it expresses the true vehicular nature of shorthands much more accurately. It also seems simpler to implement, at first sight. With heavy emphasis on the two "at first sight"s ;-). >> * So, if we follow our first instincts (they were my first instincts, >> too!), it means that the exact same Help input in two different >> situations could bring about different results. > > That already happens in any number of situations, and shouldn't > prevent us from adding one more. The most trivial example is > buffer-local variables; another example is mode-specific commands (a > recent addition in Emacs 28).=20=20 Interesting, I wasn't aware of mode-specific commands. Can you give one example of one or two commands specific to a mode? Does it mean that the listing itself, i.e. the collection of completions of given by 'C-h x' is different according to the buffer? > And there are many more: a user who expects identical Emacs behaviors > in different buffers will be extremely disappointed. In what regards _listing_ of symbols brought about by C-h o, C-h f and C-h x, etc, I will be one of these "disappointed" users. I'm OK with seeing the final product of my C-h v request say that 'foo' 's value is 42 in the buffer 'bar.el', because it's so very clearly spelled out there. But I'd find it odd not to see a variable, function or anything listed there at all. Anyway "disappointed", doesn't mean "extremely disappointed" because being a catastrophist about such things isn't really my thing. If this is the direction where you and others envision Emacs going, I'm on board! Jo=C3=A3o