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 [thread overview]
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 --]
next prev parent reply other threads:[~2021-05-18 12:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 15:00 [PATCH] Fontification for inline src blocks 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
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
2021-11-21 14:09 ` Timothy
2021-11-22 11:52 ` Timothy
2021-11-22 12:23 ` Ihor Radchenko
2021-11-22 13:43 ` Timothy
2021-11-22 14:35 ` Ihor Radchenko
2021-11-22 14:37 ` Timothy
2021-11-23 13:30 ` Ihor Radchenko
2021-11-29 19:21 ` Timothy
2021-11-30 11:44 ` Timothy
2021-11-30 12:45 ` Sébastien Miquel
2021-11-30 12:46 ` Timothy
2021-11-30 12:21 ` Ihor Radchenko
2021-12-02 12:53 ` Eric S Fraga
2021-12-02 13:57 ` Faces for inline src blocks (was: [PATCH] Fontification for inline src blocks) Timothy
2021-12-02 15:52 ` Faces for inline src blocks Eric S Fraga
2021-12-02 15:56 ` Timothy
2021-12-02 16:15 ` Eric S Fraga
2021-11-23 10:45 ` [PATCH] Fontification " Vitaly Ankh
2021-11-23 13:45 ` Vitaly Ankh
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 \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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 read-only IMAP folder(s) and NNTP newsgroup(s).