From: "Sébastien Miquel" <firstname.lastname@example.org> To: Timothy <email@example.com> Cc: org-mode-email <firstname.lastname@example.org> Subject: Re: [PATCH] Fontification for inline src blocks Date: Tue, 18 May 2021 12:06:46 +0000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> [-- 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 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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 read-only IMAP folder(s) and NNTP newsgroup(s).