bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

(kbd "M-<TAB>") incorrectly returns [M-TAB].  IMHO, it should return
[134217737], the same thing that (kbd "M-TAB") returns.
 
IOW, for consistency, TAB should be treated specially here, in the
same way that NUL, RET, LFD, ESC, SPC, and DEL are treated specially.
 
Yes, it is true that there is no predefined function key named `NUL'
etc.  But there is also no predefined function key named `TAB'.  The
predefined function key is named `tab', not `TAB'.  `M-<tab>' is not the
same thing as `M-<TAB>', of course.  It is better to help users avoid
such possible confusion by treating `TAB' the same way we treat `NUL' etc.
 

diff -c edmacro.el edmacro-patched.el
*** edmacro.el Fri Sep 28 13:55:18 2012
--- edmacro-patched.el Fri Sep 28 13:56:24 2012
***************
*** 708,714 ****
        (substring word (match-beginning 3)
            (match-end 3))))
          (not (string-match
!        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
         word))))
          (setq key (list (intern word))))
         ((or (equal word "REM") (string-match "^;;" word))
--- 708,714 ----
        (substring word (match-beginning 3)
            (match-end 3))))
          (not (string-match
!        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\TAB\\)$"
         word))))
          (setq key (list (intern word))))
         ((or (equal word "REM") (string-match "^;;" word))
 
Diff finished.  Fri Sep 28 13:56:44 2012
 
 
In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-09-17 on MARVIN
Bzr revision: 110062 cyd@gnu.org-20120917054104-r93rtwkrtva73ewe
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> (kbd "M-<TAB>") incorrectly returns [M-TAB].  IMHO, it should return
> [134217737], the same thing that (kbd "M-TAB") returns.
>
> IOW, for consistency, TAB should be treated specially here, in the
> same way that NUL, RET, LFD, ESC, SPC, and DEL are treated specially.

Makes sense, I guess, but I'm not familiar with the `kbd' use cases.

[...]

> !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
>          word))))
>           (setq key (list (intern word))))
>          ((or (equal word "REM") (string-match "^;;" word))
> --- 708,714 ----
>         (substring word (match-beginning 3)
>             (match-end 3))))
>           (not (string-match
> !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\TAB\\)$"

There's probably a missing | in the patch...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
> >          word))))
> >           (setq key (list (intern word))))
> >          ((or (equal word "REM") (string-match "^;;" word))
> > --- 708,714 ----
> >         (substring word (match-beginning 3)
> >             (match-end 3))))
> >           (not (string-match
> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\TAB\\)$"
> 
> There's probably a missing | in the patch...

Yes, good catch.  Should be \\|TAB, not \\TAB.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
>> >          word))))
>> >           (setq key (list (intern word))))
>> >          ((or (equal word "REM") (string-match "^;;" word))
>> > --- 708,714 ----
>> >         (substring word (match-beginning 3)
>> >             (match-end 3))))
>> >           (not (string-match
>> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\TAB\\)$"
>> 
>> There's probably a missing | in the patch...
>
> Yes, good catch.  Should be \\|TAB, not \\TAB.

Can you submit a new patch, preferably tested?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> >> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
> >> >          word))))
> >> >           (setq key (list (intern word))))
> >> >          ((or (equal word "REM") (string-match "^;;" word))
> >> > --- 708,714 ----
> >> >         (substring word (match-beginning 3)
> >> >             (match-end 3))))
> >> >           (not (string-match
> >> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\TAB\\)$"
> >>
> >> There's probably a missing | in the patch...
> >
> > Yes, good catch.  Should be \\|TAB, not \\TAB.
> 
> Can you submit a new patch, preferably tested?

Sorry; I really don't have the time now.  But I think that all
of the relevant info has been provided, so you should be able
to DTRT.  The patch is quite tiny.  And it is unlikely that
the `edmacro-parse-keys' has changed much, if at all, since
2014.  Just change \\TAB to \\|TAB in the patch.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> >> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
>> >> >          word))))
>> >> >           (setq key (list (intern word))))
>> >> >          ((or (equal word "REM") (string-match "^;;" word))
>> >> > --- 708,714 ----
>> >> >         (substring word (match-beginning 3)
>> >> >             (match-end 3))))
>> >> >           (not (string-match
>> >> > !        "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\TAB\\)$"
>> >>
>> >> There's probably a missing | in the patch...
>> >
>> > Yes, good catch.  Should be \\|TAB, not \\TAB.
>> 
>> Can you submit a new patch, preferably tested?
>
> Sorry; I really don't have the time now.  But I think that all
> of the relevant info has been provided, so you should be able
> to DTRT.  The patch is quite tiny.  And it is unlikely that
> the `edmacro-parse-keys' has changed much, if at all, since
> 2014.  Just change \\TAB to \\|TAB in the patch.

The patch you sent obviously hadn't been tested, because it was
syntactically wrong.  I'm not going to apply patches that haven't been
tested.

Please create a new patch and post it here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> >> Can you submit a new patch, preferably tested?
> >
> > Sorry; I really don't have the time now.  But I think that all
> > of the relevant info has been provided, so you should be able
> > to DTRT.  The patch is quite tiny.  And it is unlikely that
> > the `edmacro-parse-keys' has changed much, if at all, since
> > 2014.  Just change \\TAB to \\|TAB in the patch.
> 
> The patch you sent obviously hadn't been tested, because it was
> syntactically wrong.  I'm not going to apply patches that haven't been
> tested.
> 
> Please create a new patch and post it here.

See my previous comment.  If you don't want to make the
one-line change required to fix this bug, too bad.

You've been working a lot on bugs today, which is great.
You're tired, and so am I.  And we are no doubt both busy
with other things too.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> See my previous comment.  If you don't want to make the
> one-line change required to fix this bug, too bad.

If you can't be bothered to test the code you're submitting, that's also
too bad.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> See my previous comment.  If you don't want to make the
>> one-line change required to fix this bug, too bad.
>
> If you can't be bothered to test the code you're submitting, that's also
> too bad.

And that didn't happen in the three years since, so I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> >> See my previous comment.  If you don't want to make the
> >> one-line change required to fix this bug, too bad.
> >
> > If you can't be bothered to test the code you're submitting, that's also
> > too bad.
> 
> And that didn't happen in the three years since, so I'm closing this bug
> report.

Truly ridiculous.  A _great_ example (unfortunately).

Ten msgs back & forth.  Trivial change of this line:

			    "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"

to this one (just add "\\|TAB"):

			    "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\|TAB\\)$"
                                                              ^^^^^^

So much for users reporting bugs.  Just the bug
report, regardless of whether any freebie
suggested solution code was also provided (which
it was), should have sufficed to get this fixed
7 years ago.

With also a description of the solution (just add
an entry for TAB) - again regardless of whether
suggested code to do that was also provided - it's
inconceivable that nothing was done about this (and
in fact there was pedantic pushback).  Lamentable.

Users _help_ by reporting bugs.  End of story.

It's not important to this reporter _how_ the bug
gets fixed.  If you find something deficient about
the fix that was volunteered, another fix is fine.
The point is that there's a bug.  (And any fix
should be trivial, here.)

Do you think there's no bug?

Or is it "wontfix" because it's too difficult to
fix?  Or because you don't think it should be
fixed?  Or because you don't like the suggested
fix, and you don't want to look for a better one?
Or is it just because you want to fight or play a
game of some kind?

I really cannot imagine why that 6-char fix would
not have been applied sometime in the 7 years that
have elapsed since the report - let alone why the
bug would now be closed as "wontfix".

Of course, if there's a good argument as to why
there's no bug, that's different.  None has been
presented.

The bug report was just handled like a complaint
form filled out improperly:

fill-out-the-form-again-and-go-to-the-end-of-the-line-and-start-over.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

> I really cannot imagine why that 6-char fix would
> not have been applied sometime in the 7 years that
> have elapsed since the report - let alone why the
> bug would now be closed as "wontfix".

I think the reason is that when you say things like this:

    > Can you submit a new patch, preferably tested?

    Sorry; I really don't have the time now.  But I think that all
    of the relevant info has been provided, so you should be able
    to DTRT.

You unavoidably send the message that your time is more important than
the person handling your bug report (to be clear, it's not the "I'm busy
right now" part alone, but the combination of "I'm busy, you do it"
that's the problem).

> Just the bug report, regardless of whether any freebie suggested
> solution code was also provided (which it was) [...]

Similarly, use of the word "freebie" implies that you don't consider the
time spent reading and checking posted patches for mistakes as important.

If bug reports were answered by utility-maximising robots this wouldn't
matter.  However, we have only squishy humans available for bug report
handling.  Therefore, please try to think about the human on the
receiving end before you post something.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> > I really cannot imagine why that 6-char fix would
> > not have been applied sometime in the 7 years that
> > have elapsed since the report - let alone why the
> > bug would now be closed as "wontfix".
> 
> I think the reason is that when you say things like this:
> 
>   > Can you submit a new patch, preferably tested?
> 
>   Sorry; I really don't have the time now.  But I
>   think that all of the relevant info has been
>   provided, so you should be able to DTRT.
> 
> You unavoidably send the message that your time is more important than
> the person handling your bug report (to be clear, it's not the "I'm busy
> right now" part alone, but the combination of "I'm busy, you do it"
> that's the problem).

The "YOU should be able" was not, and is not,
directed at any particular person.  It's not at
all about "the person handling [my] bug report".
Not that I don't take into consideration someone
handling the report, but that "you" is not about
that person or any other.

It's a statement that the bug description - and
even a possible solution - is complete and clear
(IMHO), and Someone(TM) _could_ easily apply it.

And it questions why the bug should be _closed_,
if it has not yet been fixed.

It's not at all about my time vs someone else's
time.  We each contribute the way we can and the
way we want to.  I contributed a bug report, and
a possible fix, and I then contributed time and
effort trying to clarify and better communicate
the problem and proposed fix.

The possible fix is an "extra", a "nice-to-have",
a "freebie". - it's fine if how I think the
problem might be fixed is ignored in favor of a
better solution.  What's important is the bug
report - recording the bug so we're aware of it,
and so it might be fixed someday.

We are _all_ volunteers.  Submitting a bug report
is volunteer work, intended to help Emacs.  No
one should take a bug report as a commandment to
work or as a burden.  Bug reports are good, not
bad.  And they are for us all; they are not
personal directives for anyone to do anything.

> > Just the bug report, regardless of whether
> > any freebie suggested solution code was also
> > provided (which it was) [...]
> 
> Similarly, use of the word "freebie" implies that you don't consider the
> time spent reading and checking posted patches for mistakes as important.

No, it does not imply that at all.  See above.  It
stresses that what's important in the contribution
I chose to make is the bug report.  _If_ someone
wants to _also_ consider the fix I suggested, fine;
if not, another fix would be fine.

There is nothing in what I said that suggests that
I consider the work of actually fixing the bug to
be unimportant or trivial.  Relative to other bug
fixes I do think the suggested fix is pretty simple.

But I know that it takes time to apply and test
even a simple fix.  Just because I don't work on
that myself doesn't mean I trivialize that work
if done by someone else.  Quite the contrary.

If a school boy spends extra time reading poetry
and neglects his math studies, does that mean he
thinks math is unimportant or trivial?  No, that
doesn't follow.  He just prefers reading poetry.

The use of "freebie" emphasizes that I don't care
whether it gets fixed using my fix suggestion -
that was just a suggestion, aimed to help.  If
someone has a better fix then that's even better.

The point is that there is a _bug_, described.
It can be fixed, and I think that can be done
easily.  Whether someone else has the time or
will to do that is for them to decide.

When a user submits a bug report it's OK to ask
if they also want to provide a patch.  It's not
so OK to close the bug just because they don't
decline to do that.

In this case, the code change for the suggested
fix is truly trivial.  Requiring a patch and
testing from the submitter is over the top, IMO.

If that's the requirement - that the bug won't
be fixed unless the reporter submits a tested
patch - so be it.

Note the difference: The fact that the bug
_hasn't_ been fixed _because_ of that is a
bit surprising to me.  But _closing_ the bug
because of that, and because it hasn't yet
been fixed, is not good (IMHO).

> If bug reports were answered by utility-maximising robots this wouldn't
> matter.  However, we have only squishy humans available for bug report
> handling.  Therefore, please try to think about the human on the
> receiving end before you post something.

We are _all_ squishy humans, including users
who volunteer bug reports and possible fixes,
however imperfect or unclear the report or
unwise or imperfect the fix.

This reporter does _not_ expect that robots
read Emacs bug reports and fix bugs.  Nor do
I expect bugs to be closed robotically.  I'm
grateful that other squishy humans read bug
reports, try to understand them, and sometimes
find time to fix them.  I've always been so. 

Did I hound this thread with demands that
this bug be fixed - let alone demands that my
suggested fix be applied?  I don't think so.
How many years have passed?  How many times
did I ping or insist that it be fixed?

If no one wants to fix it, fine - but too bad
(for us all).  I don't blame (and have not
blamed) anyone for not volunteering to fix it.
I expressed surprise, years later, that it
hasn't been fixed and, especially, that it's
being closed.

Personally, I don't think such a bug (or any
bug that is recognized as such and is not
deemed unfeasible to fix) should be closed.

But I know that others can feel differently.
In some organizations (e.g. companies) there
are members whose job it is to reduce the set
of outstanding bugs.

I don't see why a user-run volunteer group
would want to close bugs (recognized as bugs
and as feasible to fix) just because time has
passed or there is currently no one to work
on fixing them.  No one gets a raise from
reducing the bug count.  But again, I know
that others can see this differently.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Eli Zaretskii]

> Date: Sun, 7 Jul 2019 08:34:42 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 12535@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> 
> >   Sorry; I really don't have the time now.  But I
> >   think that all of the relevant info has been
> >   provided, so you should be able to DTRT.
> > 
> > You unavoidably send the message that your time is more important than
> > the person handling your bug report (to be clear, it's not the "I'm busy
> > right now" part alone, but the combination of "I'm busy, you do it"
> > that's the problem).
> 
> The "YOU should be able" was not, and is not,
> directed at any particular person.  It's not at
> all about "the person handling [my] bug report".
> Not that I don't take into consideration someone
> handling the report, but that "you" is not about
> that person or any other.
> [...]

Drew, you are repeatedly told by different people that your style and
choice of words makes others think twice before handling your reports
and requests.  I'd suggest to consider the possibility that there's at
least some truth in that, and choose your words differently.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

[Trying again, after unarchiving.]

This is closed, marked as "DONE".  Doesn't that mean
that it was fixed?  (I'm not clear on what "DONE" is
meant to indicate.)

If so, that's incorrect - the bug is still present.
Shouldn't it be tagged as "wontfix", since that was
the decision?  (Or perhaps "DONE" includes closures
other than just fixes?)
___

BTW, in addition to adding \\|TAB where I suggested,
the code could be improved slightly by changing most
of the `string-match' occurrences to `string-match-p',
as most of them don't need to set the match data.

Just a (minor) suggestion.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Eli Zaretskii]

> Date: Tue, 13 Oct 2020 21:53:45 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: npostavs@gmail.com, 12535@debbugs.gnu.org, larsi@gnus.org
> 
> If so, that's incorrect - the bug is still present.

Btw, I'm not sure I agree with the proposed fix: <TAB> and TAB are
different keys.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> > If so, that's incorrect - the bug is still present.
> 
> Btw, I'm not sure I agree with the proposed fix: <TAB> and TAB are
> different keys.

Yes, but then why wouldn't we also consider <ESC> and
ESC to be different keys?

`kbd' and `edmacro-parse-keys' treat them both the same.

Likewise, all the others in the same clause:

"\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"

Why, for all of those, does Emacs consider <WORD> and
WORD to be the same key, where WORD is any of those
ASCII control-char names (NUL, RET, LFD, ESC, SPC, DEL),
but it doesn't consider <TAB> and TAB to be the same key.

IOW, isn't your saying that they are different keys just
another way of saying what `edmacro-parse-keys' does
currently?  Isn't it just proclaiming that there's no
bug because what is, is right?

It's quite possible I'm missing something, in which case
please let me know what.  So far, I don't know of a good
explanation, and I haven't found one in the doc or code
comments.

I understand why we treat <tab> differently from TAB.
I don't understand why we treat <TAB> differently from
TAB.

Why is TAB not handled like NUL, RET, etc.?  They're
all ASCII control chars.  (They aren't like the case of
F9, <F9>, and <f9>.)

Thanks for thinking about this, and perhaps finding a
good explanation/rationalization.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 09:13:22 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: npostavs@gmail.com, 12535@debbugs.gnu.org, larsi@gnus.org
> 
> > > If so, that's incorrect - the bug is still present.
> > 
> > Btw, I'm not sure I agree with the proposed fix: <TAB> and TAB are
> > different keys.
> 
> Yes, but then why wouldn't we also consider <ESC> and
> ESC to be different keys?

Because they aren't.

TAB is the ASCII character Ctrl-I, whereas <TAB> is the _function_ key
Tab.  Modern keyboards can produce both, and Emacs maps the latter to
the former.  But there's no function key Esc on the keyboard.

> Likewise, all the others in the same clause:
> 
> "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"

We do have the same situation with DEL vs <Delete> and <Backspace>.
But not with the others you mention.

> Why, for all of those, does Emacs consider <WORD> and
> WORD to be the same key, where WORD is any of those
> ASCII control-char names (NUL, RET, LFD, ESC, SPC, DEL),
> but it doesn't consider <TAB> and TAB to be the same key.

You are missing the point: the brackets is not some syntactic sugar,
it is an indication of a function key, like <F1> and <DOWN>.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > TAB is the ASCII character Ctrl-I, whereas <TAB> is the _function_ key
  > Tab.  Modern keyboards can produce both, and Emacs maps the latter to
  > the former.  But there's no function key Esc on the keyboard.

If the key that says "Tab" is the function key <TAB>, and you produce
ASCII TAB by typing C-i, that is not inherently different from the
situation with ESC.  You can produce the ASCII ESC character by typing
C-[, so we _could_ treat the key labeled "ESC" as <ESC>.  That would
be uniform.

I don't remember whether we treat tab and esc alike in that way or not.
I am mot saying we should change how Emacs handles them.
I'm only saying that it is possible to do so.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: drew.adams@oracle.com, 12535@debbugs.gnu.org, larsi@gnus.org,
> 	npostavs@gmail.com
> Date: Fri, 16 Oct 2020 00:07:50 -0400
> 
> If the key that says "Tab" is the function key <TAB>, and you produce
> ASCII TAB by typing C-i, that is not inherently different from the
> situation with ESC.  You can produce the ASCII ESC character by typing
> C-[, so we _could_ treat the key labeled "ESC" as <ESC>.  That would
> be uniform.

But AFAIU the keyboard input systems we use don't work like that, and
we simply follow them.

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams]

> > > > If so, that's incorrect - the bug is still present.
> > >
> > > Btw, I'm not sure I agree with the proposed fix: <TAB> and TAB are
> > > different keys.
> >
> > Yes, but then why wouldn't we also consider <ESC> and
> > ESC to be different keys?
> 
> Because they aren't.
> 
> TAB is the ASCII character Ctrl-I, whereas <TAB> is the _function_ key
> Tab.  Modern keyboards can produce both, and Emacs maps the latter to
> the former.  But there's no function key Esc on the keyboard.
> 
> > Likewise, all the others in the same clause:
> >
> > "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
> 
> We do have the same situation with DEL vs <Delete> and <Backspace>.
> But not with the others you mention.
> 
> > Why, for all of those, does Emacs consider <WORD> and
> > WORD to be the same key, where WORD is any of those
> > ASCII control-char names (NUL, RET, LFD, ESC, SPC, DEL),
> > but it doesn't consider <TAB> and TAB to be the same key.
> 
> You are missing the point: the brackets is not some syntactic sugar,
> it is an indication of a function key, like <F1> and <DOWN>.

That's the point - why are we interpreting <TAB> as a
function key, as if TAB were as unknown as foobar, which
we handle as (unknown) function key <foobar>?  Why aren't
we interpreting TAB the same way we interpret ESC, RET,
and SPC, that is, interpreting <TAB> the same way we
interpret <ESC>, <RET>, and <SPC>?

You say Tab is a function key (you wrote it like that), at
least on some keyboards.  So is tab apparently, which Emacs
writes as <tab>.  And which is (naturally, good) not
considered the same (function) key as <TAB>.  But your Tab
function key is written <TAB>?

Are you sure there are no keyboards, or there won't be any,
that have a function key named Esc or ESC, Ret or RET, Del
or DEL, etc.?

My keyboard has a key labeled "Esc", but presumably it
sends an ASCII ESC code.  I understand that my keyboard
key labeled doesn't send an ASCII TAB code, but Emacs
calls it <tab>, not <TAB>.

Something seems pretty arbitrary, here...  Hysterical
raisins or real logic?  Why is TAB the odd man out?

bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 10:22:13 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: drew.adams@oracle.com, npostavs@gmail.com, 12535@debbugs.gnu.org,
>         larsi@gnus.org
> 
> That's the point - why are we interpreting <TAB> as a
> function key

Because that's what <foo> means.

> Are you sure there are no keyboards, or there won't be any,
> that have a function key named Esc or ESC, Ret or RET, Del
> or DEL, etc.?

Yes.

> My keyboard has a key labeled "Esc", but presumably it
> sends an ASCII ESC code.  I understand that my keyboard
> key labeled doesn't send an ASCII TAB code, but Emacs
> calls it <tab>, not <TAB>.
> 
> Something seems pretty arbitrary, here...  Hysterical
> raisins or real logic?

It's how the GUI environments work.

> Why is TAB the odd man out?

It isn't.