come evitare che i volti sanguinino sulle aree circostanti del buffer?


20

D: Come posso evitare org-modeche le facce dei collegamenti scorrano nei ...caratteri di visualizzazione selettiva alla fine di un'intestazione piegata?

Questo è un segno di spunta visivo che mi fa diventare un po 'matto. Quando, in org-mode, un collegamento è l'ultima cosa su una linea, la faccia del collegamento sanguina nel ...segno che indica che l'intestazione è piegata. Se c'è, diciamo, uno spazio vuoto dopo il collegamento, non c'è sanguinamento.

Lo screenshot che ho pubblicato dimostra il problema. La linea tre è la linea problematica senza caratteri tra la fine del collegamento e la fine della linea, mentre la linea quattro mostra un collegamento, seguito da uno spazio:

strano comportamento del viso di collegamento

Prima di tutto, perché succede? Secondo, e più precisamente al punto, come posso farlo smettere?

AGGIORNAMENTO 1: come da commenti, pubblicati di seguito sono schermate del buffer con le intestazioni chiuse e aperte. Ho aperto Emacs senza file init (es. emacs -Q), requireD org-mode e ho aperto questo file di esempio. Quindi: non sembra essere qualcosa di strano nella mia configurazione.

Tutte le intestazioni sono chiuse: strana faccia di collegamento chiusa

Tutte le intestazioni sono aperte: strano link aperto

Il tema che stavo usando sopra è inkpot, anche se ho lo stesso problema quando utilizzo il tema solarizzato e il tema predefinito (come nei nuovi screenshot).

La versione di Emacs è 24.3.1. Ottengo gli stessi risultati quando uso la versione 7.9.3f dell'organizzazione (ovvero quella in bundle con quella versione di Emacs), così come la 8.3beta.

AGGIORNAMENTO 2: ecco un esempio minimo di lavoro in risposta a una richiesta di commento:

* here's a header with a [[~/somefile.txt][link at the end]]

  - This one's a problem
  - Interesting note:
    + put the cursor immediately *after* the *d* in "end" with the
      header closed/folded
      * the face no longer bleeds over into the dots
    + move the cursor anywhere else
      * the face bleeds over into the dots again

* here's another [[~/someotherfile.txt][go at it]]
  DEADLINE: <2014-10-26 Sun>

  - This one's also a problem

* here's another header with a [[~/anotherfile.txt][link followed by a space]] 

  - No bleed-over onto the dots with this one

