[BUG] unfolding headlines with :extend face keyword & background broke after 2da622cad [9.7 (9.7-??-8ac99c33f @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

[StrawberryTea]

Hi, using the following test case with Emacs -Q:

(let ((default-directory (file-name-directory load-file-name)))
  (when (file-exists-p (expand-file-name "default.el" default-directory))
(load-file (expand-file-name "default.el" default-directory

(straight-use-package 'org)

(require 'org)
(load-theme 'leuven t)

(dolist (face '(org-level-1 org-level-2 org-level-3 org-level-4 org-level-5
org-level-6 org-level-7 org-level-8))
  (set-face-attribute face nil :extend t))

(setq org-fontify-whole-heading-line t)
(setq org-startup-folded t)

(defvar org-extend-faces-bug-4-file "/tmp/org-extend-faces-bug-4.org"
  "The file to be used for the bug demo.")

(with-temp-buffer
  (insert "* foo\n** bar\ntest\n** baz\ntest")
  (write-file org-extend-faces-bug-4-file))

(find-file org-extend-faces-bug-4-file)

The most recent fix for the bug in 2da622cad seems to have made things
worse. Now sometimes the background of the headline is not extended and
other times we still have the trailing background color where it's not
supposed to. It's definitely a lot worse when the file is started up
folded because the issue seems to be specifically related with unfolding
a heading with subheadings.

StrawberryTea <

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.18.0)
 of 2024-03-04
Package: Org mode version 9.7 (9.7-??-8ac99c33f @ 
/home/st/.config/emacs/.local/straight/build-30.0.50/org/)

[tip] Export to PDF with latexmk 'continuous preview' option

[Juan Manuel Macías]

A little-known (and sometimes very useful) latexmk option is the -pvc
option. According to the latexmk manual:

  [...] The second previewing option is the powerful -pvc option
  (mnemonic: "preview continuously"). In this case, latexmk
  runs continuously, regularly monitoring all the source files
  to see if any have changed. Every time a change is detected,
  latexmk runs all the programs necessary to generate a new
  version of the document. A good previewer will then
  automatically update its display. Thus the user can simply
  edit a file and, when the changes are written to disk,
  latexmk completely automates the cycle of updating the .dvi
  (and/or the .ps and .pdf) file, and refreshing the
  previewer's display. It's not quite WYSIWYG, but usefully
  close.

In order to use this option from Org, I have defined a simple minor mode
that runs latexmk with the -pvc option and creates a buffer to monitor
the process. Every time the document, or any file involved, is saved,
the PDF is updated. We can define in our `latexmkrc' our favorite
external PDF viewer (Atril, Okular, Evince, etc.). I have this line:

┌
│ $pdf_previewer = "atril %O %S > /dev/null 2>&1 &";
└

And here's the code (for documents that are long, complex, or take a
while to export, it may be better to use the asynchronous version of
`org-latex-export-to-latex'):

┌
│ (defun my-org-compile-latexmk-interactive ()
│   (let* ((tex-file (org-export-output-file-name ".tex")))
│ (start-process-shell-command
│  "latexmk"
│  (format "*%s-latexmk-process*" (file-name-sans-extension tex-file))
│  (concat
│   "latexmk -f -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape 
%S/' "
│   tex-file
│
│ (define-minor-mode org-interactive-compile-pdf-mode
│   "TODO"
│   :lighter " OrgInteractivePDF"
│   (if org-interactive-compile-pdf-mode
│   (progn
│   (my-org-compile-latexmk-interactive)
│   (add-hook 'after-save-hook #'org-latex-export-to-latex nil t))
│ (remove-hook 'after-save-hook #'org-latex-export-to-latex t)
│ (when (equal (process-status "latexmk") 'run)
│   (kill-process "latexmk"
└

And a screencast:



--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: naming: Re: Experimental public branch for inline special blocks

[Samuel Wales]

[i did not aim that at any particular person!]

On 3/4/24, Samuel Wales  wrote:
> If language is not correct, then what is said is
> not what is meant; if what is said is not what is meant,
> then what must be done remains undone; if this remains
> undone, morals and art will deteriorate; if justice goes
> astray, the people will stand about in helpless
> confusion. Hence there must be no arbitrariness in what is
> said. This matters above everything.  --- analects
>
> On 3/4/24, Juan Manuel Macías  wrote:
>> Max Nikulin writes:
>>
>>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>>> within paragraphs are named objects. I admit that for org-element
>>> everything is element.
>>
>> In my initial message I used 'element' loosely. Note that
>> inline-special-block is included in org-element-all-objects, where
>> inline-src-block is also.
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: naming: Re: Experimental public branch for inline special blocks

[Samuel Wales]

If language is not correct, then what is said is
not what is meant; if what is said is not what is meant,
then what must be done remains undone; if this remains
undone, morals and art will deteriorate; if justice goes
astray, the people will stand about in helpless
confusion. Hence there must be no arbitrariness in what is
said. This matters above everything.  --- analects

On 3/4/24, Juan Manuel Macías  wrote:
> Max Nikulin writes:
>
>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>> within paragraphs are named objects. I admit that for org-element
>> everything is element.
>
> In my initial message I used 'element' loosely. Note that
> inline-special-block is included in org-element-all-objects, where
> inline-src-block is also.
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: naming: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Max Nikulin writes:

> In Org syntax, "elements" are paragraphs and larger parts, while parts
> within paragraphs are named objects. I admit that for org-element
> everything is element.

In my initial message I used 'element' loosely. Note that
inline-special-block is included in org-element-all-objects, where
inline-src-block is also.

Re: naming: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Max Nikulin  writes:
>
>> Does anybody have an idea of a better name for a feature? Maybe 
>> something like inline custom objects, snippets. "Objects" are used to 
>> describe syntax, but not used in the manual though.
>
> Custom inline markup.

Custom span?

I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

> Does anybody have an idea of a better name for a feature? Maybe 
> something like inline custom objects, snippets. "Objects" are used to 
> describe syntax, but not used in the manual though.

Custom inline markup.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 02/03/2024 03:34, Juan Manuel Macías wrote:


Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:


I find the feature name confusing, however I am unsure if others share 
my opinion.


In Org syntax, "elements" are paragraphs and larger parts, while parts 
within paragraphs are named objects. I admit that for org-element 
everything is element.


In CSS "display: inline block" makes an HTML element a rectangular block 
inside a paragraph while new feature is mostly intended for normal text 
flow. I admit that [...]{...} may be used to create an instance 
similar to inline block and that "inline source blocks" are already 
described in the manual.


Does anybody have an idea of a better name for a feature? Maybe 
something like inline custom objects, snippets. "Objects" are used to 
describe syntax, but not used in the manual though.

Re: Provide sane default for the @direntry

[Stefan Monnier]

>> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.
> It would be nice to provide etc/ORG-NEWS entry as well.

Yes, thanks.

>>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
>>The directory title of the document.
>> +  This is the short name under which the ~m~ command will find your
>> +  manual in the main Info directory.  It defaults to the base name of
>> +  the Texinfo file.
>> +
>> +  If you need more control, it can also be the full entry using the
>> +  syntax ~* TITLE: (FILENAME).~.
>
> This example is a bit confusing. How will it look like in Org document?
> #+TEXINFO_DIR_TITLE: * title: (filename). ?
> If yes, it is confusing because you just mention that default value is
> filename, but you have both "title" and "filename" in the example.
>
> Maybe
>
> : #+TEXINFO_DIR_TITLE: * name: (filename).
>
> ?

[ Calling it "TITLE" is definitely confusing, I should use DIRTITLE.  ]

And yes, the Texinfo syntax is either

* FILENAME.

or

* DIRTITLE: (FILENAME).

[ where FILENAME which should be the file name without the
  `.info` extension).  ]

so I think it makes a lot sense for DIRTITLE to default to FILENAME?

The "* DIRTITLE: (FILENAME)." syntax is Texinfo's syntax, and currently the
Org user needs to know that syntax and abide by it (even though it's
not well defined nor well documented, IME).  My change mostly makes it
unnecessary for the user to know that syntax because ox-texinfo already
knows the FILENAME, so it only needs the DIRTITLE.

The new code supports the "* DIRTITLE: (FILENAME)." syntax mostly for
backward compatibility, tho it can also be useful in corner cases such
as when the final filename will be different than the one ox-texinfo
knows about.

Not sure how to adjust the text to clarify that, without including
a discussion of the "* DIRTITLE: (FILENAME)." and how things used to be,
and how the filename is controlled.

The old(current) situation is arguably worse because it doesn't even
document the syntax that needs to be used.

>>  - =TEXINFO_DIR_DESC= ::
>>  
>>#+cindex: @samp{TEXINFO_DIR_DESC}, keyword
>>The directory description of the document.
>> +  Defaults to the title of the document.
>
> I'd also add that it should be a short sentence.

Not sure if it needs to be a sentence, but yes, it should usually be
short tho I don't think there's a technical need for it, so I think the
"defaults to the title" should be a good enough hint about the kind of
length expected.

>>  (:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t)
>> +;; FIXME: The naming of these options is unsatisfactory:
>> +;; TEXINFO_DIR_DESC corresponds (and defaults) to the document's
>> +;; title, whereas TEXINFO_DIR_TITLE corresponds (and defaults) to
>> +;; its filename.
> What about TEXINFO_DIR_NAME + TECINFO_DIR_DESC?

Fine by me, yes.

> I do not see a big problem with description defaulting to document title
> given that it should be a short sentence - an equivalent of proper
> document title.

I don't see a problem with it either.  The problem is mostly in the
DIR_TITLE name suggesting it should be like the title rather than the
indexing keyword that it is.

>> + (let* ((dircat (plist-get info :texinfo-dircat))
>> +(dt (plist-get info :texinfo-dirtitle))
>> +(file (file-name-sans-extension
>> +   (or (org-strip-quotes (plist-get info :texinfo-filename))
>> +   (plist-get info :output-file
>> +(dirtitle
>> + (cond
>> +  ((and dt
>> +(or (string-match "\\`\\* \\(.*?\\)\\(\\.\\)?\\'" dt)
>> +(string-match "\\`\\(.*(.*)\\)\\(\\.\\)?\\'" dt)))
>> +   ;; `dt' is already "complete".
>> +   (format "* %s." (match-string 1 dt)))
>> +  ((and dt (not (equal dt file)))
>> +   (format "* %s: (%s)." dt file))
>
> It would be nice to add a comment saying that dt values like
> "Foo (filename)" are already captured by the previous cond clause.

I don't understand what you mean by that.

>> +  (t (format "* %s." file)
>
> What if dt is "Foo."?

Good point.


Stefan

Re: [BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]

[Philip Kaludercic]

Ihor Radchenko  writes:

> Philip Kaludercic  writes:
>
>> This just popped up in my *Warnings* buffer:
>>
>> --8<---cut here---start->8---
>> ⛔ Warning (org-element-cache): org-element--cache: Org parser error
>> in .links.org::29638. Resetting.
>>  The error was: (wrong-type-argument integer-or-marker-p nil)
>> ...
>> I was editing a file through occur over TRAMP, but otherwise I don't
>> think anything special was going on.
>
> Thanks for reporting!
> Does the error persist if you upgrade Org mode to the latest 9.6.20
> version? If yes, what about the development version?

Sorry, I cannot really reproduce the bug in any reliable way.

-- 
Philip Kaludercic on peregrine

Re: [PATCH] org-babel-demarcate-block: split using element API

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> I resubmit my patch (attached) without any caveats in the commit 
> message.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c2ea553be

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-babel-demarcate-block: split using element API

[gerard . vermeulen]

On 04.03.2024 11:12, Ihor Radchenko wrote:


What about after
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5f5db3d35
?


This fixes the bug.
I resubmit my patch (attached) without any caveats in the commit 
message.


Regards -- Gerard



0001-org-babel-demarcate-block-split-using-element-API.patch
Description: Binary data

Re: [BUG] we should obsolete org-fontify-whole-heading-line [9.7 (9.7-??-b127d72 @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

[Ihor Radchenko]

StrawberryTea  writes:

> We should make org-fontify-whole-heading-line default to t and obsolete
> it. That variable was added before the introduction of the :extend
> keyword for text properties. Now that we have :extend, we can make the
> whole heading line face extend to the end of the window without needing
> a special variable for it.

Nope.
Try to set underline face for headlines and see how it spans one char
further than end of heading when `org-fontify-whole-heading-line' is t
and headline face does not have :extend t.

Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Re: The orgframe construct in the Beamer exporter as a default needs a rethink

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> Org-lint will signal that… IHvHO that’s more than enough 

May you elaborate?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Provide sane default for the @direntry

[Ihor Radchenko]

Stefan Monnier  writes:

>> May you please supply a ChangeLog entry? I am not sure if I understand
>> the purpose of each change in the diff.
>>
>> Also, it looks like you introduce some DWIM behaviour for auto-generating
>> @direntry contents. Such new behaviour ought to be documented in the
>> manual and announced in the news.
>
> New patch attached,

Thanks!
See my comments inline.

> * lisp/org/ox-texinfo.el: Remove redundant `:group` arguments.
> Prefer #' to quote function names.

May you please split unrelated changes into a separate patch?

> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly.

It would be nice to provide etc/ORG-NEWS entry as well.

>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword
>The directory title of the document.
> +  This is the short name under which the ~m~ command will find your
> +  manual in the main Info directory.  It defaults to the base name of
> +  the Texinfo file.
> +
> +  If you need more control, it can also be the full entry using the
> +  syntax ~* TITLE: (FILENAME).~.

This example is a bit confusing. How will it look like in Org document?
#+TEXINFO_DIR_TITLE: * title: (filename). ?
If yes, it is confusing because you just mention that default value is
filename, but you have both "title" and "filename" in the example.

Maybe

: #+TEXINFO_DIR_TITLE: * name: (filename).

?
  
>  - =TEXINFO_DIR_DESC= ::
>  
>#+cindex: @samp{TEXINFO_DIR_DESC}, keyword
>The directory description of the document.
> +  Defaults to the title of the document.

I'd also add that it should be a short sentence.
  
>  (:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t)
> +;; FIXME: The naming of these options is unsatisfactory:
> +;; TEXINFO_DIR_DESC corresponds (and defaults) to the document's
> +;; title, whereas TEXINFO_DIR_TITLE corresponds (and defaults) to
> +;; its filename.

What about TEXINFO_DIR_NAME + TECINFO_DIR_DESC?

I do not see a big problem with description defaulting to document title
given that it should be a short sentence - an equivalent of proper
document title.

> + ;; Info directory information.  Only supply if category is provided.
> + ;; FIXME: A Texinfo doc without a direntry is significantly less useful
> + ;; since it won't appear in the main Info-directory, so maybe we should
> + ;; use a default category like "misc"?

Sounds reasonable. We may add a new custom option with default category.

> + (let* ((dircat (plist-get info :texinfo-dircat))
> + (dt (plist-get info :texinfo-dirtitle))
> + (file (file-name-sans-extension
> +(or (org-strip-quotes (plist-get info :texinfo-filename))
> +(plist-get info :output-file
> + (dirtitle
> + (cond
> +  ((and dt
> +(or (string-match "\\`\\* \\(.*?\\)\\(\\.\\)?\\'" dt)
> +(string-match "\\`\\(.*(.*)\\)\\(\\.\\)?\\'" dt)))
> +   ;; `dt' is already "complete".
> +   (format "* %s." (match-string 1 dt)))
> +  ((and dt (not (equal dt file)))
> +   (format "* %s: (%s)." dt file))

It would be nice to add a comment saying that dt values like
"Foo (filename)" are already captured by the previous cond clause.

> +  (t (format "* %s." file)

What if dt is "Foo."?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[DISCUSSION] Face priority in Org fontification (was: [BUG] org dates, radio links, and special keywords override heading backgrounds [9.7 (9.7-??-902dacb @ /home/st/.config/emacs/.local/straight/buil

[Ihor Radchenko]

StrawberryTea  writes:

> Hello. Currently, if you have a heading background, and you have a date,
> radio link, or special keyword, the background is overridden. I have
> attached a patch that fixes this issue by using the `prepend' property
> instead of the `t' property. Here is also a minimal example to reproduce
> the issue:

This is not an exhaustive list. We have a number of markup objects that
are fontified overriding the containing element/paragraph/heading face:

- target links
- timestamps
- footnotes
- radio targets
- macros
- inline export snippets

I am not 100% sure we should unconditionally prepend their faces to
the containing headline/table/etc.

CCing Protesilaos. This discussion might be of interest for him.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-babel-demarcate-block: split using element API

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

>> Have you tried the latest main?
>
> Yes (just tried again), the minimal function still triggers the 
> "infinite" list of warnings
> "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org 
> buffer # (python-mode)"
> It is coming from the last org-indent-block call even though the message
> just before tells that the mode is derived from org-mode.

What about after
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5f5db3d35
?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at