From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.devel Subject: Re: epa command names Date: Sat, 12 Nov 2011 09:07:01 +0100 Message-ID: <87ty693gt6.fsf@gmail.com> References: <87vcqpzw2w.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1321085238 28673 80.91.229.12 (12 Nov 2011 08:07:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Nov 2011 08:07:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 12 09:07:15 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RP8cM-0000PV-Ie for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2011 09:07:14 +0100 Original-Received: from localhost ([::1]:40909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RP8cK-0008Pv-Ps for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2011 03:07:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:50778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RP8cI-0008Pq-6Q for emacs-devel@gnu.org; Sat, 12 Nov 2011 03:07:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RP8cG-0008VB-SH for emacs-devel@gnu.org; Sat, 12 Nov 2011 03:07:10 -0500 Original-Received: from mail-bw0-f41.google.com ([209.85.214.41]:52856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RP8cG-0008V7-Jt for emacs-devel@gnu.org; Sat, 12 Nov 2011 03:07:08 -0500 Original-Received: by bke17 with SMTP id 17so3416574bke.0 for ; Sat, 12 Nov 2011 00:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=tPP8yJSP0W2UfdWJUVxf5zop2vieGexhl/A0Zt4fXI8=; b=u+daqAzSIkwVzehatOyrqNlIdU6JbFPDiS1Aeo/klrqlJuTdyf/eBKiMH1w4J5uw2u sMRFzPKNEITEAUHxaz5gksEn87gPz5EjhGmmHiviS+QUtKkpzGE6Gkbgy+JE6Iy72NhS HSXDZ5AL2ZoUHz8o2T7NrIzHwwTIn+v2ecVg4= Original-Received: by 10.204.148.75 with SMTP id o11mr11379970bkv.95.1321085227546; Sat, 12 Nov 2011 00:07:07 -0800 (PST) Original-Received: from thierry-MM061 (56.78.88.79.rev.sfr.net. [79.88.78.56]) by mx.google.com with ESMTPS id dq2sm15731329bkb.11.2011.11.12.00.07.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 00:07:04 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sat, 12 Nov 2011 02:22:12 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146001 Archived-At: Stefan Monnier writes: >>>> I have switched to using epa instead of mailcrypt. The only drawback >>>> I see is that the command names are not natural; thus, remembering >>>> them is extra work. >>>> Shall we give them aliases without `epa-'? For instance, define >>>> `mail-encrypt' or `encrypt-mail' as an alias for `epa-mail-encrypt'? >>> I don't much like this option because of the inability to handle >>> conflicts. I'd much rather make M-x a bit more permissive such that M-x >>> mail-encrypt falls back to epa-mail-encrypt (probably via completion). >>> >>> One way is something along the lines of the `substring' completion-style >>> (which we could restrict to substrings that start after a word boundary), >>> but I think we'd want something less general. >>> >>> I'm thinking of a way for packages to say "if `mail-encrypt' is matched >>> by the user's input, then include `epa-mail-encrypt' in the list of >>> completion candidates". This would handle conflicts very >>> straightforwardly since if we have a second rule "if `mail-encrypt' is >>> matched by the user's input, then include `superduper-mail-encrypt' in >>> the list of completion candidates" M-x mail-encrypt TAB would simply >>> provide both options as valid completion candidates. > >> anything does that actually. > > IIUC the "that" which it does is the "substrings that start after a word > boundary" matching, but not the other one (which requires extra manually > provided information, AFAICT). Right? It loop in command list and does (string-match pattern "command_name"). This allow to do: M-x encrypt which will match all commands _containing_ "encrypt" but also: M-x ^encrypt which will match all commands _starting_ by "encrypt" And also, if you say: M-x encrypt mail or M-x mail encrypt Both will match "epa-mail-encrypt" i.e (string-match "mail or encrypt" "command_name") -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997