Re: Org markup and non-ASCII punctuation (was: org parser and priorities of inline elements)

[Tom Gillespie]

> We might probably generalize to
> PRE  = Zs Zl Pc Pd Ps Pi ' "
> POST = Zs Zl Pc Pd Pe Pf . ; : ! ? ' " \ [

If this works I think it is reasonable. We might want to
specify what to do in cases where an org implementation
might not fully support unicode, and might want to do a
review of related issues in syntax with respect to ascii
vs unicode, because iirc there is some ambiguity in
the current syntax doc.

For example, I'm pretty sure that I'm mixing and matching
unicode and ascii whitespace in the tokenizer I have in Racket.

> Though we need to take care excluding zero-width spaces.

Ya, I removed a comment to this effect in the paragraph about
the usual alternate solution.

> Emacs does not support them though (yet?).

Racket has full support for the latest unicode standards iirc,
so I will see if I can leverage that support for testing in laundry.

> At the end, it is the current ASCII limitation plus partially arbitrary
> choice of boundaries that keep some users confused (we are getting bug
> reports about confusing markup from time to time).

Ya, it would be good to try to generalize the affordance if possible since
users of text in non-ascii languages have certain valid expectations. Hopefully,
the unicode consortium has managed to cover the categories we need.

Re: org-fontify-emphasized-text

[Colin Baxter]

> Henrik Frisk  writes:

> On Mon, Jul 17, 2023, 1:23 PM Ihor Radchenko  wrote:
>> Henrik Frisk  writes:
>> 
>>> For the first time I tried to enable the fontification of
>>> emphasized text but quickly decided I didn't want it. But I
>>> can't seem to get rid of it.  For example, any part of a
>>> filename that is after an underscore is still printed as subtext
>>> (expected if fontification is on). Is there anything else than
>>> the above variable that controls this? emacs -Q works of course
>>> fine.
>> 
>> Can't get rid even after re-starting Emacs?
>> 

> Exactly, I've had it for weeks annoyingly.

Indeed, it is VERY annoying. Setting

(setq org-use-sub-superscripts nil)

