From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: non word abbrevs Date: Mon, 08 Nov 2021 18:29:00 -0500 Message-ID: References: <2F7AC7B8-48AA-4BF3-B5AA-A4141F248109@traduction-libre.org> <4097001A-F60D-4712-B828-EA778BFCF56E@traduction-libre.org> <2067AA83-8EC0-4429-9189-9E3CCCFD06BB@traduction-libre.org> <976C9A57-FA22-4E47-AF16-C1B20C66E451@traduction-libre.org> <87v913nr8y.fsf@laposte.net> <2297BB1A-8F37-4624-8156-CDA4F48BEC7B@traduction-libre.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30346"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:KagwPjQpQjqWRjppvUM1ev8++Ck= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 09 00:29:39 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1mkE55-0007bW-Ma for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 09 Nov 2021 00:29:39 +0100 Original-Received: from localhost ([::1]:55800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mkE54-0000M9-CU for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 08 Nov 2021 18:29:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39734) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkE4c-0000Lt-UV for help-gnu-emacs@gnu.org; Mon, 08 Nov 2021 18:29:10 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:47938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkE4b-0002Ol-Eg for help-gnu-emacs@gnu.org; Mon, 08 Nov 2021 18:29:10 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mkE4X-0006xo-KV for help-gnu-emacs@gnu.org; Tue, 09 Nov 2021 00:29:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:134459 Archived-At: > Thank you. I am really just interested in having "proper" text expansions > like what I have on the OS side. I fail to see the logic of limiting abbrevs > to "word characters". Maybe part of the motivation was the performance cost of checking abbrevs after every key stroke, but I suspect the main issue is avoiding "false positives": Say you hit in sequence the three keys `< = >` and you have abbrev rules for `<=` and for `<=>`, you'd probably not want the first abbrev rule to apply after you hit `< =` because you'd prefer for Emacs to wait a bit more and apply the second abbrev rule. For words, this notion of boundary is fairly standard. But for other chars, it's not so clear. So to lift this restriction we need something more. Stefan