Org-mode mailing list
 help / color / mirror / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Fontification for inline src blocks
Date: Thu, 13 May 2021 12:38:42 +1000
Message-ID: <87y2cjwdj1.fsf@gmail.com> (raw)
In-Reply-To: <87cztv29ff.fsf@gmail.com>


Timothy <tecosaur@gmail.com> writes:

> Thank you for the detailed feedback :)
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Timothy <tecosaur@gmail.com> 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


  reply	other threads:[~2021-05-13  2:53 UTC|newest]

Thread overview: 19+ 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

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://orgmode.org

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2cjwdj1.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://orgmode.org/list/0 list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ https://orgmode.org/list \
		emacs-orgmode@gnu.org
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git