outline-* -> org-* possible?

[Samuel Wales]

i am running an ancient org version.  i noticed this, referring to an
unknown future-to-mine version.

+backend.  From now on, using =outline-*= functions is strongly
+discouraged when working with Org files.

before i try to upgrade, i'd like to know if possible whether with
this change, org- versions of outline- identifiers were added to make
it possible to substitute org- for outline-, at least in most cases?

in my old version, i am finding functions and variables named
outline-* that have no obvious org-* replacement.  a few do, and a few
can be substituted with no probable issues.  here are examples of
stuff i might in principle be running:

$ grep -oh '(outline-[^) ]*' *.el|sort -u
(outline-back-to-heading
(outline-backward-same-level
(outline-flag-region
(outline-forward-same-level
(outline-hide-subtree
(outline-invisible-p
(outline-mark-subtree
(outline-next-heading
(outline-on-heading-p
(outline-previous-heading
(outline-show-children
(outline-up-heading

thanks.

Re: Is this proper time format?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
 Maybe I'm not explicit enough.  In section 8.1 of the Org 9.6 manual is
 a subsection "Time/Date Range" that *implies* times are supported in
 ranges by the use of words "time" and "timestamp" when, above, you're
 saying they are undefined (unsupported?) for now.  I'm merely saying
 adjust the manual to remove the implication.
>>>
>>> Please check the manual from main branch of Org. It has more text:
>>
>> I disagree. I cloned Org from Savannah and made the attached patch
>> file from the main branch.  First time for me attaching a file to a
>> message.   Does it work for you?
>
> Yes. Though it would be better to attach the diff with proper (.diff or
> .patch) extension.

I hope you saw that I provided a "patch,txt" file in a following message
(forgot about the naming convention -- been a long time...)

> Even better would be providing commit message and formatting the patch
> properly. See https://orgmode.org/worg/org-contribute.html#first-patch
> Not mandatory though - I can format things properly on your behalf.

Thank you.  I haven't "patched" anything on Savannah and assumed I might
have to do the GNU copyright assignment.  For this, I thought it would
be easy for you.

>> -  Two timestamps connected by =--= denote a range.
>> +  Two timestamps connected by =--= denote a date range.  NOTE: time is
>> +  not specified in these timestamps -- just dates,
>
> I'd avoid this NOTE. Time is actually allowed, but agenda does nothing
> with it. But only agenda. The rest of Org will handle date ranges like
> <2023-06-10 Sat 14:00>--<2023-06-12 Mon 18:00> correctly.
>
>> -#+cindex: timestamps
>> -#+cindex: ranges, time
>> -#+cindex: date stamps
>> -#+cindex: deadlines
>> -#+cindex: scheduling
>
> Is there any particular reason why you removed index entries here and
> further in the diff?

No, there isn't.  I think what happened here is that I noticed section
8.1 in org-guide and org-manual were almost (but not quite) the same. I
assumed (incorrectly?) that they were supposed to be the same, but got
out of sync.  So I made my patch to org-guide and then replaced section
8.1 in org-manual with the one from org-guide.  I think these "cindex"
statements got dropped because of that.  If they are important in
org-manual, but not org-guide, then please put them back.

>>A timestamp may contain a /repeater interval/, indicating that it
>>applies not only on the given date, but again and again after
>> -  a certain interval of N hours (h), days (d), weeks (w), months (m),
>> -  or years (y).  The following shows up in the agenda every Wednesday:
>> +  a certain interval of N days (d), weeks (w), months (m), or years
>> +  (y).  The following shows up in the agenda every Wednesday:
>
> Why did you remove hours?

Oh!  Another difference between org-guide and org-manual that came over
in trying to resync the two.

>>For more complex date specifications, Org mode supports using the
>> -  special expression diary entries implemented in the
>> -  [[info:emacs#Special Diary Entries][Emacs Calendar package]][fn:20].
>> -  For example, with optional time:
>> +  special expression diary entries implemented in the Emacs Calendar
>> +  package.  For example, with optional time:
>
> Why did you remove the links and the footnote?

Again, another diff between org-guide and org-manual, :-\

I'm relooking at this patch.  Testing finds that these work in the
timegrid agenda as expected:

* <2023-02-03 Thu 10:00-11:00>--<2023-02-04 Fri 10:00-11:00>
** Can't mark one done -- you have to mark them all done
*** Kind of expected for this form
* <2023-02-03 Thu 10:00-11:00 +1d>
** Can you limit the number of repeats? If so, how?
** Marking it DONE removes current one from agenda
*** reasonable

I have to rethink section 8.1.  With the above in mind, 8.1 is not quite
right, but it's more subtle than I thought.  Not sure how in the weeds
it should get for a user's manual. 

-- 
David Masterson

Re: Where does headline data end for the purpose of `org-adapt-indentation´ == ´headline-data

[Farblos]

On 2023-06-10  22:47, Farblos wrote:

Hang on, that test case is not really clean yet ... -Q disabled my 
load-path additions, of course ... will give it another try ...


No, the test case is good and exactly as described in the mail before 
the previous one, even with "emacs -Q".


Thanks

Re: Where does headline data end for the purpose of `org-adapt-indentation´ == ´headline-data

[Farblos]

On 2023-06-10  22:39, Jens Schmidt wrote:


OK, so I cobbled up Org main with branch emacs-29.


Hang on, that test case is not really clean yet ... -Q disabled my 
load-path additions, of course ... will give it another try ...


Sorry.

Re: Is this proper time format?

[Ihor Radchenko]

David Masterson  writes:

>>> Maybe I'm not explicit enough.  In section 8.1 of the Org 9.6 manual is
>>> a subsection "Time/Date Range" that *implies* times are supported in
>>> ranges by the use of words "time" and "timestamp" when, above, you're
>>> saying they are undefined (unsupported?) for now.  I'm merely saying
>>> adjust the manual to remove the implication.
>>
>> Please check the manual from main branch of Org. It has more text:
>
> I disagree. I cloned Org from Savannah and made the attached patch
> file from the main branch.  First time for me attaching a file to a
> message.   Does it work for you?

Yes. Though it would be better to attach the diff with proper (.diff or
.patch) extension.

Even better would be providing commit message and formatting the patch
properly. See https://orgmode.org/worg/org-contribute.html#first-patch
Not mandatory though - I can format things properly on your behalf.

> -  Two timestamps connected by =--= denote a range.
> +  Two timestamps connected by =--= denote a date range.  NOTE: time is
> +  not specified in these timestamps -- just dates,

I'd avoid this NOTE. Time is actually allowed, but agenda does nothing
with it. But only agenda. The rest of Org will handle date ranges like
<2023-06-10 Sat 14:00>--<2023-06-12 Mon 18:00> correctly.

> -#+cindex: timestamps
> -#+cindex: ranges, time
> -#+cindex: date stamps
> -#+cindex: deadlines
> -#+cindex: scheduling

Is there any particular reason why you removed index entries here and
further in the diff?

>A timestamp may contain a /repeater interval/, indicating that it
>applies not only on the given date, but again and again after
> -  a certain interval of N hours (h), days (d), weeks (w), months (m),
> -  or years (y).  The following shows up in the agenda every Wednesday:
> +  a certain interval of N days (d), weeks (w), months (m), or years
> +  (y).  The following shows up in the agenda every Wednesday:

Why did you remove hours?
  
>For more complex date specifications, Org mode supports using the
> -  special expression diary entries implemented in the
> -  [[info:emacs#Special Diary Entries][Emacs Calendar package]][fn:20].
> -  For example, with optional time:
> +  special expression diary entries implemented in the Emacs Calendar
> +  package.  For example, with optional time:

Why did you remove the links and the footnote?

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

Re: [BUG] org-fold-core--fix-folded-region slows down typing [9.6.6 (release_9.6.6 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Ihor Radchenko]

Visuwesh  writes:

>> You can try to set `org-fold-core-style' to overlays. Or you can try to
>> disable flyspell. Or you can try to disable org-num that adds up to text
>> properties.
>
> What kind of disasters will I invite if I permanently set
> `org-fold-core--ignore-modifications' to t?

1. Auto-unfolding will be broken
2. Some text inserted in the middle of folded regions may remain visible.

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

Re: How to export to the simplest possible HTML?

[Thomas Redelberger]

Dear Marcin and everybody,

I had a similar requirement for "simplest HTML" and have documented (incl. 
source code) how I tackled this under
 http://web222.webclient5.de/doc/swdev/emacs/orgmode/html

In summary, my solution is
- a few settings in init.el:
  + org-html-text-markup-alist similar to below
  + setting org-export-allow-bind-keywords to t
- setting quite some org variables in-buffer/in the org file
- elisp to steer a final XSLT transformation of the generated HTML


I had coded a derived HTML export back-end (for Emacs 25.1) and used it quite 
for some time.
When I moved to Emacs 27.2, the derived back-end did not work any more, hence I 
changed to above approach.

Best regards
Thomas


On 2023-05-30, at 20:48, Marcin Borkowski wrote:


On 2023-05-30, at 17:32, Max Nikulin  wrote:


On 30/05/2023 10:47, Marcin Borkowski wrote:

since I'm going to
call my exporting function in a loop over many elements.  I tried
(org-export-with-backend 'html (org-element-at-point (point)))


There is `org-export-string-as', but likely it is not suitable for
you. My guess is that you are going to export headings (blog posts) to
separate html files.


Correct, dear Holmes. 


This is /italic/.
can become e.g.
This is italic.


I am curious whether  is more friendly to screen readers
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em


Good point.  You're right, I'll probably go with `' then.  (The
reason I wanted `' was that I wan't somewhat atypical styling,
namely letterspace.  But of course css magic can make `' do this,
too.)


I'm considering writing a custom (derived) export backend, but maybe
that is an overkill?  Any ideas?


I just have noticed

(defcustom org-html-text-markup-alist
   '((bold . "%s")
 (code . "%s")
 (italic . "%s")
 (strike-through . "%s")
 (underline . "%s")
 (verbatim . "%s"))
   "Alist of HTML expressions to convert text markup.

You may look into ox-html customizations such as
(:html-doctype "HTML_DOCTYPE" nil org-html-doctype)
(:html-html5-fancy nil "html5-fancy" org-html-html5-fancy)

I have never tried ox-slimhtml:
Laszlo Elo. ox-slimhtml. Mon, 14 Dec 2020 00:48:27
-0500. https://list.orgmode.org/41d2e10d-bcff-4604-8417-b499514af...@bald.cat


Ah, that looks interesting, too.

Thanks!