Jak odróżnić Ci od TAB?

20

Zwykle ze względów historycznych emacs traktuje TABkod i C-iklucz tak samo, por. dokumentacja emacs lisp na klawiszach funkcyjnych lub odpowiedź abo-abo na pytanie „Jaka jest różnica między TAB a?” .

UWAGA: W tym poście są kody klawiszy TAB, <tab>oraz C-i; tabi Ctrl+ iz drugiej strony są fizycznymi klawiszami na klawiaturze.

Jednak w tej chwili emacs traktuje to samo TABi C-ito samo, tj. (equal (kbd "TAB") (kbd "C-i"))-> t.

Ponieważ jednak nie żyjemy już w branży komputerowej, jest to niezwykle denerwujące. Istnieje kilka sugestii, które można zrobić, aby obejść ten problem, np

  • „Jak powiązać polecenie z Ci bez zmiany TAB?”

    • Rozwiązanie Treya nie działało dla mnie, zmienna local-function-key-mapssię nie zmienia. Zmodyfikowanie go w celu użycia deletezamiast delqskutkuje modyfikacją zmiennej, ale nie przynosi rozwiązania ... tabi Ctrl+ isą nadal takie same.
    • Tłumaczenie na hiper mapę wydaje się obejściem z lat 80. XX wieku ... Chciałbym również użyć Hyper+ i.
  • Użycie input-decode-mapmapowania Ctrl+ ido kodu sterującego post-ASCII jest prawie tym, czego szukam. Tyle że nie działa poprawnie z kbdmakrem, co oznacza, że ​​należy zmodyfikować wszystkie bity kodu źródłowego, które będą wiązały Ctrl+ i. Prawdopodobnie jest to najlepsze rozwiązanie, biorąc pod uwagę, że cały kod źródłowy jest odpowiednio zmodyfikowany.

  • Używanie (kbd "<tab>")for tabi (kbd "C-i")(co oznacza (kbd "TAB")np. \tDosłowność) dla Ctrl+ i działa, ale trzeba zmodyfikować wszystkie pliki źródłowe, które używają niewłaściwego rodzaju tab[Czytaj: kod klucza TAB], co jest denerwujące.
    Zasugerowano to np. W kwestii github i na emacs.sx .

Żadne z tych rozwiązań nie wydaje się prawdziwymi rozwiązaniami, wolę raczej rozważyć obejścia lub włamania (istniejącego błędu ).

Czy istnieje sposób, aby tam wymusić emacs mapować tabdo (kbd "<tab>")i (kbd "TAB")podczas Ctrl+ isą odwzorowywane na (kbd "C-i")krótki modyfing kod źródłowy emacs?

To podejście powinno być całkowicie niewidoczne dla użytkownika, co oznacza, że tabpodobne kody <tab>i TABpowinny być mapowane na jedno wiązanie, podczas gdy podobny kod Ctrl+ powinien być imapowany C-ina inne powiązanie.

Z mniej poważnej uwagi: czy są tu programiści emacsa, którzy mogą komentować, czy w pewnym momencie zostanie to zmienione / naprawione w kodzie źródłowym emacs?

elemakil
źródło
2
Zauważ, że TABi C-i(kody, nie klucze) są takie same z definicji TAB.
Stefan,
@Stefan Właśnie dlatego dodałem notatkę . Zamierzam edytować post i umieścić go tam.
elemakil
Możliwy duplikat Jak powiązać Ci jako inny niż TAB?
Gilles „SO- przestań być zły”
IMO to pytanie nie jest duplikatem, ponieważ chce przenieść wszystkie skróty klawiszowe zdefiniowane w TAB (nawet te z pakietów zewnętrznych), aby zamiast tego użyć <tab>. Podczas gdy inne pytanie dotyczyło sposobu ich rozróżnienia we własnym kodzie.
Malabarba
Moją sugestią byłoby zalecenie kbdprzetłumaczenia TAB jako [tab]. To po prostu nie zadziała dla wstępnie załadowanych części Emacsa.
Malabarba

Odpowiedzi:

21

Przyszłość już dawno minęła, a epoka kamienia komputerowego wkrótce nadejdzie. Wszystkie terminale tekstowe, które znam, wysyłają dokładnie tę samą sekwencję bajtów dla Emacsa, C-ico dla TAB, więc pierwotna potrzeba ich „unifikacji” wciąż jest bardzo ważna.

Mapa wejściowa dekodowania (à la (define-key input-decode-map "\C-i" [C-i])) jest prawdopodobnie tak dobra, jak teraz.

Jako były opiekun Emacsa z radością przyjmuję lepsze rozwiązanie tego problemu, aby zwolnić klucze C-i( C-mi C-[) w GUI (prawdopodobnie uczynią je „zarezerwowanymi dla użytkownika”). Ale nie wiem, jak to zrobić bez powodowania wielu problemów z istniejącymi pakietami.

Stefan
źródło
Nadeszła epoka brązu, ale jak dotąd tylko w Xtermie
Gilles „SO- przestań być zły”
Zastanawiasz się, jakiego rodzaju klawiatur używasz? W przypadku typowych klawiatur QWERT rozróżnienie jest po prostu pozorne, a niemożność rozróżnienia tych klawiszy to taki ból ...
Ivan Huang