* [2025-02-20 17:46 +0000] Ihor Radchenko <yanta...@posteo.net>:
> Phil Estival <p...@7d.nz> writes:
>
>>> whole line does not mean only background. It includes everything -
>>> underline as well. Background is just one example.
>>
>> It does because the variables are programmatically linked
>> [[file:~/.emacs.d/repos/org/lisp/org.el::5109]]
>> but natively no and that's fine, see the example below.
>
> I still do not see the connection.
>
>>>>> You are free to disable this custom option if you do not like it.
>>>>
>>>> The point is that I'm not free to do it the other way around: to disable
>>>> the extend option of a line -- in order to draw an underline only under
>>>> the text, not through the entire line, while the whole block
>>>> fontification is on, which otherwise, gets the fontification of the
>>>> block below past the text. When it's on, an underline will be
>>>> forcefully extended so there are only two options.
>>>
>>> So, do you mean that you want a new feature?
>>>
>>
>> In a way.
>>
>> This "mannerism in design" (and I am sorry because there are more
>> important matters) was proposed some time ago in this patch
>> https://list.orgmode.org/2b705b3c-3eec-c466-263b-1e3224f9e...@7d.nz/
>> Along a screenshot:
>> https://list.orgmode.org/2b705b3c-3eec-c466-263b-1e3224f9e...@7d.nz/2-org_src_block_2022-06-08.png
>> that we may reconsider again now
>>
>> If I understood well, this was before an attempt to give a tree-sitter
>> grammar to Org, the conclusion having been that Org was missing a formal
>> attribute to make this possible -- I don't remember which one and if you
>> refresh my memory I'll be thankful-- while a colleague of mine suggested
>> this could have proven ahead by formal language theory, but I digress.
>
> That's not about tree-sitter grammar. That's about using Org parser
> (org-element.el) for fontification. That effort is on hold due to lack
> of time but not forgotten.
>
>>> Sorry, but I am not sure what you are talking about.
>>> May you please show me steps starting from emacs -Q that demonstrate
>>> the problem?
>>
>> #+begin_src elisp
>> ;; This is meant to be evaluated one line at a time,
>> ;; and observe the result above
>> (set-face-attribute 'org-block nil :background "#DDDDDD")
>> (set-face-attribute 'org-block-begin-line nil :underline t)
>> (set-face-attribute 'org-block-begin-line nil :extend nil)
>> ;; desired result achieved
>>
>> (org-mode)
>> ;; last option overwritten
>> (face-attribute 'org-block-begin-line :extend)
>> ;; => t
>> #+end_src
>>
>> ;; Does
>> (setq org-fontify-whole-block-delimiter-line nil)
>> ;; achieves the desired effect?
>> (revert-buffer-quick)
>> ;; no, because block background now applies past
>> ;; #+begin_src elisp text.
>
> Does the attached diff fix the problem you are encountering?
Yes it does. Thank you!
But we are losing that previous possibility we had of a
bi-color display of meta lines, with the second part (past
the text of a meta line) being of the color of the block.
Maybe we can simplify a little the fontification of that
area now by replacing org-fontify-whole-block-delimiter-line
with the respective extend attribute instead and introducing
an other variable.
Line 5566 of org.el:
;; Fontify the #+begin and #+end lines of the blocks.
A quick reminder of the structure of a block to
understand what I'm saying next :
[[#+begin_src] [lang] [switches]][remainder of the line]
[block]
[#+end_src][remainder of the line]
1) Begin/end src have a face inheriting from org-meta-line.
They can extend all over the line.
2) A block fontification starts on the next line of
a begin declaration.
3) When a meta line is not extended, the remainder is either:
- not fontified (it has no text, it's a default face).
- or, optionally, it is fontified like a block.
This, without identifying if the block fontification
should starts right past the meta-line text or at eol,
but simply, when set and not extending, adding the
extra strike of marker along the line.
=> Introduces org-block-fontify-meta-line
(Non-nil means fontify past the text of begin/end
lines of blocks with the block face to give the
allure of a block covering those lines too.)
Adding a face for the remainder of the line would also
achieve the same result and even more for the area aspects.
To me it's fine in the current state. My proposals are only
meant for someone who would observe the change differently.
--
Phil
>
> diff --git a/lisp/org.el b/lisp/org.el
> index d012819a9c..bc4fb4ea04 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -5496,9 +5496,7 @@ (defun org-fontify-meta-lines-and-blocks-1 (limit)
> limit t)
> (let ((beg (match-beginning 0))
> (end-of-beginline (match-end 0))
> - ;; Including \n at end of #+begin line will include \n
> - ;; after the end of block content.
> - (block-start (match-end 0))
> + (block-start (1+ (match-end 0)))
> (block-end nil)
> (lang (match-string 7)) ; The language, if it is a source block.
> (bol-after-beginline (line-beginning-position 2))