(the default is t) seems to ensure that it does not come on even if some
library puts `org-pretty-entities' to t.

Best wishes,

Colin Baxter.

Re: Org markup and non-ASCII punctuation (was: org parser and priorities of inline elements)

[Ihor Radchenko]

Tom Gillespie  writes:

> The way I have implemented this is by maintaining an explicit list of
> characters that are safe for pre markup and another for post markup.
>
> It is not possible to use unicode punctuation for this because there
> are a variety of punctuation marks that cannot appear in that position
> and be considered markup, those include @, #, % to name just a few.

Not that bad.
Unicode standard defines the following categories (I listed those that
might be of use):

Pc = Punctuation, connector
Pd = Punctuation, dash
Ps = Punctuation, open
Pe = Punctuation, close
Pi = Punctuation, initial quote (may behave like Ps or Pe depending on usage)
Pf = Punctuation, final quote (may behave like Ps or Pe depending on usage)
Po = Punctuation, other
Zs = Separator, space
Zl = Separator, line
Zp = Separator, paragraph

We currently use the following:
PRE  =   - ( ' " {
POST =  - . ; : ! ? ' " ) } \ [

At least, ({ have
(get-char-code-property ?{ 'general-category) ;=> Ps (punctuation, open)

We might probably generalize to
PRE  = Zs Zl Pc Pd Ps Pi ' "
POST = Zs Zl Pc Pd Pe Pf . ; : ! ? ' " \ [

Though we need to take care excluding zero-width spaces.

I can find https://www.unicode.org/review/pr-23.html that defines
punctuation terminals like .;:!?
It looks like it is adopted, via special properties:
https://www.unicode.org/reports/tr44/#STerm and
https://www.unicode.org/reports/tr44/#Terminal_Punctuation

Emacs does not support them though (yet?).

> Therefore, if we want to do this we commit to extending and then
> maintaining the lists of valid pre and post markup delimiters as
> special cases.

We certainly do not want to do this. It is out of scope of Org, when
Unicode can be of use.

> Note also this could produce changes from current behavior because
> things that previously tokenized as a series of words connected by
> e.g. underscores could become markup.

Indeed. And we should study the feedback.
However, most scenarios that will change will involve non-standard
Unicode markup characters. The odds are low that users will use such
Unicode at markup boundary and _also expect markup to be ignored_. At
the end, it is the current ASCII limitation plus partially arbitrary
choice of boundaries that keep some users confused (we are getting bug
reports about confusing markup from time to time).

Of course, we can, as usual, provide a linter to catch such scenarios
and warn in the ORG_NEWS.

I do believe that better Unicode support will benefit many Org users
that use non-Latin scripts. 

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

Re: Org markup and non-ASCII punctuation (was: org parser and priorities of inline elements)

[Tom Gillespie]

Hi Ihor,
   Thank you for looping me in. Best,
Tom

The way I have implemented this is by maintaining an explicit list of
characters that are safe for pre markup and another for post markup.

It is not possible to use unicode punctuation for this because there
are a variety of punctuation marks that cannot appear in that position
and be considered markup, those include @, #, % to name just a few.

Therefore, if we want to do this we commit to extending and then
maintaining the lists of valid pre and post markup delimiters as
special cases.

Note also this could produce changes from current behavior because
things that previously tokenized as a series of words connected by
e.g. underscores could become markup.

The alternative would be (as usual in these cases) for the user to
add a zero width space or something like that between the end of the
markup marker and the symbol they want to follow the markup. This
solution is (trivially) backward compatible, and works for all chars
regardless of whether org-mode has blessed them as sanctioned marks.

My inclination would be not to make this change because there are a
potentially infinite number of future "left right neutral" marks
that we would have to maintain and would occasionally have to field
requests from users to add them, and those solutions would not work
with older versions of org.

Re: org-fontify-emphasized-text

[Henrik Frisk]

On Mon, Jul 17, 2023, 1:23 PM Ihor Radchenko  wrote:

> Henrik Frisk  writes:
>
> > For the first time I tried to enable the fontification of emphasized text
> > but quickly decided I didn't want it. But I can't seem to get rid of it.
> > For example, any part of a filename that is after an underscore is still
> > printed as subtext (expected if fontification is on). Is there anything
> > else than the above variable that controls this? emacs -Q works of course
> > fine.
>
> Can't get rid even after re-starting Emacs?
>

Exactly, I've had it for weeks annoyingly.

Henrik

>

[BUG] SPACE jumps to tag in header line after hidden emphasis marker [9.7-pre (release_9.6.7-562-g5b6268 @ /home/jschmidt/work/org-mode/lisp/)]

[Jens Schmidt]

[emacs-29]$ ./src/emacs -Q -L ~jschmidt/work/org-mode/lisp/

(org-version nil t)
"Org mode version 9.7-pre (release_9.6.7-562-g5b6268 @ 
/home/jschmidt/work/org-mode/lisp/)"


(setq org-hide-emphasis-markers t)
t

;; assume test.org being absent in cwd
 C-x 4 f  ;; find-file-other-window
 t;; self-insert-command
 e;; self-insert-command
 s;; self-insert-command
 t;; self-insert-command
 .;; self-insert-command
 o;; self-insert-command
 r;; self-insert-command
 g;; self-insert-command
  ;; minibuffer-complete-and-exit
 *;; org-self-insert-command
 SPC  ;; org-self-insert-command
 t;; org-self-insert-command
 e;; org-self-insert-command
 s;; org-self-insert-command
 t;; org-self-insert-command
 C-c C-q  ;; org-set-tags-command
 t;; self-insert-command
 e;; self-insert-command
 s;; self-insert-command
 t;; self-insert-command
  ;; exit-minibuffer
 SPC  ;; org-self-insert-command
 =;; org-self-insert-command
 t;; org-self-insert-command
 e;; org-self-insert-command
 s;; org-self-insert-command
 t;; org-self-insert-command
 =;; org-self-insert-command
 SPC  ;; org-self-insert-command

The final SPC after the closing equal sign lets point jump to before the 
colon of the ":test:" tag.


Most likely, this is not limited to space, but that is just the 
character I most frequently type after closing emphasis.

Re: [BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ilja Kocken]

Ah thanks for the info, I messed up by only looking at C-h f org-num-mode,
and not looking at customize-group. Thank you :)

On Mon, Jul 17, 2023 at 2:35 AM Ihor Radchenko  wrote:

> Ilja Kocken  writes:
>
> > If I have a large org-file with many headings, sometimes it's useful to
> > refer to the heading number that people have commented on in the
> > exported PDF (e.g. for an academic paper). However, when I turn on
> > org-num-mode, this shows a continuous numbering for all the headlines in
> > the file. I have many headings that are not included in my LaTeX export
> > for one reason or another, so the heading numbers don't match.
> >
> > Ideally org-num-mode would not add a number to headings with:
> > * COMMENT heading
> > * heading :nolatex:
> >
> > and perhaps based on whether the ox-extras ignore-headlines is activated
> or not:
> > * heading :ignore:
>
> See `org-num-skip-commented', `org-num-skip-tags', and generally "Org
> Num" staff in M-x customize-group  org-appearance 
>
> Canceled.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <
> https://urldefense.com/v3/__https://orgmode.org/__;!!PvDODwlR4mBZyAb0!XEeAiUVhr0Q9RZmWhARjn77YA5CoMvWp_0cdCN4SZSoWWIvwkhcnL3pWm-LatsWrvi7bI-dium_rKat5o4k$
> >.
> Support Org development at <
> https://urldefense.com/v3/__https://liberapay.com/org-mode__;!!PvDODwlR4mBZyAb0!XEeAiUVhr0Q9RZmWhARjn77YA5CoMvWp_0cdCN4SZSoWWIvwkhcnL3pWm-LatsWrvi7bI-dium_rRQ4SYCU$
> >,
> or support my work at <
> https://urldefense.com/v3/__https://liberapay.com/yantar92__;!!PvDODwlR4mBZyAb0!XEeAiUVhr0Q9RZmWhARjn77YA5CoMvWp_0cdCN4SZSoWWIvwkhcnL3pWm-LatsWrvi7bI-dium_rXK24r_s$
> >
>