1
Sto facendo fatica a riprodurlo su Emacs 24.3.1 e sulla modalità org che ne deriva. Anche con i passaggi di riproduzione che hai citato. Potresti mostrare il buffer raw in modalità org? (Detto questo, suppongo che sia un bug in modalità org. L'aggiunta di una nuova riga aiuta?)
aerique

Come su @aerique, non lo vedo qui. Quindi, forse questo dipende dalla versione di Emacs o da alcuni dettagli del buffer della modalità Org.
Stefan,

@Dan, per curiosità, quale tema stai usando?
Luca,

1
@Dan potresti fornire l'origine di un file org di esempio per il test?
Wilfred Hughes,

2
@Dan Posso riprodurlo su Emacs 24.4 con il file che hai fornito.
rekado,

Risposte:


10

Questo appare come un bug innescati da org-mode's org-activate-bracket-linksla funzione.

Ecco come appare questa funzione:

(defun org-activate-bracket-links (limit)
  "Run through the buffer and add overlays to bracketed links."
  (if (and (re-search-forward org-bracket-link-regexp limit t)
       (not (org-in-src-block-p)))
      (let* ((hl (org-match-string-no-properties 1))
         (help (concat "LINK: " (save-match-data (org-link-unescape hl))))
         (ip (org-maybe-intangible
          (list 'invisible 'org-link
            'keymap org-mouse-map 'mouse-face 'highlight
            'font-lock-multiline t 'help-echo help
            'htmlize-link `(:uri ,hl))))
         (Vp (list 'keymap org-mouse-map 'mouse-face 'highlight
               'font-lock-multiline t 'help-echo help
               'htmlize-link `(:uri ,hl))))
    ;; We need to remove the invisible property here.  Table narrowing
    ;; may have made some of this invisible.
    (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
    (remove-text-properties (match-beginning 0) (match-end 0)
                '(invisible nil))
    (if (match-end 3)
        (progn
          (add-text-properties (match-beginning 0) (match-beginning 3) ip)
          (org-rear-nonsticky-at (match-beginning 3))
          (add-text-properties (match-beginning 3) (match-end 3) vp)
          (org-rear-nonsticky-at (match-end 3))
          (add-text-properties (match-end 3) (match-end 0) ip)
          (org-rear-nonsticky-at (match-end 0)))
      (add-text-properties (match-beginning 0) (match-beginning 1) ip)
      (org-rear-nonsticky-at (match-beginning 1))
      (add-text-properties (match-beginning 1) (match-end 1) vp)
      (org-rear-nonsticky-at (match-end 1))
      (add-text-properties (match-end 1) (match-end 0) ip)
      (org-rear-nonsticky-at (match-end 0)))
    t)))

Cerca una corrispondenza per un collegamento tra parentesi (ad esempio [[target][label]], nasconde la [[target][parte aggiungendola ipalle proprietà del testo, quindi collega la labelaggiungendo vpalle proprietà del testo e infine rimuove il finale ]]aggiungendo ipnuovamente alle proprietà del testo.

Sembra tutto a posto. org-rear-nonsticky-atdovrebbe occuparsi del sanguinamento delle proprietà.

Questo comportamento è attivato da (add-text-properties (match-end 3) (match-end 0) ip), che nasconde il trailing ]]. Solo la 'invisible 'org-linkproprietà attiva questo comportamento, le altre proprietà sembrano innocenti.

È possibile sovrascrivere in modo org-activate-bracket-linkstale che ipnon sia più impostato 'invisiblema 'display ""che abbia lo stesso effetto:

(defun org-activate-bracket-links (limit)
  "Run through the buffer and add overlays to bracketed links."
  (if (and (re-search-forward org-bracket-link-regexp limit t)
       (not (org-in-src-block-p)))
      (let* ((hl (org-match-string-no-properties 1))
         (help (concat "LINK: " (save-match-data (org-link-unescape hl))))
         (ip (org-maybe-intangible
          (list 'display ""
            'keymap org-mouse-map 'mouse-face 'highlight
            'font-lock-multiline t 'help-echo help
            'htmlize-link `(:uri ,hl))))
         (Vp (list 'keymap org-mouse-map 'mouse-face 'highlight
               'font-lock-multiline t 'help-echo help
               'htmlize-link `(:uri ,hl))))
    ;; We need to remove the invisible property here.  Table narrowing
    ;; may have made some of this invisible.
    (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
    (remove-text-properties (match-beginning 0) (match-end 0)
                '(invisible nil))
    (if (match-end 3)
        (progn
          (add-text-properties (match-beginning 0) (match-beginning 3) ip)
          (org-rear-nonsticky-at (match-beginning 3))
          (add-text-properties (match-beginning 3) (match-end 3) vp)
          (org-rear-nonsticky-at (match-end 3))
          (add-text-properties (match-end 3) (match-end 0) ip)
          (org-rear-nonsticky-at (match-end 0)))
      (add-text-properties (match-beginning 0) (match-beginning 1) ip)
      (org-rear-nonsticky-at (match-beginning 1))
      (add-text-properties (match-beginning 1) (match-end 1) vp)
      (org-rear-nonsticky-at (match-end 1))
      (add-text-properties (match-end 1) (match-end 0) ip)
      (org-rear-nonsticky-at (match-end 0)))
    t)))

Chiaramente, questo è un brutto trucco. Ma funziona per me e potrebbe funzionare per te. Consiglio comunque di presentare una segnalazione di bug.


Grazie per lo sforzo (+1 per quello!), Ma questa soluzione non funziona per me. Piuttosto che appropriatamente [[~/somefile.txt][link label]]come link label(dove il corsivo indica la faccia standard per il collegamento), diventa link label]](senza cambiare faccia). Presenterò una segnalazione di bug.
Dan

Hmm, strano. L'unica modifica nella mia definizione di org-activate-bracket-linksè la sostituzione 'invisible non-nilcon 'display "", quindi dovrebbe comunque applicare la faccia del collegamento come prima. Funziona sicuramente per me in Emacs 24.4, ma suppongo che l'energia sia meglio spesa per la segnalazione dei bug piuttosto che cercare di far funzionare il mio hack ... :)
rekado,
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.