epa command names

epa command names

[Richard Stallman]

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/

name prefixes [was: epa command names]

[Drew Adams]

> 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.

Re: name prefixes [was: epa command names]

[Richard Stallman]

    > 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/

Re: name prefixes [was: epa command names]

[Stephen J. Turnbull]

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.

Re: name prefixes [was: epa command names]

[Richard Stallman]

    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/

Re: name prefixes [was: epa command names]

[Kevin Rodgers]

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

Re: name prefixes [was: epa command names]

[Richard Stallman]

    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/

Re: name prefixes [was: epa command names]

[Andreas Röhler]

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

Re: epa command names

[Stefan Monnier]

> 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

RE: epa command names

[Drew Adams]

> 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.)

Re: epa command names

[Jason Rumney]

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?

Re: epa command names

[Stefan Monnier]

> 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

Re: epa command names

[Chong Yidong]

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).

Re: epa command names

[Thierry Volpiatto]

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 

Re: epa command names

[Stefan Monnier]

>>> 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

Re: epa command names

[Thierry Volpiatto]

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 

Re: epa command names

[Richard Stallman]

    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/

Re: epa command names

[Thierry Volpiatto]

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