Re: Doubt about error messages

[Ihor Radchenko]

Ypo  writes:

> Warning (org-element-cache): org-element--cache: Org parser error in 
> 3-recursos.org::1868222. Resetting.
> ...
> Should I report it in some way? Or as it didn't happen with emacs-q and 
> as I don't know how to reproduce it, I shouldn't bother?

Thanks for reporting!
Yes, the message is asking to report this for a reason - it is one of
the asynchronous parts of Org that is notoriously difficult to debug.
And we need some help from users.

May you please set org-element--cache-self-verify to 'backtrace in your
config and report the very long backtrace that will appear in the
warnings buffer next time you see the error?

(You may consider sending the backtrace privately or cleaning it up, as
it may contain parts of your Org buffer, like heading titles)

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

Doubt about error messages

[Ypo]

Hi

Frequently I receive this kind of messages:

"

Warning (org-element-cache): org-element--cache: Org parser error in 
3-recursos.org::1868222. Resetting.

 The error was: (wrong-type-argument integer-or-marker-p nil)
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x 
org-submit-bug-report). Disable showing Disable logging

"


Should I report it in some way? Or as it didn't happen with emacs-q and 
as I don't know how to reproduce it, I shouldn't bother?



Best regards

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Ihor,

On 14 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


Looks like this on my side as well.


Given the feedback, I went ahead and changed the lilypond.org 
file:


https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


Thanks! It would be even nicer if we allowed 
https://packages.debian.org/buster/lilypond (2.19.81) or at 
least https://packages.ubuntu.com/focal/lilypond (2.20.0).


