Org-mode mailing list
 help / color / mirror / Atom feed
From: "Sébastien Miquel" <sebastien.miquel@posteo.eu>
To: Timothy <tecosaur@gmail.com>
Cc: org-mode-email <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Fontification for inline src blocks
Date: Tue, 18 May 2021 12:06:46 +0000
Message-ID: <cb93f6d8-956a-bc03-2e90-f97390e24585@posteo.eu> (raw)
In-Reply-To: <87cztv29ff.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]

Hi Timothy,

Thanks for your work. I hope this can be merged.

Here are a few comments.

Doesn't this line in ~org-toggle-inline-results-display~ throw the
configured delimiters away when called twice ?
: (setq org-inline-src-prettify-results (not 
org-inline-src-prettify-results))

I think the =org-block= face should only be applied to the actual
code, note the =src_lang= part, nor the result. For normal src blocks,
it is only used inside the block.

The ~org-src-font-lock-fontify-block~ function could be modified to
take an optional =inline= argument. When =t=, it should not set the
=multiline= font property. Although this is very minor, it would allow
one to easily advice this function to behave differently in inline src
blocks. For example, to not use the =org-block= face in this case.

I think the default parenthesis pair around results are bad. I much
preferred your original brackets. Yes, as Tom said, they look alien,
but alien is appropriate for use of ~prettify-symbols~.

Since ~prettify-symbols~ seems to be raising some usability concerns,
perhaps ~org-inline-src-prettify-results~ should default to ~nil~.
It'd be unlike org to hide things from the user in the default
configuration.

As Tom points out, the two faces used (for the =src_= and bracket and
the language part) should be customizable. The default value you chose
are fine IMO. Perhaps the language one could also be used to highlight
the language of normal src blocks, though It might be easier to use a
single face.

Timothy writes:
>> 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?

You need only return =t= if some fontification has been done (and set
point after the fontified part). If your function returns =t=, it will
be called again.

A case can be made for keeping the loop though. It works fine and is
clearer since the aforementioned fontlock behaviour is poorly
documented. Really, the only downside is the loss of consistency, since
the function ~org-fontify-meta-lines-and-blocks-1~ doesn't loop.

Regards,

-- 
Sébastien Miquel


[-- Attachment #2: Type: text/html, Size: 3514 bytes --]

  parent reply	other threads:[~2021-05-18 12:14 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
2021-05-13  5:31                   ` Ihor Radchenko
2021-05-18 12:06                   ` Sébastien Miquel [this message]
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=cb93f6d8-956a-bc03-2e90-f97390e24585@posteo.eu \
    --to=sebastien.miquel@posteo.eu \
    --cc=emacs-orgmode@gnu.org \
    --cc=tecosaur@gmail.com \
    /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