Hi Eric,
> However, I am finding the result not very pleasing unfortunately.
> Specifically, I am not happy with the use of other pre-existing faces
> (shadow and org-meta-line) for this purpose. These other faces have
> their specific uses and the resulting combination for inline src blocks,
> f
Timothy,
I am happy to see the fontification of inline src blocks in org. Thank
you!
However, I am finding the result not very pleasing unfortunately.
Specifically, I am not happy with the use of other pre-existing faces
(shadow and org-meta-line) for this purpose. These other faces have
their
Hi Sebastien,
> Sorry for the late reply, but isn’t there a `message' call leftover from
> debugging ?
Ooops! Time for a clean-up patch to fix the things you and Ihor’s just noticed.
Thanks for mentioning this.
All the best,
Timothy
Hi,
Timothy writes:
Pushed 🙂.
Sorry for the late reply, but isn't there a =message= call leftover from
debugging ?
Regards,
--
Sébastien Miquel
Timothy writes:
>>> [use org-element]
>
> Ah right. We now also have the new thread about using org-element. I think
> that
> sounds like a great change overall, but am still keen for this patch to go
> through for the moment — just as a stop gap till org-element exposes all the
> necessary info
Pushed 🙂.
All the best,
Timothy
Hi Ihor,
> That’s an option. Though you should also consider a paragraph ending at
> EOB. Searching for “” will fail with error then.
Don’t worry, that’s just a snippet. The full logic is as follows
┌
│ (min limit (or (save-excursion (and (search-forward "\n" limit t 2) (point)))
│
Hi Timothy,
Sorry for my stupid question. I have figured out the problem is not
relevant to
your work and I have fixed it. I'm really looking forward to your org-mode
asynchronous fragment compilation.
All the best,
VitalyR
On Tue, Nov 23, 2021 at 6:45 PM Vitaly Ankh wrote:
>
> Hi Timothy,
>
Timothy writes:
>> I can see the purpose. However, it still looks like overcomplication.
>> org-element-context takes care about this issue simply by narrowing to
>> current element (inline src block is an object and hence must end within
>> current element).
>
> Well, one simple change we could
Hi Ihor,
org-inline-src-fontify-max-length
>> The description may need updating, as that’s a tad inaccurate. That value
>> actually limits how far forwards a paired paren is searched for. There’s no
>> spurious fontification.
>
> I can see the purpose. However, it still looks like overcomplic
Timothy writes:
>> I have some comments. See below.
>
> Thanks for going through this, and for all your help previously.
> I appreciate it :)
Welcome.
>>> (org-inline-src-fontify-max-length): Create a variable to limit the
>>> maximum length of an inline-src block fontified, to protect from lag
Hi Ihor,
> I have some comments. See below.
Thanks for going through this, and for all your help previously.
I appreciate it :)
>> (org-inline-src-fontify-max-length): Create a variable to limit the
>> maximum length of an inline-src block fontified, to protect from lag
>> spikes (e.g. when typi
Timothy writes:
> See attached for a patch which just adds this face. I feel like this might be
> the final version of this patch so I’d appreciate thoughts on this.
I have some comments. See below.
> (org-inline-src-fontify-max-length): Create a variable to limit the
> maximum length of an inl
Hi Everyone,
I think there’s room in the future to add more faces for this, but I it occurs
to me that the main complaint raised in this thread can be resolved by adding
one new face: `org-inline-src-block' (which inherits from `org-block') by
default.
See attached for a patch which just adds th
Hi All,
Since the contentious component of my previous patches has been the
`{{{results()}}}' prettification, I’ve prepared an alternate version that I’m
hoping everybody will be fairly happy with (fingers crossed!) that tosses out
the results prettification for now.
I think Protesilaos’ comments
On 2021-10-03, 17:09 +0800, Ihor Radchenko wrote:
> Timothy writes:
>
>> Ihor Radchenko writes:
>>
>>> Let me bump this thread again and mark it as a patch ;)
>>
>> Thanks for the bump. I'd like to get this working, but I don't know how best
>> to
>> deal with the "prettification" of {{{result
Hi Ihor,
> What about separating the src_{nil} fontification into separate patch? I
> think that part raised no objections.
That sounds like a good idea to me. We may as well get that in.
> As for the results prettifications, I look at this and similar ideas as
> at Emacs themes. It looks nice
Timothy writes:
> Ihor Radchenko writes:
>
>> Let me bump this thread again and mark it as a patch ;)
>
> Thanks for the bump. I'd like to get this working, but I don't know how best
> to
> deal with the "prettification" of {{{results(=value=)}}}, which is the major
> blocker as I
> see it.
W
Ihor Radchenko writes:
> Let me bump this thread again and mark it as a patch ;)
Thanks for the bump. I'd like to get this working, but I don't know how best to
deal with the "prettification" of {{{results(=value=)}}}, which is the major
blocker as I
see it.
Other than that, this all works f
Timothy writes:
> Hi All,
>
> I've been using inline src blocks a fair bit more recently, and I've
> thought it's a pity how bad they look as they are currently without
> fontification. A little digging into Org internals and font-lock later
> and we have this patch. I could speak about what's be
Timothy writes:
In src blocks, you have the org-block-begin-line face applied. This (in
any sensible theme) has the same background as org-block.
I might be confused by my own config, but that doesn't seem to be the
case. Unless customized, the =org-block-begin-line= inherits from
org-meta-lin
Hi Sébastien, thanks for your comments.
Sébastien Miquel writes:
> 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 o
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 =
Timothy 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.
cursor-sensor-mode
>>> Ah, it does it anyway at the moment.
>
Timothy writes:
> Thank you for the detailed feedback :)
>
> Ihor Radchenko writes:
>
>> Timothy 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
Thank you for the detailed feedback :)
Ihor Radchenko writes:
> Timothy 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.
Timothy writes:
>> I do not like abusing prettify-symbols-mode. What if it is not enabled?
>
> 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-
Thanks for your response.
Ihor Radchenko writes:
> I do not like abusing prettify-symbols-mode. What if it is not enabled?
Ah, it does it anyway at the moment.
> What will happen if user toggles prettify-symbols-mode in Org buffer?
This seems to be toggled nicely by prettify-symbols-mode to
Timothy writes:
> If anyone else is interested in this, it would be great to get your
> thoughts.
I do not like abusing prettify-symbols-mode. What if it is not enabled?
What will happen if user toggles prettify-symbols-mode in Org buffer?
Maybe better use something like org-entities?
Best,
Iho
If anyone else is interested in this, it would be great to get your
thoughts.
I'd also appreciate it if a core maintainer might be able to find the
time to review the patch and let me know if it looks good.
Thanks,
Timothy.
--
> Tom Gillespie writes:
>
>> 1. I think there needs to be a func
Tom Gillespie writes:
> 1. I think there needs to be a function to toggle
> org-inline-src-prettify-results as there is e.g. for hyperlinks. I was
> quite confused by the prettified results.
Added org-toggle-inline-results-display.
> 3. I'm not sure about the default choice for prettified deli
Hi Timothy,
Another thought about this. In some languages (e.g. python) blocks
require an explicit return by default. It would be nice to be able to
set header arguments in the property drawer separately for inline
source blocks in such cases.
src_python[:prologue "x = (" :epilogue ")\nreturn
> I see. I imagine the expected behaviour of such a function would be to
> toggle org-inline-src-prettify-results and redisplay?
Yeah, see org-toggle-link-display for inspiration I think.
;;;###autoload
(defun org-toggle-link-display ()
"Toggle the literal or descriptive display of links."
(i
Thanks for trying this!
Tom Gillespie writes:
> Hi Timothy,
>It seems to work more or less as expected. A few comments below. Best,
> Tom
>
> 1. I think there needs to be a function to toggle
> org-inline-src-prettify-results as there is e.g. for hyperlinks. I was
> quite confused by the p
Hi Timothy,
It seems to work more or less as expected. A few comments below. Best,
Tom
1. I think there needs to be a function to toggle
org-inline-src-prettify-results as there is e.g. for hyperlinks. I was
quite confused by the prettified results.
2. I'm also not sure that this approach to p
It would be good to hear if anyone has been able to test this, and if so
what your experience has been :)
--
Timothy
On 2021-03-31 11:00, Timothy wrote:
I've been using inline src blocks a fair bit more recently, and I've
thought it's a pity how bad they look as they are currently without
fontification. A little digging into Org internals and font-lock later
and we have this patch.
I recall trying inline src
Timothy writes:
> Hi All,
>
> I've been using inline src blocks a fair bit more recently, and I've
> thought it's a pity how bad they look as they are currently without
> fontification. A little digging into Org internals and font-lock later
> and we have this patch. I could speak about what's
38 matches
Mail list logo
