From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Tue, 5 May 2020 13:57:58 +0200 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="47292"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Emacs developers , Stefan Monnier , =?UTF-8?B?7KGw7ISx67mI?= , Dmitry Gutov , Eli Zaretskii , Drew Adams To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 13:58:59 2020 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 1jVwDz-000C9t-72 for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 13:58:59 +0200 Original-Received: from localhost ([::1]:37026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVwDy-0008DE-9S for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 07:58:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVwDU-0007nG-GG for emacs-devel@gnu.org; Tue, 05 May 2020 07:58:28 -0400 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:46564) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVwDT-0005Kg-Le; Tue, 05 May 2020 07:58:28 -0400 Original-Received: by mail-lj1-x231.google.com with SMTP id f18so1277400lja.13; Tue, 05 May 2020 04:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=osEDEwQgOV+OMzzcUa7xbs6tt48DRWeLGq2rOptsHho=; b=TgSNZ6GAIPeEzcHrygD/otuyoN2uouOvZunPUDb0cTxd/EL2Ew+p5epJsRLUPulGbQ gXLXWb4A9oYg4ZRIL5QyTkMNdQcS6kOoy75RminCkAhkI0XvhPyxR21GlMoeOke2uIg8 eP0l/yySWGKWqz5Bd4gYBM8e633h/XJdCswcMwAeXlYE2xkn8qG83KZykEBqWtQfUSv0 EsWk1cYpqJWEwM2G3rloGJJTCLtCfDFkChZcpd/rjN/GA+s3l/TbGIWCjM5uVTfje9SN pGyBI/qN3gy7dFlXejNSXtY+2cFvt5gd8WrbeeL5GT6KEfjUg5pBlozUJQCuKxQqUBss V6HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=osEDEwQgOV+OMzzcUa7xbs6tt48DRWeLGq2rOptsHho=; b=unpyrQThHR3uBXX7O/SnaN+l88+QCsgEuqLKSNZDvfO2X0BAAT9ontDgiCMnzuuRD5 ioMItiVEUqe5yS21xmWFZIm+tWPpxqN5runnYuH2Zg7Jr5TH5iI6IKjNBQRLd1wHEPiK lHOi8Z0nwyqXKn+nodQgYfp++7dAWOue4tN6O09O9f5HK+2cMmCFwqVfX3xZfUhy1xuk pPIC3qv9wV9MBnqHNNdOafHkVL01X/ym6hPQn7+Hk1kmADvgZdc97shBKHC+CRNYqgg9 SPqEsSUl9H4/QRR0O0/Cy3ev0I2MqHIhjUvR/3+A+TuAnNFaIAD8zWWi/oOscuCf/hGh 1r7Q== X-Gm-Message-State: AGi0PuZQO9IjuhNQwWRXdcnYYR6DFPV9/wbrYsYrgyWAOCVZP1jl1B0T H2ZqYcZlMnS9O0cDVILhvhskvOlA9/+HIrt8ghE= X-Google-Smtp-Source: APiQypJE7asae3n2u+X3BFvIijrfIZ1eX4bjRQUQ0u5QlPyrKXiP+vQG69ZEVlBf1Mnshzon85ocucLxKbtXdOxsNYQ= X-Received: by 2002:a2e:7e04:: with SMTP id z4mr1692049ljc.50.1588679905104; Tue, 05 May 2020 04:58:25 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::231; envelope-from=philippe.vaucher@gmail.com; helo=mail-lj1-x231.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:248971 Archived-At: > > You understand that substring completion fails as soon as the term is > > too generic? e.g "string", "regexp" or "list", the list is just a lot > > of noise. > > Have you actually tried Drew's suggestion? Starts an Emacs -Q and (setq > completion-styles '(flex)), or just M-x fido-mode. Then C-h f for > "string". You get a _little_ noise but it's not "a lot", by far. And > the little noise you _do_ get from internal functions in other packages > is pretty easy to remove if you boost things by their mentions in the > manual. In fact there's a patch at the end of this message. I must admit I'm a bit of an extremist here, because even when trying this the little noise annoys me. Also the noise is bigger with "regexp". But I understand this solution seems good enough from your perspective. > > Also it doesn't quite work when the order is "reversed", e.g> C-h f > > "string TAB multibyte" would not return the desired function > > because it has to be "multibyte TAB string". > > But that's never going to work either way, unless you alias all the > multi-word symbols to all their possible permutations. You'll always > get a group of people that really expected it to be multibyte-string and > group of people that expect string-multibyte. I think "all in string-" or "all in string- or multibyte-" would work for me. Sure, the first time you try to find "multibyte" in in "string-" you fail but you rapidly know that from now only multibyte starts with multibyte. For example your list I'd do: multibyte-string-p -> multibyte-string-p string-to-multibyte -> multibyte-from-string string-as-multibyte -> multibyte-from-string-unsafe set-buffer-multibyte -> buffer-set-multibyte multibyte-char-to-unibyte -> multibyte-char-to-unibyte > To be clear. I'm not presenting these examples to be antagonistic. I'm > kind of sympathetic to your laziness to read the manuals, I'm lazy > myself, a reasonably good trait in programmers. So I really do use > these tools (and work on them) to get around an imperfect world instead > of demanding that the world adjust to my rigid way of thinking. I agree you have a point. But even without renaming as much as I suggest, I think renaming the functions that does not follow the "standard" of Emacs Lisp should be done (once it is defined). It's much easier for the brain to think in terms of patterns, even if they are not as straight forward as namespaces they should at least be consistent. > That said, it is possible to devise a completion style that will take > two words and match them against candidates in different ways, maybe > even matching them against other properties besides their names. I > haven't found it really useful, yet. But it's not absurd to think about > that and writing a smart completion style for Emacs is a much better > (and more interesting) contribution to it than the renaming > sledgehammer. Yes, personally I'd be more enclined toward the proposal of grouping functions according to https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html, this should be fairly easy to implement.