From: Tim Cross <firstname.lastname@example.org> To: email@example.com Subject: Re: [PATCH] Fontification for inline src blocks Date: Thu, 13 May 2021 12:38:42 +1000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Timothy <firstname.lastname@example.org> writes: > Thank you for the detailed feedback :) > > Ihor Radchenko <email@example.com> writes: > >> Timothy <firstname.lastname@example.org> writes: >> >>>> I do not like abusing prettify-symbols-mode. What if it is not enabled? > > If you know of another way of accomplishing text-replacement which > changes back when the cursor enters the region, please let me know. > >>> Ah, it does it anyway at the moment. >> >> Hmm. You are right. You are calling compose-region directly. Note, that >> you do not add 'decompose-region function for automatic region >> destruction (see help:pretty-symbol-pattern-to-keyword). > > Isn't the same effect achieved by the remove-list-of-text-properties call? > >> If I understand correctly (I did not really install your patch), if you have >> composed region, disable font-lock, and try to edit the region, edits >> will be invisible. Or imagine setting org-inline-src-prettify-results to >> nil in already fontified buffer. > > I just tried "setting org-inline-src-prettify-results to nil in already > fontified buffer." and the region just decomposed and stayed that way. > >> Also, you may find help:font-lock-extra-managed-props useful. That way, >> you will not have to manually remove composition and other non-standard >> properties during fontification > > Hmmm, from a look I can't tell exactly how these are "managed". Are they > just removed when a region is processed? > >> why are you even removing 'face? It should be already done by font-lock). > > I tried removing such calls, and everything still worked, so this is no > longer done. > >>>> What will happen if user toggles prettify-symbols-mode in Org buffer? >>> >>> This seems to be toggled nicely by prettify-symbols-mode too. >> >> I would not expect it to. Why would prettify-symbols-mode interfere with >> Org mode native fontification if it is not strictly necessary? > > Well, I guess this is a by-product of using prettify-symbols-start/end, > see my note at the start of this email about not being aware of anything else. > >> P.S. Nitpick: You do not need to run fontification in while loops. Just >> fontifying next match before limit should be enough. Font-lock will call >> the function again if needed. > > I'm guessing for this to work I'd need to return the final char > fortified? Or is the moving of point enough? > > Maybe related - I've noticed this doesn't seem to work with multiple > src_ blocks per line, might you have any insight here? > > This may or may not be something to consider but ... What is the impact of using this technique for accessibility and users of assistive technology like text-to-speech or braille displays? I'm currently not in the position to test this patch, but once I get some environments for testing sorted out, I should be able to try it out. From an accessibility perspective, behaviour which changes what is 'displayed' based on cursor position is often confusing for things like text-to-speech. In the past, I have run into issues with prettify symbols because it results in either less meaningful content (e.g. unicode numbers rather than defined character names) or additional spoken text which makes it difficult to understand. Things like overlays, tooltips or features which make display different from underlying character content can often be problematic with assistive technology. -- Tim Cross
next prev parent reply other threads:[~2021-05-13 2:53 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-31 15:00 Timothy 2021-04-28 7:14 ` Timothy 2021-05-02 20:17 ` Timothy 2021-05-02 20:57 ` Tom Gillespie 2021-05-02 21:03 ` Timothy 2021-05-02 21:13 ` Tom Gillespie 2021-05-02 23:54 ` Tom Gillespie 2021-05-03 3:29 ` Timothy 2021-05-12 11:15 ` Timothy 2021-05-12 14:24 ` Ihor Radchenko 2021-05-12 14:47 ` Timothy 2021-05-12 15:53 ` Ihor Radchenko 2021-05-12 16:39 ` Timothy 2021-05-13 2:38 ` Tim Cross [this message] 2021-05-13 5:31 ` Ihor Radchenko 2021-05-18 12:06 ` Sébastien Miquel 2021-05-18 13:34 ` Timothy 2021-05-18 14:36 ` Sébastien Miquel 2021-04-29 22:59 ` TRS-80 2021-10-03 7:14 ` Ihor Radchenko 2021-10-03 7:16 ` Timothy 2021-10-03 9:09 ` Ihor Radchenko 2021-10-03 9:22 ` Timothy 2021-10-04 20:02 ` Protesilaos Stavrou
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] Fontification for inline src blocks' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).