Describe keymap

Describe keymap

[Ergus]

Hi:

I am wondering why there is not a function like describe-keymap in order
to present a keymap in a human readable way.

I suppose that most of the infrastructure must be there because that's
what describe-bindings does. So, really nobody have needed such a
command before?????

Best,
Ergus

RE: Describe keymap

[Drew Adams]

> I am wondering why there is not a function like describe-keymap in order
> to present a keymap in a human readable way.
> 
> I suppose that most of the infrastructure must be there because that's
> what describe-bindings does. So, really nobody have needed such a
> command before?????

I added `describe-keymap' to my library `help-fns+.el'
in 2007.  It's still there.

https://www.emacswiki.org/emacs/download/help-fns%2b.el

A while ago we added it to vanilla Emacs, for Emacs 28.
(The version in `help-fns+.el' is still better, IMO,
but they're essentially the same.)

https://www.emacswiki.org/emacs/HelpPlus

Re: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> I added `describe-keymap' to my library `help-fns+.el' in
> 2007. It's still there [...]
>
> A while ago we added it to vanilla Emacs, for Emacs 28. (The
> version in `help-fns+.el' is still better, IMO, but they're
> essentially the same.)

Neat! Really good! Good work!

Just tried it with `gnus-article-mode'. Only, three lines
confuses me:

  S <t>           gnus-article-read-summary-send-keys

the angle brackets; and

  <remap>         Prefix Command
  <remap> <self-insert-command>   gnus-article-read-summary-keys

?

Maybe something gnus-article-mode specific...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>   S <t>           gnus-article-read-summary-send-keys
>> 
>> the angle brackets; 
>
> That's just the standard Emacs way of writing a key binding.
> `C-h k' and `C-h b' use the same syntax. `describe-keymap' does
> nothing special here.

Well, it might be the standard somewhere else, but here it is
the one exception:

  [...]
  S W             gnus-article-wide-reply-with-original
  S <t>           gnus-article-read-summary-send-keys

  C-h b           gnus-article-describe-bindings
  C-h c           gnus-article-describe-key-briefly
  C-h k           gnus-article-describe-key

  C-c C-b         gnus-bug
  C-c C-f         gnus-summary-mail-forward
  C-c TAB         gnus-info-find-node
  C-c RET         gnus-article-mail
  C-c ^           gnus-article-refer-article
  [...]

>>   <remap>         Prefix Command
>>   <remap> <self-insert-command>   gnus-article-read-summary-keys
>> 
>> ?
>
> Sorry, I don't understand the question. But see above.
> There's nothing special/different about how `describe-keymap'
> lists key bindings. It just shows the key bindings of
> a keymap in human-readable form (as opposed to what `C-h v'
> shows you for a keymap variable).

What do these lines mean?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

FW: Describe keymap

[Drew Adams]

[Adding the missing help-gnu-emacs list.
Reply All never works (for me) when replying to your mails.]

> > I added `describe-keymap' to my library `help-fns+.el' in
> > 2007. It's still there [...]
> >
> > A while ago we added it to vanilla Emacs, for Emacs 28. (The
> > version in `help-fns+.el' is still better, IMO, but they're
> > essentially the same.)
> 
> Neat! Really good! Good work!
> 
> Just tried it with `gnus-article-mode'. Only, three lines
> confuses me:
> 
>   S <t>           gnus-article-read-summary-send-keys
> 
> the angle brackets; 

That's just the standard Emacs way of writing a key
binding.  `C-h k' and `C-h b' use the same syntax.
`describe-keymap' does nothing special here.

> and
> 
>   <remap>         Prefix Command
>   <remap> <self-insert-command>   gnus-article-read-summary-keys
> 
> ?
> 
> Maybe something gnus-article-mode specific...

Sorry, I don't understand the question.  But see
above.  There's nothing special/different about how
`describe-keymap' lists key bindings.  It just shows
the key bindings of a keymap in human-readable form
(as opposed to what `C-h v' shows you for a keymap
variable).

FW: Describe keymap

[Drew Adams]

[Adding the missing help-gnu-emacs list.
Reply All never works (for me) when replying to your mails.]

> >>   S <t>           gnus-article-read-summary-send-keys
> >>
> >> the angle brackets;
> >
> > That's just the standard Emacs way of writing a key binding.
> > `C-h k' and `C-h b' use the same syntax. `describe-keymap' does
> > nothing special here.
> 
> Well, it might be the standard somewhere else, but here it is
> the one exception:
> 
>   [...]
>   S W             gnus-article-wide-reply-with-original
>   S <t>           gnus-article-read-summary-send-keys
> 
>   C-h b           gnus-article-describe-bindings
>   C-h c           gnus-article-describe-key-briefly
>   C-h k           gnus-article-describe-key
> 
>   C-c C-b         gnus-bug
>   C-c C-f         gnus-summary-mail-forward
>   C-c TAB         gnus-info-find-node
>   C-c RET         gnus-article-mail
>   C-c ^           gnus-article-refer-article
>   [...]
> 
> >>   <remap>         Prefix Command
> >>   <remap> <self-insert-command>   gnus-article-read-summary-keys
> >>
> >> ?
> >
> > Sorry, I don't understand the question. But see above.
> > There's nothing special/different about how `describe-keymap'
> > lists key bindings. It just shows the key bindings of
> > a keymap in human-readable form (as opposed to what `C-h v'
> > shows you for a keymap variable).
> 
> What do these lines mean?

Dunno.  I don't use gnus.

What keys does `C-h f gnus-article-read-summary-keys'
tell you that command is bound to?

Re: Describe keymap

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>   S <t>           gnus-article-read-summary-send-keys

That is actually `t', the symbol, and
(info "(elisp) Format of Keymaps") tells you:

| ‘(t . BINDING)’
|      This specifies a “default key binding”; any event not bound by
|      other elements of the keymap is given BINDING as its binding.
|      Default bindings allow a keymap to bind all possible event types
|      without having to enumerate all of them.  A keymap that has a
|      default binding completely masks any lower-precedence keymap,
|      except for events explicitly bound to ‘nil’ (see below).

In this special case, S lets you invoke summary buffer commands from
within the article buffer.  Try e.g. S f with the article buffer
current.

> the angle brackets; and
>
>   <remap>         Prefix Command
>   <remap> <self-insert-command>   gnus-article-read-summary-keys

Again, these are symbols.  The items are command remappings, and this is
explained in (info "(elisp) Remapping Commands").

Seems the brackets just denote symbols, ordinary keys most of the time,
like <f1>, compared to keys that are numbers internally, like "k".

Michael.

Re: FW: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> Reply All never works (for me) when replying to your mails.]

OK, why not?

Oh, my, now the subject has changed as well...

> What keys does `C-h f gnus-article-read-summary-keys' tell
> you that command is bound to?

Doesn't say anything about that what I can see?

  gnus-article-read-summary-keys is an autoloaded interactive
  compiled Lisp function in ‘gnus-art.el’.

  (gnus-article-read-summary-keys &optional ARG KEY
  NOT-RESTORE-WINDOW)

  Read a summary buffer key sequence and execute it from the
  article buffer.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

>>   S <t>           gnus-article-read-summary-send-keys
>
> That is actually `t', the symbol, and (info "(elisp) Format
> of Keymaps") tells you:
>
> | ‘(t . BINDING)’
> |      This specifies a “default key binding”; any event not
> |      bound by other elements of the keymap is given BINDING
> |      as its binding. Default bindings allow a keymap to
> |      bind all possible event types without having to
> |      enumerate all of them. A keymap that has a default
> |      binding completely masks any lower-precedence keymap,
> |      except for events explicitly bound to ‘nil’ (see
> |      below).
>
> In this special case, S lets you invoke summary buffer
> commands from within the article buffer. Try e.g. S f with
> the article buffer current.
>
>> the angle brackets; and
>>
>>   <remap>         Prefix Command
>>   <remap> <self-insert-command>   gnus-article-read-summary-keys
>
> Again, these are symbols. The items are command remappings,
> and this is explained in (info "(elisp) Remapping Commands").
>
> Seems the brackets just denote symbols, ordinary keys most of
> the time, like <f1>, compared to keys that are numbers
> internally, like "k".

OK, thanks, good research :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: FW: Describe keymap

[Robert Pluim]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Drew Adams wrote:
>
>> Reply All never works (for me) when replying to your mails.]
>
> OK, why not?
>

Because you have Reply-To set (and Mail-Followup-To, but I think
Drew's MUA ignores that)

Robert

Re: FW: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Pluim wrote:

> Because you have Reply-To set (and Mail-Followup-To, but
> I think Drew's MUA ignores that)

Thanks, that's exactly right, they are

  Reply-To: Emanuel Berg <moasenwood@zoho.eu>
  Mail-Followup-To: help-gnu-emacs@gnu.org

I don't remember configuring that, but again there has been so
much configuration...

Anyway yes, it seems Technologist Adams's client is to blame,
since the MFT seems to make sense.

  ‘Mail-Followup-To’
   
      One of more address(es) to use as default recipient(s)
      for follow-up messages. This is typically used when you
      reply to a message from a mailing list that you are
      subscribed to, and want replies to go to the list without
      sending an extra copy to you. [1]

Or is it, that these headers values are mutually exclusive?
Should I not have the Reply-To when I have the
Mail-Followup-To?

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Mail-Headers.html

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: FW: Describe keymap

[Robert Pluim]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Robert Pluim wrote:
>
>> Because you have Reply-To set (and Mail-Followup-To, but
>> I think Drew's MUA ignores that)
>
> Thanks, that's exactly right, they are
>
>   Reply-To: Emanuel Berg <moasenwood@zoho.eu>
>   Mail-Followup-To: help-gnu-emacs@gnu.org
>
> I don't remember configuring that, but again there has been so
> much configuration...
>

Itʼs possible that itʼs the mailing list putting those in for
you, since itʼs rewriting your From header as well (I assume youʼre
sending to the mailing list)

Robert

Re: FW: Describe keymap

[Gregory Heytings via Users list for the GNU Emacs text editor]

>>> Because you have Reply-To set (and Mail-Followup-To, but I think 
>>> Drew's MUA ignores that)
>>
>> Thanks, that's exactly right, they are
>>
>>   Reply-To: Emanuel Berg <moasenwood@zoho.eu>
>>   Mail-Followup-To: help-gnu-emacs@gnu.org
>>
>> I don't remember configuring that, but again there has been so much 
>> configuration...
>
> Itʼs possible that itʼs the mailing list putting those in for you, since 
> itʼs rewriting your From header as well (I assume youʼre sending to the 
> mailing list)
>

Yes, it's the mailing list, because the domain name Emanuel uses (zoho.eu) 
has a strict DMARC policy:

$ dig +short -t txt _dmarc.zoho.eu
"v=DMARC1; p=reject; sp=reject; fo=0; rua=mailto:dmarc.reports.eu@zoho.eu; ruf=mailto:dmarc.reports.eu@zoho.eu"

The two "reject" means that the policy is strict.  Compare this to, for 
instance:

$ dig +short -t txt _dmarc.gmail.com
"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
$ dig +short -t txt _dmarc.gnu.org
"v=DMARC1; p=none; rua=mailto:dmarc-rua@fsf.org"

Re: FW: Describe keymap

[Robert Pluim]

Gregory Heytings via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:
>> Itʼs possible that itʼs the mailing list putting those in for you,
>> since itʼs rewriting your From header as well (I assume youʼre
>> sending to the mailing list)
>>
>
> Yes, it's the mailing list, because the domain name Emanuel uses
> (zoho.eu) has a strict DMARC policy:
>
> $ dig +short -t txt _dmarc.zoho.eu
> "v=DMARC1; p=reject; sp=reject; fo=0; rua=mailto:dmarc.reports.eu@zoho.eu; ruf=mailto:dmarc.reports.eu@zoho.eu"
>
> The two "reject" means that the policy is strict.  Compare this to,
> for instance:
>
> $ dig +short -t txt _dmarc.gmail.com
> "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
> $ dig +short -t txt _dmarc.gnu.org
> "v=DMARC1; p=none; rua=mailto:dmarc-rua@fsf.org"

Ah yes, Iʼd forgotten about that, I guess my brain had better things
to do than remember DMARC :-)

Robert

Re: FW: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Pluim wrote:

> It's possible that it's the mailing list putting those in for
> you, since it's rewriting your From header as well (I assume
> you're sending to the mailing list)

I send to gmane.emacs.help from news.gmane.io .

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: FW: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings via Users list for the GNU Emacs text editor wrote:

> Yes, it's the mailing list, because the domain name Emanuel
> uses (zoho.eu) has a strict DMARC policy:
>
> $ dig +short -t txt _dmarc.zoho.eu
> "v=DMARC1; p=reject; sp=reject; fo=0;
> rua=mailto:dmarc.reports.eu@zoho.eu;
> ruf=mailto:dmarc.reports.eu@zoho.eu"

Ah, right, that whole story with zoho! That is also why
I have/get the via line in the From header. Feels like
AGES ago!

There was also some big politics to it. Like Gmail trying to
bully people not using Gmail or something?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: FW: Describe keymap

[Robert Pluim]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Gregory Heytings via Users list for the GNU Emacs text editor wrote:
>
>> Yes, it's the mailing list, because the domain name Emanuel
>> uses (zoho.eu) has a strict DMARC policy:
>>
>> $ dig +short -t txt _dmarc.zoho.eu
>> "v=DMARC1; p=reject; sp=reject; fo=0;
>> rua=mailto:dmarc.reports.eu@zoho.eu;
>> ruf=mailto:dmarc.reports.eu@zoho.eu"
>
> Ah, right, that whole story with zoho! That is also why
> I have/get the via line in the From header. Feels like
> AGES ago!
>
> There was also some big politics to it. Like Gmail trying to
> bully people not using Gmail or something?

Not really. Itʼs the various mail providers attempting to stop spam
masquerading as coming from them, which then unfortunately prevents
mailing lists from sending on your email with the original From, since
they're not your email provider. Gmail is fairly liberal, hence why my
messages donʼt get munged.

Robert

Robert

Re: FW: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Pluim wrote:

>> Ah, right, that whole story with zoho! That is also why
>> I have/get the via line in the From header. Feels like
>> AGES ago!
>>
>> There was also some big politics to it. Like Gmail trying to
>> bully people not using Gmail or something?
>
> Not really. It's the various mail providers attempting to
> stop spam masquerading as coming from them, which then
> unfortunately prevents mailing lists from sending on your
> email with the original From, since they're not your email
> provider. Gmail is fairly liberal, hence why my messages
> don't get munged.

OK, but there was _something_ like that, maybe not Gmail then.
I still have the thread URL noted in a file [1] with a bunch of
commands that were proposed to figure this out, including the
one just mentioned, dig(1).

Here is the thread:

# discussion and commands:
#   http://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00476.html
#   http://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00477.html
#   http://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00481.html

[1] https://dataswamp.org/~incal/conf/.zsh/mail

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: FW: Describe keymap

[Robert Pluim]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Robert Pluim wrote:
>
>>> Ah, right, that whole story with zoho! That is also why
>>> I have/get the via line in the From header. Feels like
>>> AGES ago!
>>>
>>> There was also some big politics to it. Like Gmail trying to
>>> bully people not using Gmail or something?
>>
>> Not really. It's the various mail providers attempting to
>> stop spam masquerading as coming from them, which then
>> unfortunately prevents mailing lists from sending on your
>> email with the original From, since they're not your email
>> provider. Gmail is fairly liberal, hence why my messages
>> don't get munged.
>
> OK, but there was _something_ like that, maybe not Gmail then.

Yes, but it's zoho.eu who have the restrictive policy, not gmail.

Robert

Re: FW: Describe keymap

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Pluim wrote:

>> OK, but there was _something_ like that, maybe not
>> Gmail then.
>
> Yes, but it's zoho.eu who have the restrictive policy,
> not gmail.

Indeed, see this message:

  https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00481.html

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal