• Key binding question

    From cjsmall@21:1/5 to All on Wed Oct 12 10:26:31 2022
    In my .muttrc file I have the following:

    #------------------------------------------------------------------------------ # attach key bindings #------------------------------------------------------------------------------ bind attach g first-entry # g Key
    bind attach q exit # q Key
    bind attach v exit # v Key
    bind attach <esc>[42~ exit # Keypad 5 Key
    bind attach <esc>[45~ exit # Keypad 8 Key
    bind attach <esc>[46~ exit # Keypad 9 Key
    bind attach <esc>Om exit # Keypad - Key
    bind attach <esc>Ok exit # Keypad + Key
    bind attach <esc>OM exit # Keypad Enter Key

    When reading an email and entering the attachments menu,
    I can exit with KP5, KP8, and KP9, but the keypad -, + and Enter
    keys do not work. I verify in the editor that all keys are issuing the specified escape codes. When in the attachment menu, "?" shows
    that all binding are proper assigned.

    Any clue as to why the first three bindings work but last three don't?
    I'm now on Xubuntu 22.04.1 with mutt 2.1.4, the latest package in the repository.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Doctor@21:1/5 to jefferysmall@gmail.com on Wed Oct 12 21:59:37 2022
    In article <265d30e1-4b61-403f-9efd-69e3211b5432n@googlegroups.com>,
    cjsmall <jefferysmall@gmail.com> wrote:
    In my .muttrc file I have the following:

    #------------------------------------------------------------------------------
    # attach key bindings >#------------------------------------------------------------------------------
    bind attach g first-entry # g Key
    bind attach q exit # q Key
    bind attach v exit # v Key
    bind attach <esc>[42~ exit # Keypad 5 Key
    bind attach <esc>[45~ exit # Keypad 8 Key
    bind attach <esc>[46~ exit # Keypad 9 Key
    bind attach <esc>Om exit # Keypad - Key
    bind attach <esc>Ok exit # Keypad + Key
    bind attach <esc>OM exit # Keypad Enter Key

    When reading an email and entering the attachments menu,
    I can exit with KP5, KP8, and KP9, but the keypad -, + and Enter
    keys do not work. I verify in the editor that all keys are issuing the >specified escape codes. When in the attachment menu, "?" shows
    that all binding are proper assigned.

    Any clue as to why the first three bindings work but last three don't?
    I'm now on Xubuntu 22.04.1 with mutt 2.1.4, the latest package in the >repository.

    FWIW

    g is group reply

    q is quit

    v is a verbose breakdown of your e-mail.
    --
    Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
    Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Why are so many happy only when controlling others? -unknown Beware https://mindspring.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tavis Ormandy@21:1/5 to cjsmall on Thu Oct 13 21:49:08 2022
    On 2022-10-12, cjsmall wrote:
    Any clue as to why the first three bindings work but last three don't?
    I'm now on Xubuntu 22.04.1 with mutt 2.1.4, the latest package in the repository.

    No, it seems okay to me and works fine here. I guess one possibility is
    you have Num Lock on, which changes what input the key generates?

    If that's the case, I guess just adding a binding for + and - might
    work.

    Tavis.


    --
    _o) $ lynx lock.cmpxchg8b.com
    /\\ _o) _o) $ finger taviso@sdf.org
    _\_V _( ) _( ) @taviso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to Tavis Ormandy on Thu Oct 13 17:47:27 2022
    On Thursday, October 13, 2022 at 2:49:10 PM UTC-7, Tavis Ormandy wrote:
    No, it seems okay to me and works fine here. I guess one possibility is
    you have Num Lock on, which changes what input the key generates?

    If that's the case, I guess just adding a binding for + and - might
    work.

    That was a good guess Tavis. Although the Num Locks key is not on, I
    already tried exactly what you suggested and it made no difference. :-(
    When I press these keys, mutt says "Key is not bound. Press '?' for help."
    The same thing is reported for other areas of mutt. It's as if these keys
    are not being recognized by mutt, even though they work elsewhere.

    I know that these bindings worked previously. I just upgraded from
    Xubuntu 20.04 to 22.04.1 and, once again, a raft of things have changed
    which are difficult to pin down. My keypad mappings in the vim editor
    and for the less pager continue to work just fine.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tavis Ormandy@21:1/5 to cjsmall on Fri Oct 14 01:36:56 2022
    On 2022-10-14, cjsmall wrote:
    On Thursday, October 13, 2022 at 2:49:10 PM UTC-7, Tavis Ormandy wrote:
    No, it seems okay to me and works fine here. I guess one possibility is
    you have Num Lock on, which changes what input the key generates?


    That was a good guess Tavis. Although the Num Locks key is not on, I
    already tried exactly what you suggested and it made no difference. :-(
    When I press these keys, mutt says "Key is not bound. Press '?' for help." The same thing is reported for other areas of mutt. It's as if these keys are not being recognized by mutt, even though they work elsewhere.

    Hmm, I would try binding something to what-key, then pressing +. I think
    it will only recognize the last character, but you can check if that
    matches at least!

    Tavis.

    --
    _o) $ lynx lock.cmpxchg8b.com
    /\\ _o) _o) $ finger taviso@sdf.org
    _\_V _( ) _( ) @taviso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to All on Thu Oct 27 14:06:44 2022
    On Thursday, October 13, 2022 at 2:49:10 PM UTC-7, Tavis Ormandy wrote:
    No, it seems okay to me and works fine here. I guess one possibility is
    you have Num Lock on, which changes what input the key generates?

    That was a good guess Tavis. Although the Num Locks key is not on, I already tried exactly what you suggested and it made no difference. :-( When I press these keys, mutt says "Key is not bound. Press '?' for help." The same thing is reported for other areas of mutt. It's as if these keys are not being recognized by mutt, even though they work elsewhere.

    Hmm, I would try binding something to what-key, then pressing +. I think
    it will only recognize the last character, but you can check if that
    matches at least!
    Tavis.

    Well, I spent quite a bit of time investigating the key bindings using the what-key feature, but there were no clues revealed. It all remains a
    mystery to me.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to All on Fri Oct 28 20:08:40 2022
    Since I was working on mutt macros, I thought I would take one more pass
    at the numeric keypad key binding problem.

    I used the <what-key> function to investigate various keys. It returned
    the same value for F1, and the keypad keys 0-9 and the period:

    Char = ~, Octal = 176, Decimal = 126

    What's up with that?

    In reality, each of these keys returns a different escape code sequence. Despite mutt not distinguishing between them, the following mappings in
    .muttrc work:

    bind pager <esc>[25~ previous-line # Keypad 0 Key
    bind pager <esc>[26~ previous-line # Keypad 1 Key
    bind pager <esc>[28~ bottom # Keypad 2 Key
    bind pager <esc>[31~ next-line # Keypad 3 Key
    bind pager <esc>[33~ previous-page # Keypad 4 Key
    bind pager <esc>[42~ exit # Keypad 5 Key
    bind pager <esc>[43~ next-page # Keypad 6 Key
    bind pager <esc>[44~ previous-entry # Keypad 7 Key
    bind pager <esc>[45~ exit # Keypad 8 Key
    bind pager <esc>[46~ next-entry # Keypad 9 Key
    bind pager <esc>[32~ next-line # Keypad . Key

    <what-key> returns this for the Num Lock key:

    Char = I, Octal = 111, Decimal = 73

    And is defined in .muttrc as:

    bind pager <esc>OI top # Keypad Num_Lock Key

    And it also works. Even though it reports the same octal value
    as the "I" key, it jumps to the first entry as expected while "I"
    does nothing.

    The remainder of the keypad keys do not work but <what-key>
    reports the following:

    / Char = A, Octal = 1101, Decimal = 577
    * Char = C, Octal = 1103, Decimal = 579
    - Char = D, Octal = 1104, Decimal = 580
    + Char = ?, Octal = 1077, Decimal = 575
    Enter Char = <Enter>, Octal = 527, Decimal = 343

    These keys issue the following escape codes:

    / <esc>Oo
    * <esc>Oj
    - <esc>Om
    + <esc>Ok
    Enter <esc>OM

    I even tried the following:

    bind pager \527 next-line # Keypad Enter Key

    but that didn't work. It still gets treated as the Enter/Return key.
    I know of no way to map a four digit octal key.

    So there it is. I don't know what is going on internally with the
    <what-key> function, but all these keypad mappings worked when
    I was back on Xubuntu 20.04 and stopped when moving to 22.04.1.
    There must be something fundamental happening a a lower
    system level that is affecting mutt but not showing up anywhere
    else.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tavis Ormandy@21:1/5 to cjsmall on Sat Oct 29 22:52:01 2022
    On 2022-10-29, cjsmall wrote:
    Since I was working on mutt macros, I thought I would take one more pass
    at the numeric keypad key binding problem.

    I used the <what-key> function to investigate various keys. It returned
    the same value for F1, and the keypad keys 0-9 and the period:

    Char = ~, Octal = 176, Decimal = 126

    What's up with that?

    It only knows about the last character of the sequence if it doesn't
    have a termcap name... but you're not pressing something unusual, so it
    should have a termcap name, it should say Char = <F1>.

    But... what terminal does F1 send something that ends with a ~? Is this rxvt?

    $ infocmp -1 rxvt | grep kf1=
    kf1=\E[11~,

    Is your $TERM definitely correct?

    Tavis.

    --
    _o) $ lynx lock.cmpxchg8b.com
    /\\ _o) _o) $ finger taviso@sdf.org
    _\_V _( ) _( ) @taviso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to Tavis Ormandy on Sun Oct 30 10:41:46 2022
    On Saturday, October 29, 2022 at 3:52:03 PM UTC-7, Tavis Ormandy wrote:
    On 2022-10-29, cjsmall wrote:
    Since I was working on mutt macros, I thought I would take one more pass
    at the numeric keypad key binding problem.

    I used the <what-key> function to investigate various keys. It returned
    the same value for F1, and the keypad keys 0-9 and the period:

    Char = ~, Octal = 176, Decimal = 126

    What's up with that?
    It only knows about the last character of the sequence if it doesn't
    have a termcap name... but you're not pressing something unusual, so it should have a termcap name, it should say Char = <F1>.

    Thanks for explaining that it only reports the last character. That helps.

    But... what terminal does F1 send something that ends with a ~? Is this rxvt?

    $ infocmp -1 rxvt | grep kf1=
    kf1=\E[11~,

    Is your $TERM definitely correct?

    I'm on Xubuntu using the xfce4-terminal. The proper setting for TERM is xterm-256color -- which I have.

    Regarding function keys, F2-F12 report, by what-key, as <F2> through <F12>
    but F1 differs from the terminfo entry. The key emits "<esc>[29~" while
    the terminfo entry is "kf1=\EOP". I don't use F1 in mutt and I always make my key mapping assignments using the actual escape code sequences rather
    than the terminfo codes, so it has not been a problem in vim or anywhere
    else. Everyone keeps trying to grab control of F1 for Help assignment. I wouldn't be surprised if the Xubuntu window system did something strange beneath the hood for F1.

    I just checked, and the definitions for the Keypad / * - + and Enter keys
    emit the same codes whether .Xdefault translations are defined or not. they are:

    / <esc>Oo
    * <esc>Oj
    - <esc>Om
    + <esc>Ok
    Enter <esc>OM

    The only key sequence defined in terminfo is:

    kent=\EOM

    which still doesn't explain why the following bindings do not work:

    bind generic <esc>Oo first-entry # Keypad / Key
    bind generic <esc>Oj last-entry # Keypad * Key
    bind generic <esc>Om select-entry # Keypad - Key
    bind generic <esc>Ok next-entry # Keypad + Key
    bind generic <esc>OM next-entry # Keypad Enter Key

    [Note: Enter acts as Return while the others are no-op]

    while these do work as defined:

    bind generic <esc>[25~ previous-entry # Keypad 0 Key
    bind generic <esc>[26~ previous-entry # Keypad 1 Key
    bind generic <esc>[28~ last-entry # Keypad 2 Key
    bind generic <esc>[31~ next-entry # Keypad 3 Key
    bind generic <esc>[33~ previous-entry # Keypad 4 Key
    bind generic <esc>[42~ select-entry # Keypad 5 Key
    bind generic <esc>[43~ next-entry # Keypad 6 Key
    bind generic <esc>[44~ previous-page # Keypad 7 Key
    bind generic <esc>[45~ first-entry # Keypad 8 Key
    bind generic <esc>[46~ next-page # Keypad 9 Key
    bind generic <esc>OI first-entry # Keypad Num_Lock Key
    bind generic <esc>[32~ next-entry # Keypad . Key

    If the problem had something to do with no left bracket after
    <esc> or ending in a letter rather than tilde, then the Num Lock
    key should also not work, but it does! And remember, these did
    once work just fine. :-(

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tavis Ormandy@21:1/5 to cjsmall on Sun Oct 30 21:15:13 2022
    On 2022-10-30, cjsmall wrote:
    Is your $TERM definitely correct?

    I'm on Xubuntu using the xfce4-terminal. The proper setting for TERM is xterm-256color -- which I have.

    Regarding function keys, F2-F12 report, by what-key, as <F2> through <F12> but F1 differs from the terminfo entry. The key emits "<esc>[29~" while
    the terminfo entry is "kf1=\EOP".

    I know you're not convinced, but I think this is a really good hint your
    $TERM is wrong! Although I can't find any terminal where f1 generates
    \E[29~, the closest I can find is xterm-color:

    $ infocmp -1 xterm-color | egrep '\\E\[29~,$'
    kf16=\E[29~,

    Does running TERM=xterm-color mutt change anything?

    Tavis.

    --
    _o) $ lynx lock.cmpxchg8b.com
    /\\ _o) _o) $ finger taviso@sdf.org
    _\_V _( ) _( ) @taviso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to Tavis Ormandy on Sun Oct 30 17:19:04 2022
    On Sunday, October 30, 2022 at 2:15:15 PM UTC-7, Tavis Ormandy wrote:
    Does running TERM=xterm-color mutt change anything?

    Well, that really doesn't work! Everything breaks including tab completion. Fore some reason, the xterm-color entry is really short:

    infocmp xterm-color
    # Reconstructed via infocmp from file: /lib/terminfo/x/xterm-color xterm-color|nxterm|generic color xterm,
    am, km, mir, msgr, xenl,
    colors#8, cols#80, it#8, lines#24, ncv@, pairs#64,
    acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, bold=\E[1m, clear=\E[H\E[2J, cr=\r,
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
    cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
    dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
    el=\E[K, enacs=\E)0, home=\E[H, ht=^I, hts=\EH, il=\E[%p1%dL,
    il1=\E[L, ind=\n,
    is2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8, kbs=^?,
    kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
    kdch1=\E[3~, kf1=\E[11~, kf10=\E[21~, kf11=\E[23~,
    kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
    kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
    kf2=\E[12~, kf20=\E[34~, kf3=\E[13~, kf4=\E[14~,
    kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
    kfnd=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
    kslt=\E[4~, meml=\El, memu=\Em, op=\E[m, rc=\E8, rev=\E[7m,
    ri=\EM, rmacs=^O, rmcup=\E[2J\E[?47l\E8, rmir=\E[4l,
    rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m,
    rs2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8, sc=\E7,
    setab=\E[4%p1%dm, setaf=\E[3%p1%dm, sgr0=\E[m, smacs=^N,
    smcup=\E7\E[?47h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
    smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
    u8=\E[?1;2c, u9=\E[c,

    compared to the xterm-256color entry:

    infocmp xterm-256color
    # Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color xterm-256color|xterm with 256 colors,
    am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
    colors#0x100, cols#80, it#8, lines#24, pairs#0x10000,
    acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
    clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
    cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
    cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
    dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
    el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
    hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
    il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
    initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
    invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
    kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
    kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw,
    ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs,
    kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
    kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
    kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
    kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
    kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
    kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
    kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
    kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
    kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
    kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
    kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
    kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
    kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
    kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
    kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
    kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
    kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
    kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
    kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
    kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~,
    kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
    memu=\Em, mgc=\E[?69l, nel=\EE, oc=\E]104\007,
    op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db,
    rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
    rmam=\E[?7l, rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l,
    rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
    rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
    setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
    setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
    sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
    sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
    smcup=\E[?1049h\E[22;0;0t, smglp=\E[?69h\E[%i%p1%ds,
    smglr=\E[?69h\E[%i%p1%d;%p2%ds,
    smgrp=\E[?69h\E[%i;%p1%ds, smir=\E[4h, smkx=\E[?1h\E=,
    smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
    u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
    u9=\E[c, vpa=\E[%i%p1%dd,

    In fact, the differences between the standard xterm and xterm-256color
    entries are very small:

    infocmp -d xterm xterm-256color
    comparing xterm to xterm-256color.
    comparing booleans.
    ccc: F:T.
    comparing numbers.
    colors: 8, 256.
    pairs: 64, 65536.
    comparing strings.
    initc: NULL, '\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\'.
    oc: NULL, '\E]104\007'.
    rs1: '\Ec', '\Ec\E]104\007'.
    setab: '\E[4%p1%dm', '\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m'.
    setaf: '\E[3%p1%dm', '\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m'.
    setb: '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
    setf: '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.

    so I still don't think that the problem is with the terminfo entry. it
    seems to me that mutt shouldn't care at all about the terminfo definitions
    if the bindings in .muttrc are explicit escape sequences. No?

    Sorry for the lengthy output, but I wanted to provide all the info so that
    it could be examined. And I do very much appreciate all of the help!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to All on Sat Nov 5 17:51:20 2022
    See thread for background: https://groups.google.com/g/comp.mail.mutt/c/0IJjSR-Syw4

    I know I'm kind of beating a dead horse here, but I am still curious to
    figure out just what is going on.

    After everything else failed, I played around with my .muttrc file,
    deleting everything else except the non-working entries just in case
    something else was interfering with the bindings, but even with just
    one key binding definition in the file, it still didn't work.

    I then tried making a custom terminfo entry that assigned the escape
    sequences to unused function key definitions, but that didn't help.

    I then realized that by holding the Alt key, these keypad keys issued
    different escape sequences as follows:

    Keypad Key Std Sequence Alt Sequence
    ------------------- ---------------------- ----------------------
    / \EOo \E03o
    * \EOj \EO3j
    - \EOm \EO3m
    + \EOk \EO3k
    Enter \EOM \EO3M

    So I defined these Alt-Key binding in .muttrc and tried things
    out. Using Alt with /, *, + and Enter worked as assigned. The
    minus (-) key still reports:"Key is not bound." just like all of
    the Std escape sequences.

    I don't believe I mentioned it before, but pressing ? and looking
    at the list of bound keys does show that all of these key sequences
    are indeed bound the proper actions or macros. It's just that
    mutt does bot recognize these bindings during operation.

    As I said, all of these binding did once work so it's not the
    definitions that are the problem, but something mutt is doing
    internally. Does any of this provide a clue?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cjsmall@21:1/5 to All on Sat Nov 5 18:52:49 2022
    One further thing regarding the failing key bindings, I just
    compiled and installed the new mutt version 2.2.8 released
    on 11-05-22 and nothing has improved regarding these bindings.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)