From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Abbrev suggestions - feedback appreciated Date: Mon, 11 May 2020 18:58:23 -0400 Message-ID: References: <871smeoalc.fsf@gnu.org> <87fuatmw71.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="83222"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Mathias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 12 00:59:26 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 1jYHOQ-000LY8-4c for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 00:59:26 +0200 Original-Received: from localhost ([::1]:56918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYHOP-00049S-7R for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 18:59:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53786) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYHNW-0003g9-Rs for emacs-devel@gnu.org; Mon, 11 May 2020 18:58:30 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10335) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYHNU-0001Ej-Gp for emacs-devel@gnu.org; Mon, 11 May 2020 18:58:29 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 28F9C450C08; Mon, 11 May 2020 18:58:27 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 65F06450C05; Mon, 11 May 2020 18:58:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1589237905; bh=gdg/g5+RHBGtKLgpJKOP5+tSxmbPgjjGDuggvbfdEcM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GojDnUzoxT8Y86OAZHE3Vtiw1cDxrRO0QShvPiDlP3G4fL2RunowROMXoS4cbxLSU 3jwcYVjGHAS97DnaZ04WBPIHyRAeBHs0d2rhFhQlqbvfG2AP+UskuTa0/84P79msVD EuZtBG+gvqfSP08IMW5YFmxHkhuqKAHz/XJa8On6ydpfk87pZ6L4eMiuDYBYSKHUtq RY4e57AgbWvITJUcQlXCyGQvWhqhfw+9a7f9I7WgglIXMN2jCTZmmKCGbJ08UQzYpZ RJHF2ZmZ801pmw8qjrTuD750VPSSLyixnlHWWMD19TZMAgnM5lfrmBEVDhc0PQl+Ib 21nZ8bMt6x3KQ== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 170C6120804; Mon, 11 May 2020 18:58:25 -0400 (EDT) In-Reply-To: (Mathias Dahl's message of "Mon, 11 May 2020 23:37:26 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/11 10:58:52 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:249902 Archived-At: >> [ Note: your patch seems to have its TABs converted into SPCs, messing >> up indentation. I tried to fix those when quoting your code, but >> I may have mishandled some parts. ] > I'll have a look at that at my next attempt. Are you saying there should be > TABs in Emacs' .el files? No: neither that it should nor that it shouldn't. Just that indentation was weird and the reason was probably that some TABs were mishandled by the mail transport. > Looking at the other defcustoms in the same file, probably not. I guess I > added that when I first wrote absug.el, thinking it was a convenience > thing. To be honest I think abbrevs are a convenience thing, I think we all agree: the `abbrev-mode` group is inside the `abbrev` group which is inside the `convenience` group ;-) Maybe this could be restructured to make it less deep, but I'm not the right person to talk to for that. >> What would be the disadvantages/risks of enabling it by default? > Of the top of my head, some people might be annoyed by the constant > "nagging" about using abbrevs. Could be, but I suspect those people who'd be annoyed don't have any abbrevs to start with, so abbrev suggestions won't annoy them ;-) > They could of course turn it off, if we enable it by default. Yes, I'm tempted to enable it by default. But indeed it's important that it can be disabled easily (and maybe we'll end up disabling by default). > The first does not have a group set and the second has convenience as group > as well. I have never thought about if this is a normal or not. Is it? I think the `:group` args there should be removed, indeed. > That is mentioned in other places too, that it should return what was > inserted, if any. It did not feel right to mess with that, but perhaps it > is okay... Here is an attempt: > > (defun expand-abbrev () > "Expand the abbrev before point, if there is an abbrev there. > Effective when explicitly called even when `abbrev-mode' is nil. > Before doing anything else, runs `pre-abbrev-expand-hook'. > Calls the value of `abbrev-expand-function' with no argument to do > the work, and returns whatever it does. (That return value should > be the abbrev symbol if expansion occurred, else nil.)" > (interactive) > (run-hooks 'pre-abbrev-expand-hook) > (or (funcall abbrev-expand-function) > (abbrev-suggest-maybe-suggest))) > > Is something like that what you had in mind? That seems good, yes. Tho please make sure `abbrev-suggest-maybe-suggest` returns nil, or use (or (funcall abbrev-expand-function) (progn (abbrev-suggest-maybe-suggest) nil)) >> I think you'd be better served defining a dolist-style macro or >> a mapc-style function to loop over all abbrevs without creating an >> intermediate list. > Sorry, I don't understand what you are suggesting, and why (performance, or > saving memory?). The idea is to avoid the memory allocation, yes. It should improve performance and reduce the frequency of GC pauses. >> > +(defun abbrev--suggest-count-words (expansion) >> Why does your code pay attention to words? > I'll think about that... Are you thinking that only characters matter? No, it's just that currently Abbrevs don't treat words specially, and some uses of abbrevs can expand to things that aren't just made of words. > I think my focus is primarily using abbrevs for sentences. Right, but abbrevs are also used in programming languages and other "non-prose" contexts. So, it's better if we can make it work without assuming "words". > I'll try to cook a new version now. Looking forward to it, Stefan