Come distinguere Ci da TAB?

Normalmente, per ragioni storiche, emacs tratta il TABcodice C-ichiave e la chiave come gli stessi, cfr. la documentazione emacs lisp sui tasti funzione o la risposta di abo-abo sulla domanda "Qual è la differenza tra TAB e?" .

NOTA: In questo post, keycodes sono TAB, <tab>e C-i; tabe Ctrl+ id'altra parte sono i tasti fisici sulla tastiera.

Tuttavia, al momento, emacs considera la TABe C-icome la stessa cosa, ovvero (equal (kbd "TAB") (kbd "C-i"))-> t.

Tuttavia, dal momento che non viviamo più nello stoneage dell'informatica, lo trovo estremamente fastidioso. Ci sono alcuni suggerimenti là fuori che cosa si può fare per ovviare a questo, ad es

• "Come associare un comando a Ci senza cambiare TAB?"

  • La soluzione di Trey non ha funzionato per me, la variabile local-function-key-mapsnon è cambiata. Modificarlo per usarlo deletepiuttosto che delqprovocare una variabile modificata, ma non porta risoluzione ... tabe Ctrl+ isono sempre gli stessi.
  • La traduzione nell'hyper map sembra una soluzione alternativa degli anni '80 ... Potrei voler usare anche Hyper+ i.

• Usare il input-decode-mapto map Ctrl+ isu un codice di controllo post-ASCII è quasi quello che sto cercando. Tranne il fatto che non funziona correttamente con la kbdmacro, il che significa che è necessario modificare tutti i bit del codice sorgente che assocerà Ctrl+ i. Probabilmente questa è la soluzione migliore dato che tutto il codice sorgente viene modificato correttamente.

• Utilizzando (kbd "<tab>")per la tabe (kbd "C-i")(che si traduce in (kbd "TAB")cioè il \tletterale) per Ctrl+ i funziona , ma che avrebbe dovuto modificare tutti i file di origine che utilizzano il tipo sbagliato di tab[Read: il codice chiave TAB] che è fastidioso.
  Questo è stato suggerito ad esempio in un problema con github e anche su emacs.sx .

Nessuna di queste soluzioni sembra soluzioni reali, preferirei considerarle soluzioni alternative o hack (del bug esistente ).

C'è una via d'uscita lì per forzare emacs per mappare tabad (kbd "<tab>")e (kbd "TAB")mentre Ctrl+ iè mappata a (kbd "C-i")corto di modyfing il codice sorgente di emacs?

Questo approccio dovrebbe essere completamente invisibile per l'utente, il che significa che il tabcome keycodes <tab>e TABdevono mappare un legame, mentre il Ctrl+ icome codice chiave C-idovrebbe mapping a un altro legame.

Su una nota meno seria: Qualche sviluppatore di emacs qui che può commentare se questo sarà cambiato / riparato nel codice sorgente di emacs ad un certo punto?

Il futuro è ormai passato e l'era della pietra dell'informatica sta per arrivare. Tutti i terminali di testo che conosco inviano ancora la stessa sequenza di byte a Emacs per C-iquanto a TAB, quindi la necessità originale di "unificarli" è ancora molto con noi.

La mappa di input-decodifica (à la (define-key input-decode-map "\C-i" [C-i])) è probabilmente buona come quella attuale.

Come Emacs ex-maintainer, sarei il benvenuto una soluzione migliore a questo problema, in modo da liberare le C-i(e C-me C-[chiavi) sotto GUI (probabilmente li rendono "riservati per l'utente"). Ma non so come farlo senza causare molti problemi con i pacchetti esistenti.