Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 3/26/24 09:59, Ihor Radchenko wrote:


I agree. My concern was not about dropping the previous wording.

What about

The assignment process does not always go quickly; occasionally it may
get stuck or overlooked at the FSF.  If there is no response to the
contributor from FSF, Org mode maintainers can contact the FSF at
  =copyright-clerk AT fsf DOT org=.  Historically, FSF replies to the
  maintainer request within a few days.

   ^^^

Other than changing "request" to, e.g. "arrive," no objection from me.

Thanks,
Adam

Re: [Worg] CSS improvements

[Adam Porter]

On 3/26/24 09:48, Ihor Radchenko wrote:

Adam Porter  writes:


What is the purpose of centering text if not to make it stand out?


To align text. I am not sure why anything more is necessary - it
is certainly counter-intuitive for me that "center" means something more
than just alignment.


Again, what is the purpose of centering text?  The answer, "To align
text," is tautological.


I am very confused. Of course, it is tautological. "center" container is
aiming to align the text. That's why it is named "center".


Yes, but why do we center text?  That's what I'm asking.


Especially, on Worg, where the whole site serves as a kind of extended
user manual, the purpose of centering text is, what, if not to make it
stand out?


To align text... I really do not understand why one would _anticipate_
that #+begin_center is doing anything other than center alignment.


Of course, I'm not suggesting that this be the default for Org's HTML 
export CSS.  I'm suggesting that, on Worg, since the .org-center class 
hasn't even been styled, we might as well use it for this purpose--to 
make text stand out--since that's generally the purpose of centering 
text anyway.



If you need extra highlighting, we may introduce a dedicated style and
apply it via special block.


Why, when we already have #+begin_center?  Currently it's not even used
at all.  This would not change anything that already exists; it would
make something that already exists useful.


