Come distinguere Ci da TAB?


20

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?


2
Si noti che TABe C-i(i codici, non le chiavi) sono la stessa cosa per definizione di TAB.
Stefan,

@Stefan Ecco perché ho aggiunto la nota . Ho intenzione di modificare il post e inserirlo.
elemakil,


IMO, questa domanda non è un duplicato, perché vuole riposizionare tutte le combinazioni di tasti definite su TAB (anche quelle da pacchetti esterni), per usare invece <tab>. Mentre l'altra domanda era chiedersi come differenziarli nel proprio codice.
Malabarba,

Il mio suggerimento sarebbe di consigliare kbddi tradurre TAB come [tab]. Semplicemente non funzionerà per le parti precaricate di Emacs.
Malabarba,

Risposte:


21

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.



Ti chiedi che tipo di tastiere usi? Con le tipiche tastiere QWERT la distinzione è appena evidente, e non riuscire a distinguere questi tasti è un tale dolore ...
Ivan Huang
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.