* epa command names
@ 2011-11-11 18:05 Richard Stallman
2011-11-11 18:26 ` name prefixes [was: epa command names] Drew Adams
2011-11-11 22:07 ` epa command names Stefan Monnier
0 siblings, 2 replies; 18+ messages in thread
From: Richard Stallman @ 2011-11-11 18:05 UTC (permalink / raw
To: emacs-devel
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'?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 18+ messages in thread
* name prefixes [was: epa command names]
2011-11-11 18:05 epa command names Richard Stallman
@ 2011-11-11 18:26 ` Drew Adams
2011-11-12 0:30 ` Richard Stallman
2011-11-11 22:07 ` epa command names Stefan Monnier
1 sibling, 1 reply; 18+ messages in thread
From: Drew Adams @ 2011-11-11 18:26 UTC (permalink / raw
To: rms, emacs-devel
> 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'?
Alas, this is a bane of 3rd-party Elisp code. That vanilla Emacs might suffer
now and then from a convention it promulgates is, well, just desserts. ;-)
Instead of allowing Emacs to flout its own guidelines, we should put in place a
real module/package/namespace system - e.g., using qualified names, where
qualifiers are separate from the names they qualify (so they can be changed
later).
Common Lisp offers one (good) approach.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-11 18:05 epa command names Richard Stallman
2011-11-11 18:26 ` name prefixes [was: epa command names] Drew Adams
@ 2011-11-11 22:07 ` Stefan Monnier
2011-11-11 22:28 ` Drew Adams
` (2 more replies)
1 sibling, 3 replies; 18+ messages in thread
From: Stefan Monnier @ 2011-11-11 22:07 UTC (permalink / raw
To: rms; +Cc: emacs-devel
> 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.
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: epa command names
2011-11-11 22:07 ` epa command names Stefan Monnier
@ 2011-11-11 22:28 ` Drew Adams
2011-11-12 2:34 ` Jason Rumney
2011-11-12 6:36 ` Thierry Volpiatto
2 siblings, 0 replies; 18+ messages in thread
From: Drew Adams @ 2011-11-11 22:28 UTC (permalink / raw
To: 'Stefan Monnier', rms; +Cc: emacs-devel
> 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.
You had one problem. And now you have two...
(No, I will say no more. Just going on record.)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: name prefixes [was: epa command names]
2011-11-11 18:26 ` name prefixes [was: epa command names] Drew Adams
@ 2011-11-12 0:30 ` Richard Stallman
2011-11-12 3:52 ` Stephen J. Turnbull
2011-11-12 8:55 ` Andreas Röhler
0 siblings, 2 replies; 18+ messages in thread
From: Richard Stallman @ 2011-11-12 0:30 UTC (permalink / raw
To: Drew Adams; +Cc: emacs-devel
> Shall we give them aliases without `epa-'? For instance, define
> `mail-encrypt' or `encrypt-mail' as an alias for `epa-mail-encrypt'?
Alas, this is a bane of 3rd-party Elisp code. That vanilla Emacs might suffer
now and then from a convention it promulgates is, well, just desserts. ;-)
Not at all. The convention is necessary, and we make exceptions when
that suits us.
Instead of allowing Emacs to flout its own guidelines,
My proposal doesn't violate any Emacs guidelines.
we should put in place a
real module/package/namespace system - e.g., using qualified names, where
qualifiers are separate from the names they qualify (so they can be changed
later).
In my experience, Common Lisp's package name system had problems and
no real advantages. But you can propose it if you wish.
However, that's a different issue from my simple proposal to
unconditionally define 5 or 10 aliases.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-11 22:07 ` epa command names Stefan Monnier
2011-11-11 22:28 ` Drew Adams
@ 2011-11-12 2:34 ` Jason Rumney
2011-11-12 3:00 ` Stefan Monnier
2011-11-12 6:36 ` Thierry Volpiatto
2 siblings, 1 reply; 18+ messages in thread
From: Jason Rumney @ 2011-11-12 2:34 UTC (permalink / raw
To: Stefan Monnier; +Cc: rms, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 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.
Something like Android Intents perhaps? Not only accessible via
completion, but any elisp package that wants encryption should be able
to say "encrypt-region" and hook into whatever suitable encryption
providers the user has installed. And could ELPA be enhanced to
provide an index of suitable packages for when a user does not have an
appropriate extension installed?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-12 2:34 ` Jason Rumney
@ 2011-11-12 3:00 ` Stefan Monnier
2011-11-12 3:33 ` Chong Yidong
0 siblings, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2011-11-12 3:00 UTC (permalink / raw
To: Jason Rumney; +Cc: rms, emacs-devel
> Something like Android Intents perhaps? Not only accessible via
> completion, but any elisp package that wants encryption should be able
> to say "encrypt-region" and hook into whatever suitable encryption
> providers the user has installed. And could ELPA be enhanced to
> provide an index of suitable packages for when a user does not have an
> appropriate extension installed?
That would be another avenue: define a standardized API. We already
have a few such things and we could add more, but it requires a careful
API which is sufficiently generic to be applicable to several packages.
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-12 3:00 ` Stefan Monnier
@ 2011-11-12 3:33 ` Chong Yidong
0 siblings, 0 replies; 18+ messages in thread
From: Chong Yidong @ 2011-11-12 3:33 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, rms, Jason Rumney
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> That would be another avenue: define a standardized API. We already
> have a few such things and we could add more, but it requires a careful
> API which is sufficiently generic to be applicable to several packages.
We could make the aliases first, then convert them to interface commands
as and when an alternative to EPA emerges (which may never happen, so
why go looking for extra work).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: name prefixes [was: epa command names]
2011-11-12 0:30 ` Richard Stallman
@ 2011-11-12 3:52 ` Stephen J. Turnbull
2011-11-12 23:32 ` Richard Stallman
2011-11-12 8:55 ` Andreas Röhler
1 sibling, 1 reply; 18+ messages in thread
From: Stephen J. Turnbull @ 2011-11-12 3:52 UTC (permalink / raw
To: rms; +Cc: Drew Adams, emacs-devel
Richard Stallman writes:
> Instead of allowing Emacs to flout its own guidelines,
>
> My proposal doesn't violate any Emacs guidelines.
Yeah, but it will surprise anybody who is currently using those
commands with their mailcrypt definitions. Not very nice IMHO.
In most cases, rather than use aliases users are allowed to pick the
implementation of `foo' by customizing `foo-function', and the "usual
implementation of `foo' either does
(progn
(apply #'foo-setup foo-args)
(apply foo-function foo-args))
or
(if foo-function
(apply foo-function foo-args))
;; default implementation goes here
)
This has the advantage that `foo-function' has a doctring (and often a
defcustom), and that documentation is pointed to by `foo's
documentation.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-11 22:07 ` epa command names Stefan Monnier
2011-11-11 22:28 ` Drew Adams
2011-11-12 2:34 ` Jason Rumney
@ 2011-11-12 6:36 ` Thierry Volpiatto
2011-11-12 7:22 ` Stefan Monnier
2 siblings, 1 reply; 18+ messages in thread
From: Thierry Volpiatto @ 2011-11-12 6:36 UTC (permalink / raw
To: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> 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.
http://tinyurl.com/cxwq73g
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-12 6:36 ` Thierry Volpiatto
@ 2011-11-12 7:22 ` Stefan Monnier
2011-11-12 8:07 ` Thierry Volpiatto
0 siblings, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2011-11-12 7:22 UTC (permalink / raw
To: Thierry Volpiatto; +Cc: emacs-devel
>>> 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?
Stefan
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-12 7:22 ` Stefan Monnier
@ 2011-11-12 8:07 ` Thierry Volpiatto
2011-11-12 23:32 ` Richard Stallman
0 siblings, 1 reply; 18+ messages in thread
From: Thierry Volpiatto @ 2011-11-12 8:07 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: name prefixes [was: epa command names]
2011-11-12 0:30 ` Richard Stallman
2011-11-12 3:52 ` Stephen J. Turnbull
@ 2011-11-12 8:55 ` Andreas Röhler
1 sibling, 0 replies; 18+ messages in thread
From: Andreas Röhler @ 2011-11-12 8:55 UTC (permalink / raw
To: emacs-devel; +Cc: Richard Stallman, Drew Adams
Am 12.11.2011 01:30, schrieb Richard Stallman:
>
> However, that's a different issue from my simple proposal to
> unconditionally define 5 or 10 aliases.
>
Hi,
aliator.el, a script which automates this was sent here:
http://lists.gnu.org/archive/html/gnu-emacs-sources/2006-07/msg00013.html
However, didn't use it much since...
Cheers,
Andreas
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: name prefixes [was: epa command names]
2011-11-12 3:52 ` Stephen J. Turnbull
@ 2011-11-12 23:32 ` Richard Stallman
2011-11-15 6:23 ` Kevin Rodgers
0 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2011-11-12 23:32 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: drew.adams, emacs-devel
Yeah, but it will surprise anybody who is currently using those
commands with their mailcrypt definitions. Not very nice IMHO.
epa replaces mailcrypt. These users will get almost the same behavior
with the new code, if the commands are changed over to epa.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-12 8:07 ` Thierry Volpiatto
@ 2011-11-12 23:32 ` Richard Stallman
2011-11-13 6:41 ` Thierry Volpiatto
0 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2011-11-12 23:32 UTC (permalink / raw
To: Thierry Volpiatto; +Cc: monnier, emacs-devel
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).
An aliasing method like this could be a good method
if it is limited to certain names for which we want it.
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"
I do not want such eager completion. Natural abbreviations
that we specific want to encourage, such as
`encryot-file' for `epa-encrypt-file', should not depend
on a general mechanism that tries to abbreviate everything.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: epa command names
2011-11-12 23:32 ` Richard Stallman
@ 2011-11-13 6:41 ` Thierry Volpiatto
0 siblings, 0 replies; 18+ messages in thread
From: Thierry Volpiatto @ 2011-11-13 6:41 UTC (permalink / raw
To: rms; +Cc: monnier, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> 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).
>
> An aliasing method like this could be a good method
> if it is limited to certain names for which we want it.
>
> 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"
>
> I do not want such eager completion. Natural abbreviations
> that we specific want to encourage, such as
> `encryot-file' for `epa-encrypt-file', should not depend
> on a general mechanism that tries to abbreviate everything.
anything will never match "encryot-file", just try it to have an idea of
what it does and doesn't.
http://repo.or.cz/w/anything-config.git
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: name prefixes [was: epa command names]
2011-11-12 23:32 ` Richard Stallman
@ 2011-11-15 6:23 ` Kevin Rodgers
2011-11-15 23:29 ` Richard Stallman
0 siblings, 1 reply; 18+ messages in thread
From: Kevin Rodgers @ 2011-11-15 6:23 UTC (permalink / raw
To: emacs-devel
On 11/12/11 4:32 PM, Richard Stallman wrote:
> Yeah, but it will surprise anybody who is currently using those
> commands with their mailcrypt definitions. Not very nice IMHO.
>
> epa replaces mailcrypt. These users will get almost the same behavior
> with the new code, if the commands are changed over to epa.
In the past, the author of the 3rd-party FOO package might implement
M-x insinuate-FOO.
--
Kevin Rodgers
Denver, Colorado, USA
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: name prefixes [was: epa command names]
2011-11-15 6:23 ` Kevin Rodgers
@ 2011-11-15 23:29 ` Richard Stallman
0 siblings, 0 replies; 18+ messages in thread
From: Richard Stallman @ 2011-11-15 23:29 UTC (permalink / raw
To: Kevin Rodgers; +Cc: emacs-devel
In the past, the author of the 3rd-party FOO package might implement
M-x insinuate-FOO.
My suggestion is specifically about epa and mailcrypt. If this
hypothetical FOO package calls for different treatment, let's treat
it differently.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-11-15 23:29 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-11 18:05 epa command names Richard Stallman
2011-11-11 18:26 ` name prefixes [was: epa command names] Drew Adams
2011-11-12 0:30 ` Richard Stallman
2011-11-12 3:52 ` Stephen J. Turnbull
2011-11-12 23:32 ` Richard Stallman
2011-11-15 6:23 ` Kevin Rodgers
2011-11-15 23:29 ` Richard Stallman
2011-11-12 8:55 ` Andreas Röhler
2011-11-11 22:07 ` epa command names Stefan Monnier
2011-11-11 22:28 ` Drew Adams
2011-11-12 2:34 ` Jason Rumney
2011-11-12 3:00 ` Stefan Monnier
2011-11-12 3:33 ` Chong Yidong
2011-11-12 6:36 ` Thierry Volpiatto
2011-11-12 7:22 ` Stefan Monnier
2011-11-12 8:07 ` Thierry Volpiatto
2011-11-12 23:32 ` Richard Stallman
2011-11-13 6:41 ` Thierry Volpiatto
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.