It would break expectations.
It will also differ from ox-html output with the default css style
`org-html-style-default':


Worg already differs significantly from the ox-html default styles, so 
why not in this way also?



Mostly because it is unexpected, as I described above.
I'd prefer to stick closer to the semantics and just apply alignment to
center blocks.


*shrug*  Worg has existed for years without even doing anything with
#+begin_center blocks--not even centering them.  I propose that we make
it useful and serve its natural purpose, rather than adding a special
new block that most users won't even know about (having to find it in
the voluminous Worg content isn't likely to happen for most users).


I do not see how, without documentation, one would expect that
#+begin_center can be used for highlighting and not for text alignment.
 From my point of view, it is worse than a special block - not only this
ad-hoc convention is not documented; it will also break expectations
about what #+begin_center does.


Again, this is just for Worg, and centering hasn't even had any effect 
for years.  There seem to be no expectations to break.



What about:

1. Introducing a new special block for highlighting
2. Documenting it in https://orgmode.org/worg/worg-editing.html


I think that such a new special block would likely go unused in favor of 
default blocks.  The cognitive load of learning how to contribute to 
Worg is already pretty high.  We see this same pattern in contributions 
to Emacs and Org themselves: code is often unidiomatic because it takes 
a long time to learn all the idioms, and it's often not obvious what the 
idiomatic way to do something is.  The same is true for contributions to 
documentation.  Worg is no different.


So I would still suggest that, on Worg, we use my suggested styling on 
#+begin_center blocks.  This would make them useful and fulfill their 
natural purpose.


I understand your general objection--and I wouldn't suggest it for Org's 
default export CSS--but I think that, for Worg specifically, it needn't 
apply.


Since Worg is updated with relatively low frequency, anyway, perhaps 
this suggestion could be tried as an experiment.  If problems are found 
with it, then the extra styling, beyond merely centering the text, could 
be reverted.  Nothing is permanent here; we've probably spilled more 
virtual ink on this topic than would be affected by the change.


Anyway, if this idea is vetoed, it would still be good to have some way 
to make text stand out in a standard way, similar to various HTML 
documentation styles in other projects (to avoid resorting to inline 
HTML).  It seems like a missing feature on Worg.


And the other changes in the patch would be good to have, regardless.

Thanks,
Adam

Question about citation formatting

[Christian Wittern]

Dear org users,

This is my second paper I am formatting with the new citation framework, 
this time using csl for the first time, since basic does not fit the 
bill anymore.


This paper is discussing and comparing translations to the same text. So 
when I mention publications in the text, I want to have the keyword to 
be the translator, rather than the author.


Here is the entry bibliography:

-test.bib--

@book{dogenMoonDewdrop1985,
  title = {Moon in a Dewdrop},
  author = {Dōgen},
  year = {1985},
  publisher = {{San Francisco : North Point Press}},
  isbn = {978-0-86547-186-3},
  language = {eng},
  translator = {Tanahashi, Kazuaki}
}

The org file looks like this:

test.org--

#+TITLE: Translation test
#+OPTIONS: num:nil toc:nil tags:nil todo:nil ':t ^:{}
# #+cite_export: basic author-year author
#+cite_export: csl /home/chris/src/org-mode/etc/csl/chicago-author-date.csl
#+bibliography: test.bib



In [cite: @dogenMoonDewdrop1985 p37] there is a different translation:
* References
#+print_bibliography:

---

and the resulting export, in this case to a buffer, looks like this:



  ━━━
    TRANSLATION TEST
  ━━━


In (Dōgen 1985, 37) there is a different translation:


References
══

  Dōgen, 1200-1253. 1985. /Moon in a Dewdrop/. Translated by Kazuaki
  Tanahashi. San Francisco : North Point Press.

--

What I would like to see is instead:

"In (Tanahashi 1985, 37) there is a different translation:"

in the running text.

Has anybody an idea of how to achieve this?

Any help appreciated,

Christian

Re: org-agenda-skip-function now evaluated on line after headline?

[Sean Whitton]

Hello,

I apologies for not replying to this when the details were still fresh
in my mind.  I'm not sure enough of the problem now.  My apologies
again.

-- 
Sean Whitton

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

[Gregor Zattler]

Hi Ihor,
* Ihor Radchenko  [2024-03-26; 10:27 GMT]:
> Gregor Zattler  writes:
>
>> In the file.org_archive, with point on a clock line:
>>
>> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
>>   encode-time((0 nil nil nil nil nil nil -1 nil))
>>   (float-time (encode-time (list 0 (org-element--property :minute-start 
>> timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
>> (org-element--property :day-start timestamp nil nil) (org-element--property 
>> :month-start timestamp nil nil) (org-element--property :year-start timestamp 
>> nil nil) nil -1 nil)))
>
> This is helpful. You have some very strange timestamp.
> May you, when the backtrace window is active, press
> e (buffer-substring-no-properties (line-beginning-position -2) 
> (line-end-position 3)) 
> It should display text around the problematic timestamp.
>
> I'd like to see the problematic timestamp to understand what might be
> going on there.


thanks for your instructions, I edited it a bit:

"   - SxII VPN vxx USB S ()
CLOCK: [2012-02-02 Do 14:00]--[2012-02-02 Do 16:00] =>  2:00
- SxII; Rxx kx, n xx
Clock: [2012-02-01 Mi 17:34]--[2012-02-01 Mi 18:24] =>  0:50
- Gxxx-... #NV -Fx a
CLOCK: [2012-02-01 Mi 17:04]--[2012-02-01 Mi 17:33] =>  0:29"


>> seems to be somewhat truncated.  Is there a way to get
>> it unabbreviated?
>
> Press "." (M-x backtrace-expand-ellipses)

this way I get:

Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
  encode-time((0 nil nil nil nil nil nil -1 nil))
  (float-time (encode-time (list 0 (org-element--property :minute-start 
timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil)))
  (let* ((timestamp (org-element--property :value element nil nil)) (ts 
(float-time (encode-time (list 0 (org-element--property :minute-start timestamp 
nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil (te (float-time (encode-time (list 0 
(org-element--property :minute-end timestamp nil nil) (org-element--property 
:hour-end timestamp nil nil) (org-element--property :day-end timestamp nil nil) 
(org-element--property :month-end timestamp nil nil) (org-element--property 
:year-end timestamp nil nil) nil -1 nil (dt (- (if tend (min te tend) te) 
(if tstart (max ts tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 
60))
  (cond ((and (eq element-type 'clock) (match-end 2)) (let* ((timestamp 
(org-element--property :value element nil nil)) (ts (float-time (encode-time 
(list 0 (org-element--property :minute-start timestamp nil nil) 
(org-element--property :hour-start timestamp nil nil) (org-element--property 
:day-start timestamp nil nil) (org-element--property :month-start timestamp nil 
nil) (org-element--property :year-start timestamp nil nil) nil -1 nil (te 
(float-time (encode-time (list 0 (org-element--property :minute-end timestamp 
nil nil) (org-element--property :hour-end timestamp nil nil) 
(org-element--property :day-end timestamp nil nil) (org-element--property 
:month-end timestamp nil nil) (org-element--property :year-end timestamp nil 
nil) nil -1 nil (dt (- (if tend (min te tend) te) (if tstart (max ts 
tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 60))) 
((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 
(string-to-number (match-string 4)) ((memq element-type '(headline 
inlinetask)) (if (and org-clock-report-include-clocking-task (eq 
(org-clocking-buffer) (current-buffer)) (eq (marker-position 
org-clock-hd-marker) (point)) tstart tend (>= (float-time org-clock-start-time) 
tstart) (<= (float-time org-clock-start-time) tend)) (progn (let ((time (floor 
(org-time-convert-to-integer (time-since org-clock-start-time)) 60))) (setq t1 
(+ t1 time) (let* ((headline-forced (get-text-property (point) 
:org-clock-force-headline-inclusion)) (headline-included (or (null 
headline-filter) (save-excursion (let ((saved-match-data (match-data))) 
(unwind-protect (progn (funcall headline-filter)) (set-match-data 
saved-match-data t))) (setq level (- (match-end 1) (match-beginning 1))) 
(if (>= level lmax) (progn (progn (setq ltimes (vconcat ltimes (make-vector 
lmax 0))) (setq lmax (* 2 lmax) (if (or (> t1 0) (> (aref ltimes level) 0)) 
(progn (if (or headline-included headline-forced) (progn (if headline-included 
(let* ((l 0) (--cl-var-- level)) (while (<= l --cl-var--) (aset ltimes l (+ 
(aref ltimes l) t1)) (setq l (+ l 1))) nil)) (setq time (aref ltimes level)) 
(goto-char (match-beginning 0)) 

Re: [Worg] CSS improvements

[David Rogers]

Adam Porter  writes:

On 3/24/24 03:56, Ihor Radchenko wrote: 
Adam Porter  writes:  
I am not sure if centered text should stand out.  AFAIU, you 
want to add this style for the sole purpose of highlighting 


What is the purpose of centering text if not to make it stand 
out? 
To align text. I am not sure why anything more is necessary - 
it is certainly counter-intuitive for me that "center" means 
something more than just alignment. 


Again, what is the purpose of centering text?  The answer, "To 
align text," is tautological. 


I don't agree that it's tautological. Aligning text differently is 
already a method of emphasizing it. Double- or multi-emphasizing 
that text by adding even more styles to it leads me to question 
the value of centering it in the first place. I'm not claiming 
it's somehow wrong to use more than one emphasis though - this is 
just a thought


:)

--
David Rogers

[PATCH] lisp/ox-html.el: Add avif support for html export inline images

[Ross Timson]

* lisp/ox-html.el (org-html-inline-image-rules): Add AVIF image
support for inline images on HTML export.

AVIF is well supported by browsers these days and offers similar
features and much better compression than the other image formats
commonly used for the web.

TINYCHANGE
---
 lisp/ox-html.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index baca21014..5234b634d 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -861,9 +861,9 @@ link to the image."
   :type 'boolean)
 
 (defcustom org-html-inline-image-rules
-  `(("file" . ,(regexp-opt '(".jpeg" ".jpg" ".png" ".gif" ".svg" ".webp")))
-("http" . ,(regexp-opt '(".jpeg" ".jpg" ".png" ".gif" ".svg" ".webp")))
-("https" . ,(regexp-opt '(".jpeg" ".jpg" ".png" ".gif" ".svg" ".webp"
+  `(("file" . ,(regexp-opt '(".jpeg" ".jpg" ".png" ".gif" ".svg" ".webp" 
".avif")))
+("http" . ,(regexp-opt '(".jpeg" ".jpg" ".png" ".gif" ".svg" ".webp" 
".avif")))
+("https" . ,(regexp-opt '(".jpeg" ".jpg" ".png" ".gif" ".svg" ".webp" 
".avif"
   "Rules characterizing image files that can be inlined into HTML.
 A rule consists in an association whose key is the type of link
 to consider, and value is a regexp that will be matched against
-- 
2.44.0

Re: inline-special-block: export rules

[Max Nikulin]

On 21/03/2024 17:26, Juan Manuel Macías wrote:

Max Nikulin writes:


I am afraid that :export will cause confusion with :exports for source
code blocks. Its name differs by just "s" but possible values have
nothing common.


I agree. At the moment two alternative names come to mind: :backends or
:export-rules


I find :export-rules too abstract. Unless a better name is proposed, I 
prefer :backends.



:export [or whatever new name we give it] ==> normal behavior, overwrites the 
values
:export+ ==> adds the new values to the values defined in the alias


Vim for options allowing list of values has several options
:set opt=value1,value2 " assign new value
:set opt+=value " add to list
:set opt-=value " remove from list if it is there
:set opt& " reset to default value
I am unsure whether all variants should be implemented.


This syntax could also be extended to other cases. Perhaps we want
attributes like :prelatex, :postlatex, or :html to support accumulating
values.


Certainly :export (:backends) is not the only property that should 
accumulate values.

Re: [PATCH] Create commands for org-read-date-minibuffer-local-map

[Ihor Radchenko]

Laurence Warne  writes:

>> Applied, onto main; with minor amendments to the commit message format.
>> I also added TINYCHANGE cookie as I do not see in our records that you
>> have FSF copyright assignment
>
> I believe I have signed it previously in order to contribute to Emacs core
> and ELPA packages, is that not applicable here?  Apologies - I am not too
> familiar with the process (:

It is applicable. It is just that you were not listed in our
housekeeping list at https://orgmode.org/worg/contributors.html.

Bastien, may you please check FSF records?

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

Re: [PATCH] Create commands for org-read-date-minibuffer-local-map

[Laurence Warne]

> You are also now listed as an Org mode contributor.
> https://git.sr.ht/~bzg/worg/commit/fbc3129d


Nice, thanks!

> Applied, onto main; with minor amendments to the commit message format.
> I also added TINYCHANGE cookie as I do not see in our records that you
> have FSF copyright assignment

I believe I have signed it previously in order to contribute to Emacs core
and ELPA packages, is that not applicable here?  Apologies - I am not too
familiar with the process (:

Re: [PATCH] Create commands for org-read-date-minibuffer-local-map

[Ihor Radchenko]

Laurence Warne  writes:

> I have attached a small patch which switches out inline commands in
> org-read-date-minibuffer-local-map for new analogous commands.
>
> The intent is to aid documentation and user configuration, so the user gets
> a nice description and source code when any corresponding key is looked up
> via help, and can rebind it without copying the lambda themselves.

Thank you!
Applied, onto main; with minor amendments to the commit message format.
I also added TINYCHANGE cookie as I do not see in our records that you
have FSF copyright assignment (see
https://orgmode.org/worg/org-contribute.html#first-patch)
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=990b89d32

You are also now listed as an Org mode contributor.
https://git.sr.ht/~bzg/worg/commit/fbc3129d

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

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Adam Porter  writes:

> ...
>> According to
>> https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers:
>> ...
>> We must use a specific form from a specific URL.
>
> That isn't how the Emacs maintainers handle it.  They send a form by 
> email when asked, or direct users to use the one in the Emacs git repo. 
> AFAICT, they are equivalent, if not identical.
>
> Regardless, it would be nice to have a canonical answer to this.  The 
> gnu.org site says one thing, the emacs.git repo says another, 
> org-mode.git says another, the people on the mailing say another, and 
> Worg says another--all slightly different for no apparent reason. 
> (There's also the Emacs manual, which probably mentions it too.)

AFAIU, gnu.org is the source of truth for us, as a GNU project.
Bastien, any comments? Maybe we should ask gnu-advis...@gnu.org?

>> Also, about the changes to the FSF form that Stefan mentioned in
>> https://yhetil.org/emacs-devel/jwvh6hne6nv.fsf-monnier+em...@gnu.org/
>> It does not look like they are official yet. See
>> https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00060.html
>
> AFAICT the only change is the line that asks the FSF to send additional 
> confirmation to some other interested parties.  Does that need to be 
> officially official in order to use it?  The alternative is having the 
> contributor ask by writing in the email message, which seems equivalent. 
>   IOW, it doesn't change the form, it just adds an extra request.

Yes, it has to be, if we stick to what gnu.org says:

   ... Please don’t use any of
   the templates except for those listed here, and please don’t change the
   wording.

(I personally also do prefer the changed wording, but we are not
discussing personal preferences here; it is a legal dimension)

>>> +The assignment process does not always go quickly; occasionally it may
>>> +get stuck or overlooked at the FSF.  The contact at the FSF for this
>>> +is: =copyright-clerk AT fsf DOT org=.  In rare cases, an inquiry from an
>>> +Org maintainer gets the process moving again.
>> 
>> I may be missing something, but the last sentence now reads like our
>> (Org maintainer's) inquiry rarely works.
>> 
>> The previous version is very different, IMHO:
>> 
>>> -Emails from the paper submitter have been ignored in the past, but an
>>> -email from the maintainers of Org mode has usually fixed such cases
>>> -within a few days.
>
> I would have preferred to omit all the language about the process 
> sometimes not going quickly or smoothly; it doesn't seem necessary or 
> helpful to publish such words, because they seem accusatory toward the 
> FSF volunteers.

I agree. My concern was not about dropping the previous wording.

What about

The assignment process does not always go quickly; occasionally it may
get stuck or overlooked at the FSF.  If there is no response to the
contributor from FSF, Org mode maintainers can contact the FSF at
 =copyright-clerk AT fsf DOT org=.  Historically, FSF replies to the
 maintainer request within a few days.

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

Re: [Worg] CSS improvements

[Ihor Radchenko]

Adam Porter  writes:

>>> What is the purpose of centering text if not to make it stand out?
>> 
>> To align text. I am not sure why anything more is necessary - it
>> is certainly counter-intuitive for me that "center" means something more
>> than just alignment.
>
> Again, what is the purpose of centering text?  The answer, "To align 
> text," is tautological.

I am very confused. Of course, it is tautological. "center" container is
aiming to align the text. That's why it is named "center".

> Especially, on Worg, where the whole site serves as a kind of extended 
> user manual, the purpose of centering text is, what, if not to make it 
> stand out?

To align text... I really do not understand why one would _anticipate_
that #+begin_center is doing anything other than center alignment.

>> If you need extra highlighting, we may introduce a dedicated style and
>> apply it via special block.
>
> Why, when we already have #+begin_center?  Currently it's not even used 
> at all.  This would not change anything that already exists; it would 
> make something that already exists useful.

It would break expectations.
It will also differ from ox-html output with the default css style
`org-html-style-default':

  .org-center { margin-left: auto; margin-right: auto; text-align: center; }

>> Mostly because it is unexpected, as I described above.
>> I'd prefer to stick closer to the semantics and just apply alignment to
>> center blocks.
>
> *shrug*  Worg has existed for years without even doing anything with 
> #+begin_center blocks--not even centering them.  I propose that we make 
> it useful and serve its natural purpose, rather than adding a special 
> new block that most users won't even know about (having to find it in 
> the voluminous Worg content isn't likely to happen for most users).

I do not see how, without documentation, one would expect that
#+begin_center can be used for highlighting and not for text alignment.
>From my point of view, it is worse than a special block - not only this
ad-hoc convention is not documented; it will also break expectations
about what #+begin_center does.

What about:

1. Introducing a new special block for highlighting
2. Documenting it in https://orgmode.org/worg/worg-editing.html

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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:

Hello,

I've finally implemented a solution to what I've discussed previously,
inserting zero width spaces as boundary characters after an ANSI
sequence to act as a separator from the text after the sequence.  This
would handle the scenario where deleting into the end byte of a
sequence causes ansi-color to recognize the partially deleted sequence
plus the character directly after the end byte to be a new sequence.
This looked like the invisible region containing a sequence eating up
other characters not intended to be part of the region.

So for example, suppose you had a control sequence, ^[[42m, where m is
the end byte that says the sequence is a color sequence.  Let point be
signified by *.  If we have

^[[42m*text

then deletion into the end byte would result in 

^[[42*text

t is still a valid end byte so the fontification process will
recognized the whole thing as a valid sequence still and the t would
then become part of the invisible region containing the sequence.

To avoid this from happening I have introduced the rule that any valid
sequence shall have a zero width space immediately after it and this
space remains in the buffer even on deleting into it with, for
example, backward-delete-char.  Let the zero width space be signified
by |.  If we have 

^[[42m|*text

then deletion into the space would now result in

^[[42*|text

i.e., the effect is that the deletion went past the space, leaving it
alone, and deleted the end byte of the control sequence.  Since the
control sequence is no longer valid, due to the space being at the
position of the end byte, it becomes visible.

If you then insert a valid end byte, e.g. m, then the effect is

^[[42m|*text

i.e., point moved past the space character.

So the implementation of that rule of maintaining a zero width space
after valid sequences and the rules around deleting into the space or
insertion in front of a space are the main changes in this patch
compared to previous versions.

>
> I tried to test your newest patch with the example file you provided and
> I notice two things that would be nice:
>
> 1. It is a bit confusing to understand why one or other text is colored
>without seeing the escape characters. Some customization like
>`org-link-descriptive' and a command like `org-toggle-link-display'
>would be nice. I can see some users prefer seeing the escape codes.

I've gone ahead and implemented the toggling of the visibility of the
escapes sequences.  The variable is `org-ansi-hide-sequences` and the
function is `org-toggle-ansi-display`.

I just used buffer-invisibility-spec for this.

>
> 2. Using overlays for fontification is problematic. In your example
>file, table alignment becomes broken when escape sequences are hidden
>inside overlays:
>
>| [31mcell 1 | cell 2 |
>| cell 3   | cell 4 |
>
>looks like
>
>|   cell 1 | cell 2 |
>| cell 3   | cell 4 |
>
>Using text properties would make table alignment work without
>adjustments in the org-table.el code.
>

I've gone ahead and used text properties instead of overlays.

>> One thing I would like to start doing is writing some tests for this
>> feature.  It would be great if someone could point me to some tests
>> that I can peruse so that I can get an idea of how I can go about
>> writing some of my own.  Also, are there any procedures or things I
>> should be aware of when trying to write my own tests?
>
> Check out testing/README file in the Org repository.
>
> Unfortunately, we do not yet have any existing tests for font-locking in
> Org tests. You may still refer to the files in testing/lisp/ to see some
> example tests.
>
> Also, Emacs has built-in library to help writing font-lock tests -
> faceup.el. You may consider using it. Its top comment also contains a
> number of references to various tools that could be useful to diagnose
> font-locking code.

I have not looked into testing this feature yet.

Feedback appreciated!

>From ea2345ab218d3bc9c07452b2171afc1361b74b9d Mon Sep 17 00:00:00 2001
From: Nathaniel Nicandro 
Date: Tue, 9 May 2023 19:58:11 -0500
Subject: [PATCH] Highlight ANSI escape sequences

* etc/ORG-NEWS: Describe the new feature.
* lisp/org.el (org-fontify-ansi-sequences): New customization variable
and function which does the work of fontifying the sequences.
(org-ansi-hide-sequences)
(org-ansi-highlightable-elements)
(org-ansi-highlightable-objects): New customization variables.
(org-ansi--before-command, org-ansi--after-command)
(org-ansi--before-control-seq-deletion)
(org-ansi--after-control-seq-deletion)
(org-ansi-zero-width-space, org-ansi-is-zero-width-space)
(org-ansi-new-context, org-ansi-process-region)
(org-ansi-process-block, org-ansi-process-paragraph)
(org-ansi-process-fixed-width)
(org-fontify-ansi-sequences-1)
(org-toggle-ansi-display): New functions.
(org-ansi--control-seq-positions)
(org-ansi--change-pending, 

Re: [PATCH] Run latex more than once for LaTeX src block evaluation

[Max Nikulin]

On 24/03/2024 15:58, Ihor Radchenko wrote:

Max Nikulin writes:

On 22/03/2024 05:55, Michael wrote:

I have a small patch for `org-preview-latex-process-alist' making
the default setting for LaTeX source block evaluation be running
latex three times (instead of the current one).


I suspect it may make the LaTeX preview feature unacceptably slow for
documents heavily loaded with math snippets.


Then, we may instead use latexmk - it will run latex as many times as
necessary.


Sorry I have no experience with latexmk. At least a fallback should be 
available if this script is not installed.


The LaTeX preview feature is close to dangerous per se. With latexmk the 
barrier may be even lower. Some users may have -shell-escape enabled in 
latexmk configuration. I hope, it is not possible to force latexmk 
execute something weird by spitting a crafted message into logs.


I have no idea how to enable preview for trusted files only without 
ruining usability.

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

[Max Nikulin]

On 25/03/2024 22:46, Gregor Zattler wrote:

rm -rf *; git checkout -f


git clean -dffx

should be a bit safer. However there is still risk to lost files have 
not been committed to git.

Re: [BUG] LaTeX preview should use a subdirectory in /tmp

[Max Nikulin]

On 25/03/2024 19:49, Max Nikulin wrote:


(defun org-ensure-tmp-dir (dir-symbol prefix)
   (let ((dir (symbol-value dir-symbol)))
     ;; Temporary directory has not been cleaned.
     (or (and dir (file-directory-p dir) dir)


`if' should be used instead of `or' here.


 (setf (symbol-value dir-symbol)
   (make-temp-file (or prefix "orgtmp-") 'dir)

(defvar org-tex-tmpdir nil)

Usage example: (org-ensure-tmp-dir 'org-tex-tmpdir "orgtex-")


I do not like that the function may be called with different 
`temporary-file-directory' and I can not figure out how to adjust API to 
handle such case. On the other hand I am unsure if it is a realistic 
case when this function is called with alternating 
`temporary-file-directory'.

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

[Ihor Radchenko]

Gregor Zattler  writes:

> In the file.org_archive, with point on a clock line:
>
> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
>   encode-time((0 nil nil nil nil nil nil -1 nil))
>   (float-time (encode-time (list 0 (org-element--property :minute-start 
> timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
> (org-element--property :day-start timestamp nil nil) (org-element--property 
> :month-start timestamp nil nil) (org-element--property :year-start timestamp 
> nil nil) nil -1 nil)))

This is helpful. You have some very strange timestamp.
May you, when the backtrace window is active, press
e (buffer-substring-no-properties (line-beginning-position -2) 
(line-end-position 3)) 
It should display text around the problematic timestamp.

I'd like to see the problematic timestamp to understand what might be
going on there.

> seems to be somewhat truncated.  Is there a way to get
> it unabbreviated?

Press "." (M-x backtrace-expand-ellipses)

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