I also checked what will happen with future versions, and it 
looks like \version "2.24.1" actually means >=.


That's good to know.

I know version 2.20.0 works without the update, so perhaps we 
could set those variables conditionally, WDYT?


\version "2.20"
#(if (ly:get-option 'use-paper-size-for-page)
(begin (ly:set-option 'use-paper-size-for-page #f)
   (ly:set-option 'tall-page-formats 'pdf)))


--
Jonathan

[PATCH] Testing: Add tests for 'org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item'

[Morgan Smith]

* testing/lisp/test-org-agenda.el
(test-org-agenda/check-for-timestamp-as-reason-to-ignore-todo-item):
New test.
---
 testing/lisp/test-org-agenda.el | 56 +
 1 file changed, 56 insertions(+)

diff --git a/testing/lisp/test-org-agenda.el b/testing/lisp/test-org-agenda.el
index c4bd4f0a7..66f2f5bce 100644
--- a/testing/lisp/test-org-agenda.el
+++ b/testing/lisp/test-org-agenda.el
@@ -329,6 +329,62 @@ DEADLINE: <2023-07-15 Sat>"
   "* TODO write better tests"
 (org-agenda-skip-if nil options))
 
+(ert-deftest test-org-agenda/check-for-timestamp-as-reason-to-ignore-todo-item 
()
+  "Test `org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item'."
+  (let ((org-deadline-warning-days 1)
+(expected-return
+ (lambda (timestamp value)
+   (cl-case timestamp
+ (past (not (not (memq value '(past all -1 -2 near)
+ (yesteryesterday (not (not (memq value '(past all -1 -2 near)
+ (yesterday (not (not (memq value '(past all -1 near)
+ (today (not (not (memq value '(all past 0 near)
+ (tomorrow (not (not (memq value '(future all 1 0 near)
+ (tomorroworrow (not (not (memq value '(future all 2 1 0 far)
+ (future (not (not (memq value '(future all 2 1 0 far
+;; Lexically bind the variables we're changing
+org-agenda-todo-ignore-deadlines
+org-agenda-todo-ignore-scheduled
+org-agenda-todo-ignore-timestamp)
+  (org-test-at-time "2023-01-15"
+(dolist (variable '(org-agenda-todo-ignore-deadlines
+org-agenda-todo-ignore-scheduled
+org-agenda-todo-ignore-timestamp))
+  (dolist (type '(timestamp scheduled deadline))
+;; nil is last so it resets the variable for the next one
+(dolist (value `(past future all 2 1 0 -1 -2
+  ,@(when (eq type 'deadline) '(near far 
nil
+  (dolist (timestamp '((past . "<2022-01-15>")
+   (yesteryesterday . "<2023-01-13>")
+   (yesterday . "<2023-01-14>")
+   (today . "<2023-01-15>")
+   (tomorrow . "<2023-01-16>")
+   (tomorroworrow . "<2023-01-17>")
+   (future . "<2024-01-15>")))
+;; Uncomment to debug failure
+;; (message "Type: %S, Variable: %S, Value: %S, Time: %S" type 
variable value (car timestamp))
+(set variable value)
+(should
+ (equal
+  (cl-case variable
+(org-agenda-todo-ignore-deadlines
+ (when (eq type 'deadline)
+   (funcall expected-return (car timestamp) value)))
+(org-agenda-todo-ignore-scheduled
+ (when (eq type 'scheduled)
+   (funcall expected-return (car timestamp) value)))
+(org-agenda-todo-ignore-timestamp
+ (when (eq type 'timestamp)
+   (funcall expected-return (car timestamp) value
+  (org-test-with-temp-text
+  (cl-case type
+(timestamp (concat "* hello " (cdr timestamp)))
+(scheduled (concat "* hello
+SCHEDULED: " (cdr timestamp)))
+(deadline (concat "* hello
+DEADLINE: " (cdr timestamp
+
(org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item)))
+
 (ert-deftest test-org-agenda/goto-date ()
   "Test `org-agenda-goto-date'."
   (unwind-protect
-- 
2.41.0

Re: [BUG] [PATCH] Avoid interaction in test ~ob-tangle/detangle-false-positive~

[Ihor Radchenko]

Evgenii Klimov  writes:

> While it's not applied, may I also ask: I noticed that non-default value
> 'other-frame of =org-src-window-setup= variable in my init.el leads to
> creation of multiple frames during interactive testing.
>
> I understand that testing should be done on ~emacs -Q~ etc, but since
> it's an option to quickly test interactively in the current process
> during development, would you accept the patch where
> =org-src-window-setup= would be set to default value inside the test?

It is not very meaningful.
Tests generally assume default values.
With user config loaded, tests can (and tend to) break randomly.
Sometimes, spectacularly :)

The only proper way to allow running tests while user config is in place
is force-binding _all_ the Org defaults for the duration of the tests.
And even then, custom advices and re-definition may break things.

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

Re: [BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Ilja Kocken  writes:

> If I have a large org-file with many headings, sometimes it's useful to
> refer to the heading number that people have commented on in the
> exported PDF (e.g. for an academic paper). However, when I turn on
> org-num-mode, this shows a continuous numbering for all the headlines in
> the file. I have many headings that are not included in my LaTeX export
> for one reason or another, so the heading numbers don't match.
>
> Ideally org-num-mode would not add a number to headings with:
> * COMMENT heading
> * heading :nolatex:
>
> and perhaps based on whether the ox-extras ignore-headlines is activated or 
> not:
> * heading :ignore:

See `org-num-skip-commented', `org-num-skip-tags', and generally "Org
Num" staff in M-x customize-group  org-appearance 

Canceled.

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

Re: [BUG] [PATCH] Avoid interaction in test ~ob-tangle/detangle-false-positive~

[Evgenii Klimov]

Ihor Radchenko  writes:

> Evgenii Klimov  writes:
>
>> Test ~ob-tangle/detangle-false-positive~ asks for confirmation to kill
>> the buffer, connected to testing/examples/babel.org file, that is
>> modified during the couse of the test.
>>
>> Way to reproduce the bug (from projects main dir):
>
> Thanks!
> Waiting for your copyright assignment before applying.

Thanks, responsible person from FSF just returned from vacation.

While it's not applied, may I also ask: I noticed that non-default value
'other-frame of =org-src-window-setup= variable in my init.el leads to
creation of multiple frames during interactive testing.

I understand that testing should be done on ~emacs -Q~ etc, but since
it's an option to quickly test interactively in the current process
during development, would you accept the patch where
=org-src-window-setup= would be set to default value inside the test?

It took me some time to figure it out, so further developers in the
similar situation could benefit from it.

Re: [BUG] WORG example for ob-lilypond is no longer working as described

[Graham King]

I'm late to this thread, and I might be missing some crucial aspect of the 
problem, but if you just want to integrate lilypond scores and fragments into a 
LaTeX document, and you're able to choose to use Luatex, the lyluatex and 
lilyglyphs packages work beautifully with the latest Lilypond versions.


I can supply a shortish example if you wish, but I'd rather do that off-list 
(i) in case it is not helpful to you, and (ii) to avoid cluttering the lists.

-- Graham

[BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ilja Kocken]

Hi!

If I have a large org-file with many headings, sometimes it's useful to
refer to the heading number that people have commented on in the
exported PDF (e.g. for an academic paper). However, when I turn on
org-num-mode, this shows a continuous numbering for all the headlines in
the file. I have many headings that are not included in my LaTeX export
for one reason or another, so the heading numbers don't match.

Ideally org-num-mode would not add a number to headings with:
* COMMENT heading
* heading :nolatex:

and perhaps based on whether the ox-extras ignore-headlines is activated or not:
* heading :ignore:

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8)
 of 2023-06-05
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/share/emacs/30.0.50/lisp/org/)


-- 
Dr. Ilja J. Kocken | Postdoc Researcher at SOEST | University of
Hawaii at Mānoa | 1000 Pope Road | MSB 504 | Honolulu, HI 96822, USA

Re: [BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ilja Kocken]

I think in the above I may have forgotten that at the bottom of [[
https://github.com/japhir/ArchConfigs/blob/master/myinit.org#reset-gc-cons-threshold][my
config]] I had not uncommented the line that sets the gconf-threshold :O


On Thu, Jul 13, 2023 at 3:43 PM Ilja Kocken  wrote:

> Hi!
>
> If I have a large org-file with many headings, sometimes it's useful to
> refer to the heading number that people have commented on in the
> exported PDF (e.g. for an academic paper). However, when I turn on
> org-num-mode, this shows a continuous numbering for all the headlines in
> the file. I have many headings that are not included in my LaTeX export
> for one reason or another, so the heading numbers don't match.
>
> Ideally org-num-mode would not add a number to headings with:
> * COMMENT heading
> * heading :nolatex:
>
> and perhaps based on whether the ox-extras ignore-headlines is activated
> or not:
> * heading :ignore:
>
> Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.38, cairo version 1.17.8)
>  of 2023-06-05
> Package: Org mode version 9.6.6 (release_9.6.6 @
> /usr/share/emacs/30.0.50/lisp/org/)
>
>
> --
> Dr. Ilja J. Kocken | Postdoc Researcher at SOEST | University of
> Hawaii at Mānoa | 1000 Pope Road | MSB 504 | Honolulu, HI 96822, USA
>

[PATCH worg] ob-doc-python: Use ":results file link" for returning filenames

[~jackkamm]

From: Jack Kamm 

The correct usage for returng filenames as paths is to use the link
header arg.  This updates the ob-doc-python examples to follow this
convention now.  See also:
https://list.orgmode.org/87ttu95xst.fsf@localhost/
---
 org-contrib/babel/languages/ob-doc-python.org | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-python.org 
b/org-contrib/babel/languages/ob-doc-python.org
index 7ee29be5..1012ba56 100644
--- a/org-contrib/babel/languages/ob-doc-python.org
+++ b/org-contrib/babel/languages/ob-doc-python.org
@@ -190,12 +190,12 @@ ret
 ** Graphics
 
 To return plots, save the figure to a file, return the filename, and
-set the header argument =:results file=.
+set the header argument =:results file link=.
 
 For example:
 
 #+begin_example
-#+begin_src python :session :results file
+#+begin_src python :session :results file link
 import matplotlib
 import matplotlib.pyplot as plt
 fig=plt.figure(figsize=(3,2))
@@ -244,7 +244,7 @@ syntax, but to hide the inserted code during export.
 ,#+end_src
 
 ,#+header: :noweb strip-export
-,#+begin_src python :results value file :session :exports both
+,#+begin_src python :results value file link :session :exports both
   import matplotlib, numpy
   import matplotlib.pyplot as plt
   fig=plt.figure(figsize=(4,2))
@@ -327,7 +327,7 @@ return(data[val])
 
   - Plotting
 #+begin_example
-#+begin_src python :results file
+#+begin_src python :results file link
 import matplotlib, numpy
 matplotlib.use('Agg')
 import matplotlib.pyplot as plt
-- 
2.38.5

Re: Can someone dig the reasons behind emphasis regexp limitations?

[Ihor Radchenko]

Ihor Radchenko  writes:

> I keep looking at these rules and remain confused, even though I do
> remember that Nicolas stated good reasons for this.

Ok. So, it was "whatever works".
https://orgmode.org/list/87mtlwt4h8@nicolasgoaziou.fr

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

Org markup and non-ASCII punctuation (was: org parser and priorities of inline elements)

[Ihor Radchenko]

Max Nikulin  writes:

> On 21/11/2021 16:28, Ihor Radchenko wrote:
>> 
>> Also, is there any reason why we are not simply using punctuation
>> character class instead of listing punctuation chars explicitly (and
>> only for English)? What about "_你叫什么名字_？"
>
> It seems punctuation character class is too broad. E.g.
>  ¿ INVERTED QUESTION MARK
> normally appears before words, while "?" is usually after them. I do not 
> see anything special in
>  (category-set-mnemonics (char-category-set ?¿))
> that may help to discriminate such cases.

The last resort is define-category where we can manage exceptions.
But I think that even without distinguishing ?¿, we can improve the
situation for CJK users a lot.

We can probably split character categories into "left", "right", and
"neutral" with "(" being "left" example, ")" being "right" example, and
" " being "neutral" example.
We start from using the information we can extract from Unicode data and
modify it as necessary.

Then, emphasis will be defined as PRE MARKER ... MARKER POST with
PRE = left+neutral category
POST = right+neutral category

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

Re: [ANN] lisp/ob-tangle-sync.el

[Mehmet Tekman]

Hello again!

> Ihor Radchenko  writes:
>
> Two months have passed since the last message in this thread.
> Mehmet, have you had a chance to work on this? May you need any help?

General recap of where we are so far with this patch:

 The tangle-sync mode I wished to implement had some ambiguities
 when resolving `:tangle' headers. This turned out to be a
 general problem for any header that had multiple parameters, so
 the merge-params function was re-written. This introduced some
 ambiguities in itself, so we decided to write a better testing
 framework for it.

> Mehmet Tekman  writes:
>
> ... I will rewrite to to conform to the
> `org-test-with-temp-text' examples.

So I've just rewritten the `merge-params' testing function I
wrote before, this time using the `org-test-with-temp-text'
method/macro.

I seem to be getting 5 failing tests for reasons that I'm not
quite sure why. I've tested it against upstream/main, but still
getting the same errors. Maybe you can try it and see where I'm
going wrong?

The patch does not rely on any previous patches

Best,
Mehmet

On Sun, 16 Jul 2023 at 11:42, Mehmet Tekman  wrote:
>
> Apologies, this patch has been burning in the back of mind for a
> while now, but I keep getting distracted with other random side
> projects.
>
> I appreciate the wake up call, and I will refocus my efforts next
> week in my free time.
>
> Best,
> Mehmet
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index c8dbd44f4..9ba2d09d3 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -314,6 +314,135 @@ this is simple"
 (org-babel-next-src-block)
 (should (= 14 (org-babel-execute-src-block)
 
+
+(ert-deftest test-ob/merge-params ()
+  "Test the output of merging multiple header parameters.  The
+expected output is given in the contents of the source code block
+in each test.  The desired test header parameters are given
+either as a symbol or a list in the `idtest-alist' variable.
+Multiple header parameters must be separated by a newline and
+exactly two spaces in the block contents."
+  (let ((idtest-alist '((inherit-document-header-args
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf
+  (:tangle . /tmp/default_tangle.txt)
+#+end_src")
+(inherit-document-header-with-local-sync-action
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf :tangle skip
+  (:tangle . /tmp/default_tangle.txt skip)
+#+end_src")
+(override-document-header-with-local-tfile
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf :tangle randomfile sync
+  (:tangle . randomfile sync)
+#+end_src")
+(override-document-and-parent-header-with-local-tfile-and-action
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+:PROPERTIES:
+:header-args: :tangle \"newfile.txt\" import
+:END:
+** Two
+#+begin_src conf :tangle randomfile sync
+  (:tangle . randomfile sync)
+#+end_src")
+(test-tangle-and-default-results-param-together
+ (:tangle :results) "\
+* One
+#+begin_src conf  :tangle randomfile
+  (:tangle . randomfile)
+  (:results . replace)
+#+end_src")
+(inherit-document-tfile-take-only-last-local-sync-action
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf  :tangle import export
+  (:tangle . /tmp/default_tangle.txt export)
+#+end_src")
+(ignore-document-header-take-last-tfile-and-sync-action
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf  :tangle fname1 fname2 sync export
+  (:tangle . fname2 export)
+#+end_src")
+(test-results-and-exports
+ (:results :exports) "\
+* One
+#+begin_src sh :results file wrap
+  (:results . wrap file replace)
+  (:exports . code)
+#+end_src")
+(do-not-tangle-this-block
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf :tangle no
+  (:tangle . no)
+#+end_src")
+(test-tangle-exports-and-comments
+ (:tangle :exports :comments) "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+:PROPERTIES:
+:header-args: :tangle no :exports verbatim
+:END:
+#+begin_src conf :tangle \"foo.txt\" :comments link
+  (:tangle . foo.txt)
+  (:exports . verbatim code)
+  (:comments . link)
+#+end_src")
+(override-document-and-heading-tfile-with-yes
+ :tangle "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+:PROPERTIES:
+:header-args: :tangle \"foo.txt\"
+:END:

Re: org-fontify-emphasized-text

[Ihor Radchenko]

Henrik Frisk  writes:

> For the first time I tried to enable the fontification of emphasized text
> but quickly decided I didn't want it. But I can't seem to get rid of it.
> For example, any part of a filename that is after an underscore is still
> printed as subtext (expected if fontification is on). Is there anything
> else than the above variable that controls this? emacs -Q works of course
> fine.

Can't get rid even after re-starting Emacs?

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

org-fontify-emphasized-text

[Henrik Frisk]

Hi,

For the first time I tried to enable the fontification of emphasized text
but quickly decided I didn't want it. But I can't seem to get rid of it.
For example, any part of a filename that is after an underscore is still
printed as subtext (expected if fontification is on). Is there anything
else than the above variable that controls this? emacs -Q works of course
fine.

Thanks
/h

Re: [BUG] org-babel-result-to-file failed when buffer is narrowed [9.7 (9.7-??-f7aa8c1 @ c:/Users/yhht/.config/emacs/.local/straight/build-29.0.60/org/)]

[Ihor Radchenko]

赵一宇  writes:

> Yes you're right.
> The problem exists in indirect buffer, not narrowed buffer, in which 
> base-directory is nil in this case. That's why I wonder if 
>(base-directory (and buffer-file-name
> (file-name-directory base-file-name)))
> should be
>(base-directory (and base-file-name
> (file-name-directory base-file-name)))
> where base-file-name is non-nil.

Makes sense.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c730caf51

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

Re: [BUG] [PATCH] Avoid interaction in test ~ob-tangle/detangle-false-positive~

[Ihor Radchenko]

Evgenii Klimov  writes:

> Test ~ob-tangle/detangle-false-positive~ asks for confirmation to kill
> the buffer, connected to testing/examples/babel.org file, that is
> modified during the couse of the test.
>
> Way to reproduce the bug (from projects main dir):

Thanks!
Waiting for your copyright assignment before applying.

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

Re: [DRAFT PATCH v5] Decouple LANG= and testing (was: Test failure due to LANG)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ruijie Yu  writes:
>
>> Ihor Radchenko  writes:
>>
>>> (let ((org-time-stamp-formats '("%Y-%m-%d" . "%Y-%m-%d %H:%M")))
>>>  (org-element-timestamp-interpreter timestamp nil))
>>
>> Thanks for the pointer.  I have made this into a macro and redid my
>> changes accordingly.  Please also let me know if more work should be
>> dedicated to avoid code duplication in tests (I see a lot of duplication
>> in the portions I touched in testing/lisp/test-org.el).
>
> Thanks!
> Some comments below.

I decided to go ahead and implemented my suggestions myself, after
applying your patches.
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ab9c9732e
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8739a9578
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9730f408c
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=26440689a

Note that I am going through this thread after a reminder to re-check
copyright status. I may still miss some of your other patches.
If you have something pending, you can let me know, so that we do not
wait until my previous scheduling triggers.

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