Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

Bastien  writes:
> Could it slow down agenda generation for some configurations?

Yes, it can. Specifically, fontifying tags can be costly. For
illustration, below if profiler report for a very large agenda buffer
(1468 entries):

19820  95%   - org-agenda
...
4401  21%   - org-agenda-fix-displayed-tags
3711  17%+ org-mode
...
1410   6%  - org-buffer-substring-fontified
1380   6%   + jit-lock-fontify-now
(full profiler report at the end of the message)

The total slowdown is ~30%, though the second part will only be slow
before the headings are fontified first time by
org-buffer-substring-fontified. Subsequent agenda rebuilds will be
faster.

The first part is harder. It is related to tag fontification. Currently,
agenda fetches tag list as unfontified strings via org-get-tags. So, I
had to re-fontify tags manual is temporary org-mode buffer. You can see
that running org-mode in fresh buffer takes a lot of time. Alternative
approach would be modifying org-get-tags to return fontified strings,
but I am not sure if it is safe to do - unrelated parts of org
might be affected. Or I can write something like org-get-tags-fontified.
What do you think?

Best,
Ihor
20147  96% - command-execute
20147  96%  - funcall-interactively
19820  95%   - org-agenda
19820  95%- apply
19820  95% - ad-Advice-org-agenda
19820  95%  - #
19820  95%   - apply
19820  95%- #
19761  94% - call-interactively
19761  94%  - funcall-interactively
19741  94%   - org-todo-list
13331  63%- org-agenda-get-day-entries
13331  63% - apply
13331  63%  - #
13331  63%   - org-agenda-get-todos
13331  63%- apply
13331  63% - #
8115  38%  - org-agenda-format-item
4401  21%   - org-agenda-fix-displayed-tags
3711  17%+ org-mode
409   1%+ font-lock-ensure
161   0%+ org-fold-core--fix-folded-region
40   0%+ #
3554  17%   - eval
3554  17%- format
3554  17% - format
3544  17%  - org-eval
3463  16%   + yant/format-time-balance-multiplier
81   0%   + yant/format-summary-for-agenda
10   0%  + if
40   0% replace-regexp-in-string
10   0% org-get-time-of-day
3185  15%  - org-get-tags
3095  14%   + org-up-heading-safe
20   0% org--get-local-tags
20   0%   + org-before-first-heading-p
10   0%   + mapcar
10   0%   + org-remove-uninherited-tags
1410   6%  - org-buffer-substring-fontified
1380   6%   + jit-lock-fontify-now
362   1%org-get-priority
39   0%org-add-props
20   0%org-get-todo-state
10   0%org-agenda-skip
10   0%replace-regexp-in-string
9   0%org-agenda-new-marker
5400  25%- org-agenda-finalize
2920  14% + org-get-tags
1380   6% + run-hooks
610   2%   org-agenda-fontify-priorities
340   1% + org-agenda-align-tags
30   0% + org-activate-links
20   0% + org-agenda-mark-clocking-task
730   3%+ org-agenda-prepare
150   0%+ org-agenda-finalize-entries
80   0%+ org-fold-core--fix-folded-region
59   0% + org-agenda-get-restriction-and-command

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Timothy]

Hi Nicolas,

So, I've now fixed the handling of already-$-delaminated fragments, and
removed the $$ from around environments.

Sorry to complicate things, but, looking at what the HTML fallback
actually is, I've had some further thoughts. The HTML backend will
either leave the content as-is, run `org-latex-to-html-convert-command',
or run something from `org-preview-latex-process-alist' and include an
.

Should one want to convert LaTeX images say to an SVG for HTML export, I
do not think one would want this behaviour to also apply to LaTeX being
exported to markdown.

As such I see two 'sensible' paths forward: (1) just include LaTeX
verbatim when :with-latex is non-nil, or (2) introduce
`org-markdown-with-latex' which can be set to t/'verbatim or 'html.

In the attached patch, I've taken the first approach. Let me know if
you'd like to take the second approach, or just inherit the HTML
behaviour for LaTeX after all.

--
Timothy

>From a02dbcb21dddb6d9239d13308a78a45738d9b7e6 Mon Sep 17 00:00:00 2001
From: Timothy 
Date: Thu, 1 Apr 2021 00:41:29 +0800
Subject: [PATCH] ox-md: Use TeX-style $ math wrapping

* lisp/ox-md.el (org-md-latex-environment, org-md-latex-fragment):
These two new filters wrap LaTeX maths in $ / $$ TeX-style notation.
While ox-md endeavours to adhere to the original Markdown specification,
and not any particular variant, the original specification does not deal
with LaTeX fragments at all, and so this change does not reduce how
faithfully the original specification is followed.
There is a major upside to this though. Of the many Markdown variants
that have emerged, those that support LaTeX very often exclusively
support TeX style notation.  This change thus improves the utility of
the Markdown export for many use cases, and deviates no more from the
original specification that the current method.
---
 lisp/ox-md.el | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index b6b2c1728..1ae0cf2d9 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -100,6 +100,8 @@ (org-export-define-derived-backend 'md 'html
 		 (italic . org-md-italic)
 		 (item . org-md-item)
 		 (keyword . org-md-keyword)
+ (latex-environment . org-md-latex-environment)
+ (latex-fragment . org-md-latex-fragment)
 		 (line-break . org-md-line-break)
 		 (link . org-md-link)
 		 (node-property . org-md-node-property)
@@ -460,6 +462,35 @@ (defun org-md-keyword (keyword contents info)
 (_ (org-export-with-backend 'html keyword contents info
 
 
+ Latex Environment
+
+(defun org-md-latex-environment (latex-environment contents info)
+  "Transcode a LATEX-ENVIRONMENT object from Org to Markdown.
+CONTENTS is nil.  INFO is a plist holding contextual information."
+  (when (plist-get info :with-latex)
+(let ((latex-frag (org-remove-indentation
+   (org-element-property :value latex-environment)))
+  (label (org-html--reference latex-environment info t)))
+  (if (org-string-nw-p label)
+  (replace-regexp-in-string "\\`.*"
+(format "\\&\nlabel{%s}" label)
+latex-frag)
+latex-frag
+
+ Latex Fragment
+
+(defun org-md-latex-fragment (latex-fragment contents info)
+  "Transcode a LATEX-FRAGMENT object from Org to Markdown.
+CONTENTS is nil.  INFO is a plist holding contextual information."
+  (when (plist-get info :with-latex)
+(let ((frag (org-element-property :value latex-fragment)))
+  (cond
+   ((string-match-p "^(" frag)
+(concat "$" (substring frag 2 -2) "$"))
+   ((string-match-p "^\\[" frag)
+(concat "$$" (substring frag 2 -2) "$$"))
+   (t frag) ; either already $-deliminated or a macro
+
  Line Break
 
 (defun org-md-line-break (_line-break _contents _info)
-- 
2.31.1

Re: Checkboxes in headings - opinions wanted

[Ihor Radchenko]

Arthur Miller  writes:
> ... Example can be seen in attached screenshot from
> my init file where I use org headings to form a list of packages to
> install, and checkboxes to indicate if a package configuration is used
> or not. 

Depending on details of your workflow, you might also use
org-toggle-comment for indication of configuration usage. As a bonus, if
you use literate config, commenting the heading will also disable
tangling for that heading.

Ihor
Best,

Re: <> and ?font-lock? fly-check, ...

[Greg Minshall]

Tom,

>I just checked and it induces a syntax error, which I did not know,
> but turns out to be quite useful because it means that an untangled or
> incorrectly tangled file will fail to run beyond that point. Best!

:)  cheers.

Re: About multilingual documents

[Tom Gillespie]

I like Aleksandar's solution quite a bit because it also works inline
e.g. as src_org[:lang de]{Meine deutsch ist zher schlect!}. In
principle this means that you could leverage the org-babel and org-src
buffer system to get flyspell results in that language in line as well
(though I don't think transporting overlays into the original buffer
has been implemented). Best!
Tom

Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

[Tim Cross]

Timothy  writes:

> Eric S Fraga  writes:
>
>> Is the verse package loaded automatically already?  I did not see any
>> change in the patch to that aspect and when I export a simple test, the
>> package is not loaded.
>
> Wouldn't it be nice if there was something in-between loading the
> kitchen sink and manually adding packages*... [ foreshadowing ;) ]

Will be interesting to see what you are 'foreshadowing'.

Personally, I find the current options pretty flexible with
'org-latex-classes and support for the macro like placeholders
[PACKAGES, DEFAULT_PACKAGES, EXTRA and their negators] and the ability
to add packages with LATEX_HEADER and LATEX_HEADER_EXTRA file options.
I'm often quite surprised how little people seem to take advantage of
'org-latex-classes and the LATEX_CLASS; file option to define custom
document formats. You can easily define an 'empty' class which only
includes packages you add with LATEX_HEADER: or LATEX_HEADER_EXTRA for
example. 

It is with 'tweaking' Latex packages I've seen people get into trouble.
There can often be some unexpected results when you fail to load or load
packages in a different order. Testing is notoriously difficult as you
also need a lot of different test input data to get good coverage and
adequately test the impact changes to loaded Latex packages causes.
Without detailed knowledge of the latex based exporters, it isn't always
obvious how/where specific Latex packages are used. It would be
important to ensure any mechanism designed to make it easier to
customize what packages are loaded that we don't also end up generating
more bug rports about broken export formatting. 

-- 
Tim Cross

Re: Bug: sqlite output truncated?

[Nick Savage]

I can replicate this, it looks like a bug to me.

Looks to me that there's something wrong with the way it is handling 
single quoted strings, since the output is only what is within the 
double quoted strings. I will take a stab at fixing this.


On 5/3/21 6:22 PM, learn orchids wrote:

I am using Org mode version 9.4.5 (9.4.5-73-g4c7696-elpaplus and I have the 
following code snippet. Values in the 'sql' column of the second row is 
truncated. Am I missing something?

#+begin_src sqlite :db /tmp/rip.db  :colnames yes
   drop table if exists testtable;
   create table testtable(id int, sql varchar);
   insert into testtable values (1, "Select id from foo");
   insert into testtable values (2, 'Select "id" from foo');
   select* from testtable;
#+end_src

#+RESULTS: testsql
| id | sql                |
|+|
|  1 | Select id from foo |
|  2 | id                 |

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Tim Cross  writes:

> +1 on this and the list of proposed languages.

Thanks for the feedback.

> Do any of these ob-* files have FSF copyright i.e. author assigned
> copyright to FSF. Just wondering, given the contrib package will live in
> non-gnu repo, if this is something we need to be concerned about or not?

All these ob-*.el files are part of Org core, so they are part of
Emacs and require the authors to sign the FSF papers.

So there is no real problem here.

org-contrib.git contains files with a free software license: most of
them are GPLv3+, a few of them GPVv2(+) and one (or two, from memory)
is using a MIT license.  So there is no blocker for org-contrib.git
to be packaged as a NonGNU package.

> Strikes me there is nothing written in stone here, so if a language
> becomes popular and it has maintainers, we can always review the
> decision to move it 'out' and when justified, move back into core.

Yes - on the other hand, we don't want to move files out of Org's core
too often.

> I think it is good having a clear distinction and the idea that if your
> using a contrib package, it is 'best effort only' and not guaranteed to
> work with the most recent org version compared to 'core', which has an
> expectation it works with most recent org version.

Yes, this is also the idea.  That's why I called for more maintainers
for the ob-*.el files, but we're not there yet, and for now it would
be too drastic IMHO to remove some ob-*.el for which we don't have a
maintainer or we are not 100% sure they are compatible.  But luckily
enough, I don't think backward compatibility problems happen often
with Babel files.

-- 
 Bastien

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Nicolas Goaziou]

Timothy  writes:

> Actually, since writing this patch I'm not sure that $$-surrounding
> \begin{}...\end{} environments is also a good idea. I'm inclined to
> leave this out of the patch.

Sounds good.

> I do rather like the `rx' macro, however I'm not sure that
> (rx bol "\\(") is really an improvement over "^(" in this particular
> case.

True, but I still prefer `rx'. I guess I wrote too many backslashes.
Anyway it's a nitpick. Do whatever you want.

>> Otherwise, it is a macro. We can assume it lives outside math mode. So
>> maybe the "Unrecognized fragment: %S" is in order in that situation. We
>> could also let HTML export back-end deal with it. I don't know what is
>> better.
>
> I'm not sure what to do here either. Perhaps nothing/HTML backend?

I suggest to re-send to HTML backend `org-export-data-with-backend', to
be consistent with the rest of un-handled objects.

> Finally, I think if this case (lone macro) is handled, there aren't any
> possible "Unrecognized fragment"s that could be passed, and so that
> condition would no longer be necessary?

Yup. If you handle $$ $ \( \[ and macros, you're set.

Regards,

Bug: sqlite output truncated?

[learn orchids]

I am using Org mode version 9.4.5 (9.4.5-73-g4c7696-elpaplus and I
have the following code snippet. Values in the 'sql' column of the
second row is truncated. Am I missing something?

#+begin_src sqlite :db /tmp/rip.db  :colnames yes
  drop table if exists testtable;
  create table testtable(id int, sql varchar);
  insert into testtable values (1, "Select id from foo");
  insert into testtable values (2, 'Select "id" from foo');
  select* from testtable;
#+end_src

#+RESULTS: testsql
| id | sql|
|+|
|  1 | Select id from foo |
|  2 | id |

Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Gustavo Barros]

Hi Bastien,

On Mon, 03 May 2021 at 19:26, Bastien  wrote:



well, clearly my mind is dull right now - I pushed another better fix,
but please report any better solution if you have one.



Thank you.

No, not really, I just happened to spot an offending case of the 
previous commit.  Unfortunately, I don't have a silver bullet here.


Gustavo.

Re: Delay all occurences for a heading scheduled with repeater not work.

[Bastien]

Hi,

h...@protonmail.com writes:

> In https://orgmode.org/manual/Deadlines-and-Scheduling.html#
> Deadlines-and-Scheduling
>
> It says:
> "If you want to delay the display of this task in the agenda, use
> ‘SCHEDULED: <2004-12-25 Sat -2d>’: the task is still scheduled on the
> 25th but will appear two days later. In case the task contains a
> repeater, the delay is considered to affect all occurrences; if you
> want the delay to only affect the first scheduled occurrence of the
> task, use ‘--2d’ instead."
>
> With headings below:
> * delay in scheduled with repeater
> ** TODO delay all occurences
>SCHEDULED: <2020-01-30 Thu -1d +2d>
> ** TODO delay only the first occurence
>SCHEDULED: <2020-01-30 Thu --1d +2d>
>
> Both headings display in today's agenda (today is <2020-01-31>).
> Which is correct.
>
> Then both display in agenda of <2020-02-01>.
> Which is not correct for 'delay all occurences'.
> It should display in agenda of <2020-02-02>.

I'm just bumping this thread because this issue is still open, I'll
review it before Org 9.5.

-- 
 Bastien

Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Bastien]

Hi Gustavo,

well, clearly my mind is dull right now - I pushed another better fix,
but please report any better solution if you have one.

Thanks!

-- 
 Bastien

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Mon, May 3, 2021 at 12:42 PM Nicolas Goaziou  wrote:

> Anyway, I suggest to let it nil, and select it at the document level
> instead, with
>
>   #+cite_export: basic bibstyle citestyle

What is the significance of the last two items?

In a CSL implementation like citeproc-el, both are defined in a single style.

Are they defined separately in other systems?

And if the processor is citeproc-org, where does one put the "foo.csl" style?

Bruce

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Tim Cross]

Bastien  writes:

> Hi all,
>
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation
>
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.
>

+1 on this and the list of proposed languages.

Do any of these ob-* files have FSF copyright i.e. author assigned
copyright to FSF. Just wondering, given the contrib package will live in
non-gnu repo, if this is something we need to be concerned about or not?

Strikes me there is nothing written in stone here, so if a language
becomes popular and it has maintainers, we can always review the
decision to move it 'out' and when justified, move back into core.

I think it is good having a clear distinction and the idea that if your
using a contrib package, it is 'best effort only' and not guaranteed to
work with the most recent org version compared to 'core', which has an
expectation it works with most recent org version.

-- 
Tim Cross

Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Gustavo Barros]

Hi Bastien,

On Mon, 03 May 2021 at 17:31, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:

since some time I've been facing a small annoyance in the agenda, as 
when I move point in my weekly agenda to a day which is not the first 
one display and then hit "f" (`org-agenda-later') the agenda buffer 
is 
scrolled up, hiding the top of the buffer, even though there is no 
lack 
of space in the frame to fit the whole window.


Fixed in maint, thanks.


Thank you for looking into this.

But I think the commit, though indeed avoids the reported undue 
scrolling, brings other undesired side effects.  Usually, 
`org-agenda-later' will carry over the current day of the week to the 
next week.  If we call it on Thursday, point will be placed on the same 
week day of the next week.


Just calling `(set-window-start nil 1)' there breaks this regularity. 
It is easy to generate a case where this happens.  Just squeeze the 
height of your window on a "populated" agenda, and choose a day for 
which that day next week won't fit in the window if position 1 is shown, 
and call it from there.


Perhaps doing so before the call to 
`org-agenda-find-same-or-today-or-agenda' would be a possibility? 
(untested)


Best,
Gustavo.

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Victor A. Stoichita]

Le 03 May 2021, Bastien  a écrit :
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.

I happen to be an active user of ob-lilypond. Lilypond is certainly
peripheral to the world of programming languages. It is well established
and active as an equivalent of LaTeX for music though ([1][2][3]).
It comes with built-in support for Emacs [4].

I see no reason to not move ob-lilypond to org-contrib. I understand
that only few of us use it these days. I can’t stand up as a maintainer
since my Lisp skills and my knowledge of org-mode are quite insufficient
for that. I was happy to see that someone submitted a patch for
ob-lilypond in January. I hope that by the time something breaks I’ll be
able to submit a patch myself.

Regards,
Victor

[1] http://lilypond.1069038.n5.nabble.com/

[2]  https://music.stackexchange.com/questions/tagged/lilypond

[3]  https://stackoverflow.com/questions/tagged/lilypond

[4]  
http://lilypond.org/doc/v2.21/Documentation/usage/text-editor-support.html#emacs-mode

Re: <> and ?font-lock? fly-check, ...

[Tom Gillespie]

Hi Greg,
   I just checked and it induces a syntax error, which I did not know,
but turns out to be quite useful because it means that an untangled or
incorrectly tangled file will fail to run beyond that point. Best!
Tom

On Sun, May 2, 2021 at 9:11 PM Greg Minshall  wrote:
>
> Tom, that is quite devious, actually.  thank you very much!  do you
> know, by the way, what flycheck and/or the shell make the "<<&"
> construct out to be?  cheers, Greg
>

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Timothy  writes:

> "community-developed non-core Org stuff that isn't actively maintained".

Yes, and: "In search for maintainers."

> The idea here being to move ob-* for rarely used languages to this repo
> to lessen the maintenance load.

Yes, that's it, thanks for stating it more directly than I did.

-- 
 Bastien

Re: About multilingual documents

[Juan Manuel Macías]

Hi Aleksandar,

Thank you very much for your interesting comments. I think your idea of
applying org-babel to (multi) language support is tremendously
suggestive and, of course, more org-centric. I suppose it could be
applied also to languages within the paragraph by inline blocks... I
really liked what you propose.

Well, I admit that my marks are a bit exotic :-D. The main problem I see
is that they are not as robust as Org's own marks, since they are
controlled by an export filter. Doing some further tests, by the way, I
think it would be better to add the filter to
`org-export-filter-plain-text-functions', instead of
`...final-output-functions'. I also see that it would be convenient to
avoid their expansion in verbatim texts, with a `(unless
(org-in-verbatim-emphasis)...)'.

Anyway, I think (in general terms) it would be interesting for Org to
incorporate some multilingual support and the ability to toggle between
languages in a document, and the idea you propose seems to
me that it makes a lot of sense.

Best regards,

Juan Manuel 

Aleksandar Dimitrov writes:

> Hi Juan,
>
> this sounds very interesting to me, as I, too, mostly write in Org
> and, sometimes write documents in multiple languages, usually with
> different varieties of either Latin or Cyrillic.
>
> I have some suggestions:
>
> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.
>
> I think that the syntax you're suggesting looks good, but I'm not
> sure how well it'd fit into org-mode's ecosystem. I had something in
> mind that was closer to how org-babel works (it's called *babel*
> for a reason, isn't it? :D)
>
> #+begin_src org :lang pl
>   … po polsku
> #+end_src
>
> #+begin_src org :lang de
>   … auf deutsch
> #+end_src
>
>
> This would make use of org-mode's edit special environment function. It
> would make it easier to persuade flyspell to do the right thing. You
> could, perhaps, add
>
> #+LANGUAGE: en
>
> to the parent document, and then org would take care to set the correct
> flyspell language (and the correct macros on LaTeX-export) and change
> these parameters in the special environments.
>
> I'm not 100% sure it should be #+begin_src org, maybe introducing a
> different special environment would be better, say #+begin_lang XX where
> XX is the ISO-code of said language, or the locale (think en_US
> vs. en_GB.)
>
> The drawback, and the clear disadvantage compared to your method is that
> this works great only when the languages are separated by paragraph
> breaks.
>
> Therefore, I think our suggestions might be somewhat orthogonal. Yours
> could be a shorthand syntax for introducing inline foreign-language
> snippets.
>
> What do you think?
>
> Regards,
> Aleks
>
> Juan Manuel Macías writes:
>
>> Hi all,
>>
>> I'm curious to see how other Org users deal with multilingual documents,
>> that is, those documents (for example, philology or linguistics texts)
>> that contain a significant number of online quotes in other languages.
>> Naturally, this makes more sense in the LaTeX backend, since it is
>> convenient to enclose these quotes in a \foreignlanguage command to
>> ensure that LaTeX at least apply the correct hyphenation patterns for
>> words in other languages.
>>
>> Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
>> need to do this when it comes to languages whose script is different
>> from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
>> We can, for example, define Russian and Greek as:
>>
>> #+begin_src latex
>> \babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
>> \babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
>> #+end_src
>>
>> And also the fonts for both languages:
>>
>> #+begin_src latex
>> \babelfont[russian]{rm}{Linux Libertine O}
>> \babelfont[greek]{rm}]{Free Serif}
>> #+end_src
>>
>> For Latin-based scripts it is still necessary enclose the text in the
>> \foreignlanguage command. And now comes the question: how do Org users
>> who work in multilingual documents to obtain this command when exporting
>> to Latex?
>>
>> I usually use macros, which always tend to work fine. But lately I have
>> been testing an alternative markup system using an export filter. The
>> idea would be something like:
>>
>> %(lang) lorem ipsum dolor %()
>>
>> I start from a list of the most used languages:
>>
>> #+begin_src emacs-lisp
>> (langs '(("en" "english")
>>   ("fr" "french")
>>   ("de" "german")
>>   ("it" "italian")
>>   ("pt" "portuguese")))
>> #+end_src
>>
>> And other possible languages that Babel supports can be indicated
>> explicitly, by prepending "--":
>>
>> %(fr) ... %()
>>
>> %(--esperanto) ... %()
>>
>> (If someone wants to try it, I attach a small Org document).
>>
>> Best regards,
>>
>> Juan Manuel
>
>

-- 
--

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi Palak,

Palak Mathur  writes:

> Any reason why we can’t move all ob-* files out into this new repo? 

Yes, that's because Org Babel is a core documented feature of Org that
is not usable without these ob-*.el files.

We want to move out files that are of less importance and for which we
would like maintainance to happen elsewhere than in Org's core.

-- 
 Bastien

Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Bastien]

Hi Gustavo,

Gustavo Barros  writes:

> since some time I've been facing a small annoyance in the agenda, as 
> when I move point in my weekly agenda to a day which is not the first 
> one display and then hit "f" (`org-agenda-later') the agenda buffer is 
> scrolled up, hiding the top of the buffer, even though there is no lack 
> of space in the frame to fit the whole window.

Fixed in maint, thanks.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Palak Mathur]

> On May 3, 2021, at 2:44 PM, Timothy  wrote:
> 
> 
> Palak Mathur  writes:
> 
>> Any reason why we can’t move all ob-* files out into this new repo?
> 
> I trust Bastien will correct me if I'm wrong, but my understanding is
> this isn't a new repo for "miscellaneous Org stuff" more
> "community-developed non-core Org stuff that isn't actively maintained".
> 

Will it not make sense to separate out non-core from the core? 

> The idea here being to move ob-* for rarely used languages to this repo
> to lessen the maintenance load.
> 

In that case ob-groovy.el can be moved out. 

> --
> Timothy

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Timothy]

Palak Mathur  writes:

> Any reason why we can’t move all ob-* files out into this new repo?

I trust Bastien will correct me if I'm wrong, but my understanding is
this isn't a new repo for "miscellaneous Org stuff" more
"community-developed non-core Org stuff that isn't actively maintained".

The idea here being to move ob-* for rarely used languages to this repo
to lessen the maintenance load.

--
Timothy

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Palak Mathur]

> On May 3, 2021, at 1:07 PM, Bastien  wrote:
> 
> Thanks for your reply.
> 
> Timothy  writes:
> 
>> For the future, I'd think Julia actually warrants 1st class inclusion in
>> Org, and I've instigated an effort to write an ob-julia that works well.
>> More on this once it reaches a usable state.
> 
> Great, I suggest we delete ob-julia.el from org-contrib when we can
> point to this new version.
> 
>> Just going from the fact I haven't heard of them, perhaps ob-groovy.el,
>> ob-io.el, and ob-shen.el may be worth adding to the list?
> 
> I agree ob-shen.el should probably move.
> For ob-io.el, I was perhaps too impressed by their website.
> For ob-groovy.el, I believe Groovy is quite actively used out there.
> 
> But I'll add these three to the "maybe" list.
> 
> Thanks,

Any reason why we can’t move all ob-* files out into this new repo? 


> -- 
> Bastien

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Bastien]

Hi Steven,

"Steven Bagley"  writes:

> Yes, that works for the example I quoted. The source of the original
> "::" is org-mac-link, not my typing. Maybe that could insert a
> different character sequence to avoid any confusion.

can you propose a patch for this?  

-- 
 Bastien

Re: Commit message instructions on the website

[Jeremie Juste]

Hello Bastien,

On Monday,  3 May 2021 at 10:27, Bastien wrote:
> Hi Jeremie,
>
> I pushed a fix for this (though a little bit before I read your public
> message here) - let me know if it needs to be enhanced.
It's good enough for me. Many thanks again

Best regards,
-- 
Jeremie Juste

Re: About multilingual documents

[Joost Kremers]

[Not directly related to the OP, but might be useful to know.]

On Mon, May 03 2021, Aleksandar Dimitrov wrote:
> this sounds very interesting to me, as I, too, mostly write in Org
> and, sometimes write documents in multiple languages, usually with
> different varieties of either Latin or Cyrillic.
[...]
> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.

flyspell is basically just ispell, and ispell can be configured with different
backends. One possible backend is hunspell, which allows you to set multiple
dictionaries. So if you regularly use different languages in a buffer, you
should give hunspell a try.

[...]
> The drawback, and the clear disadvantage compared to your method is that
> this works great only when the languages are separated by paragraph
> breaks.

If that is the case, you could also check out the =guess-language= package:
. It tries to detect the
language of the current paragraph and sets the ispell (and hence flyspell)
dictionary accordingly. I use it because I write in three different languages,
but usually don't mix them in one buffer.



-- 
Joost Kremers
Life has its moments

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Steven Bagley]

Yes, that works for the example I quoted. The source of the original "::" is 
org-mac-link, not my typing. Maybe that could insert a different character 
sequence to avoid any confusion.

--Steve

On Mon, May 3, 2021, at 10:30, Nicolas Goaziou wrote:
> "Steven Bagley"  writes:
> 
> > I am aware of the meaning of "::". Is this a design decision or an
> > implementation constraint? My intuition, obviously wrong here, is that
> > link, being a special kind of object, should have priority over what
> > amounts to a formatting command.
> 
> - ... :: is also a special kind of syntax. It starts before the link
>   (and being a block element, it even has priority over link).
> 
> Have you tried the solution I gave you?
> 
> Regards,
> 

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Russell Adams  writes:

> Arthur,
>
> Could you just use unicode checkbox symbols instead of TODO and DONE?
>
> https://kdr2.com/tech/emacs/1405-orgmode-checkbox-unicode.html
>
> That ought to be just a string, and need no patch.

No, I am sorry, that is completely off.

I have done this minor mode to make it independent of TODO states. Just
replacing TODO and DONE (as I already did as described in other thread 2
days ago), is effectively locking TODO to ack as checkboxes. I would
like to be able to use TODO states together with a checkbox,
independently of each other, so no, I need something more general then
just renamed todo states.

Also unicode will depend on some font to be installed, I don't want to pay
that dependency, since I am using this for my init file.

By the way, this is not a patch, this is a small minor mode that can be
installed and enabled/disabled like an extra package.

By the way, there is a widghet.el library included in Emacs, if I wanted
to use checkboxes as in screenshot there, I could use that library, but
that would be much more involved than those few lines to write the code
I attached in first mail.

> On Mon, May 03, 2021 at 09:00:40AM +0200, Arthur Miller wrote:
>
>>
>> Last night I have been playing with a minor mode to enable a checkbox in
>> a heading, or rather to fake a checkbox. To be honest, it was a 10
>> minute job. Took me way moare time to figure out avialable key
>> combination to use (which I didn't found).
>>
>> In general, enable mode and use S+up/down to toggle a checkbox. A
>> heading with a checkbox is of form [ \t]*\\*+.*? followed by a [ ] or
>> [x] before a heading. It means a [ ] can be placed somewhere after the
>> leading stars, whitespaces ignored.
>>
>> This has nothing todo with my previous hacks of todo keywords. This one
>> does not uses todo states at all so it can be used with todo states.
>>
>> It is just a small prototype. I will use something else than
>> replace-string later on.
>>
>> Just wonder if the approach is sane.
>>
>> There is also a repo on gh for interested one:
>>
>> https://github.com/amno1/org-heading-checkbox

>
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Timothy]

Nicolas Goaziou  writes:

> This sounds reasonable.

I'm glad to hear that!

>> +(defun org-md-latex-environment [...]
> Nitpick: I would use `format', also the final newline character is
> useless, since it will be removed later during the export process.

Actually, since writing this patch I'm not sure that $$-surrounding
\begin{}...\end{} environments is also a good idea. I'm inclined to
leave this out of the patch.

>> + Latex Fragment
>> +
>> +(defun org-md-latex-fragment (latex-fragment contents info)
>> +  "Transcode a LATEX-FRAGMENT object from Org to Markdown.
>> +CONTENTS is nil.  INFO is a plist holding contextual information."
>> +  (when (plist-get info :with-latex)
>> +(let ((frag (org-html-latex-fragment contents info)))
>> +  (cond
>> +   ((string-match-p "^(" frag)
>> +(concat "$" (substring frag 2 -2) "$"))
>> +   ((string-match-p "^\\[" frag)
>> +(concat "$$" (substring frag 2 -2) "$$"))
>> +   (t (message "unrecognised fragment: %s" frag)
>> +  frag)
>
> Nitpick: I suggest to use `rx' macro. It really makes the code base
> a better place.

I do rather like the `rx' macro, however I'm not sure that
(rx bol "\\(") is really an improvement over "^(" in this particular
case.

> You are missing some cases. The fragment could be $...$ or $$...$$
> already, so you can return it as-is without sending the message.

Ah yep, after getting your thoughts on this message I'll send a revised
patch with fixes this (along with any other changes).

> Otherwise, it is a macro. We can assume it lives outside math mode. So
> maybe the "Unrecognized fragment: %S" is in order in that situation. We
> could also let HTML export back-end deal with it. I don't know what is
> better.

I'm not sure what to do here either. Perhaps nothing/HTML backend?

Finally, I think if this case (lone macro) is handled, there aren't any
possible "Unrecognized fragment"s that could be passed, and so that
condition would no longer be necessary?

--
Timothy.

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Thanks for your reply.

Timothy  writes:

> For the future, I'd think Julia actually warrants 1st class inclusion in
> Org, and I've instigated an effort to write an ob-julia that works well.
> More on this once it reaches a usable state.

Great, I suggest we delete ob-julia.el from org-contrib when we can
point to this new version.

> Just going from the fact I haven't heard of them, perhaps ob-groovy.el,
> ob-io.el, and ob-shen.el may be worth adding to the list?

I agree ob-shen.el should probably move.
For ob-io.el, I was perhaps too impressed by their website.
For ob-groovy.el, I believe Groovy is quite actively used out there.

But I'll add these three to the "maybe" list.

Thanks,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Timothy]

This is only tangentally related, but this feels like a relevant place
to mention this and I don't think it deserves its own thread.

I think it's also worth considering deleting ob-julia.el from
org-contrib. Not to put to fine a point on things, but it's currently
dysfunctional. Trying to execute any code in a session causes Emacs to
freeze. Simply put, it was written for pre-1.0 Julia and is no longer
fit for purpose.

For the future, I'd think Julia actually warrants 1st class inclusion in
Org, and I've instigated an effort to write an ob-julia that works well.
More on this once it reaches a usable state.

-

Regarding your the list of proposed files to move to org-contrib, I
concur that they fall under the bar you're setting.

Just going from the fact I haven't heard of them, perhaps ob-groovy.el,
ob-io.el, and ob-shen.el may be worth adding to the list?

--
Timothy

Bastien  writes:

> Hi all,
>
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation
>
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.
>
> Since I can obviously not decide alone about "well-established", would
> you mind giving your advice on whether the files above can be moved to
> org-contrib?  (Of course we would advertize this carefully.  And also,
> there is absolutely nothing personal about perhaps moving *your* file
> out of Emacs, it's just that maintainance will be easier outside.)
>
> Are there any other?
>
> I'll leave this thread open during this week, no need to rush here.
>
> Thanks,

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

FYI, I implemented support for the org-cite syntax and the core styles
that I think will likely end up in citeproc-org, on the `org-cite`
branch, represented by this PR.

https://github.com/bdarcus/bibtex-actions/pull/113

So if you run the 'bibtex-actions-insert-citations' command and select
one or more references, it will prompt you for the prefix and style,
and insert the correct cite syntax in the document.

And, of course, the 'new-org-cite' branch of org will immediately
recognize it as a citation!

This is the command I'm using to test the two together, with the
latter two loaded from the bibtex-actions repo:

emacs -Q -l cite-init.el -l ../bibtex-actions/test/install.el -l
../bibtex-actions/test/bibtex-actions.el

I still haven't managed to get the processor configured though.

Bruce

Re: About multilingual documents

[Greg Minshall]

Aleks, et al.,

> Apart from the export, one of my biggest gripes is
> flyspell. Specifically, the fact that you have to choose one language to
> spell check the entire document with. That is insufficient in my case.

in case it's relevant:

i also switch between languages.  but, for me (maybe i'm missing
something?) it means i switch input methods.  so, i've code bound to
(toggle-input-method) that, depending on the input method, changes the
dictionary "for" that input method.  this is not org-specific, but,
rather, works for all my emacs buffers.

cheers, Greg

Re: [PATCH] lisp/ox-html.el: Move the space after exported section number

[Bastien]

Hi Mingkai,

thanks a lot for the analysis and the diff, it helps a lot.

I pushed this change:
https://code.orgmode.org/bzg/org-mode/commit/dfdd5cd0

Keeping the headline numbering consistent with the TOC numbering seems
the right thing to do here.

Thanks!

-- 
 Bastien

Re: prettify-symbols-mode in org agenda?

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> William Xu  writes:
>
>> Now I try to test it extensively. Even with all your changes, I find
>> when I use org-agenda-todo to change the todo-state inside the agenda
>> buffer, the new state isn't always prettified. 
>>
>> Do you see the same behaviour? 
>
> Oops. Yes, I do see the same behaviour. I only did light testing on
> master and I had some unrelated changes nullifying the problem you
> observe on my testing branch.

Thank you very much for the patch.

Could it slow down agenda generation for some configurations?

> See the updated patch.
>
> From 06a2d8ab328721835866bf97f0344cce15cd1dee Mon Sep 17 00:00:00 2001
> Message-Id: 
> <06a2d8ab328721835866bf97f0344cce15cd1dee.1619960107.git.yanta...@gmail.com>
> From: Ihor Radchenko 
> Date: Sat, 1 May 2021 20:09:10 +0800
> Subject: [PATCH] Make sure that fontification is preserved in agenda
>
> Preserve fontification and composition of headlines and tags in
> agenda.  If the headlines/tags are not yet fontified when building
> agenda, make sure that they are fontified in the original Org mode
> buffers first.
>
> In addition, tags alignment is now done pixelwise to avoid alignment
> issues with variable-pitch symbols that may appear in fontified Org
> mode buffers.  The alignment is utilising :align-to specification,
> which means that the alignment will be automatically updated as the
> agenda buffer is resized.

Please move the comments after the change log themselves.

> * lisp/org-macs.el (org-string-width): Refactor old code and add
> optional argument to return pixel width.  The old code used manual
> parsing of text proerpties to find which parts of string are visible.
> The new code defers this work to Emacs display engine via
> `window-text-pixel-size'.  The visibility settings of current buffer
> are taken into account.
>
> (org-buffer-substring-fontified): New function getting fontified
> substring from current buffer.
>
> * lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
> org-agenda-get-deadlines, org-agenda-get-scheduled): Use
> org-buffer-substring-fontified to get fontified heading.
>
> (org-agenda-fix-displayed-tags): Fontify tags.
>
> (org-agenda-highlight-todo): Preserve composition property used,
> i.e. by `prettify-symbols-mode'.  The composition is usually set to be
> removed on text change, so we do the changes inside
> `with-silent-modifications'.
>
> (org-agenda-align-tags): Use pixel width and (space . :align-to)
> 'display property to align tags in agenda.
>
> * lisp/org.el (org-get-heading): Make sure that heading is fontified.
> ---
>  lisp/org-agenda.el |  63 --
>  lisp/org-macs.el   | 108 ++---
>  lisp/org.el|   2 +
>  3 files changed, 85 insertions(+), 88 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index bd9d466a6..5add0e092 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -5562,7 +5562,7 @@ (defun org-agenda-get-todos ()
> ts-date-pair (org-agenda-entry-get-agenda-timestamp (point))
> ts-date (car ts-date-pair)
> ts-date-type (cdr ts-date-pair)
> -   txt (org-trim (buffer-substring (match-beginning 2) (match-end 
> 0)))
> +   txt (org-trim (org-buffer-substring-fontified (match-beginning 2) 
> (match-end 0)))

Here and for the rest of the patch: please try to keep lines below 80
characters.  I'm aware this is not always feasible, especially given
long functions with many nested s-exps, but let's try to come as close
as possible to 80.

Thanks!

-- 
 Bastien

Re: [PATCH] avoid loading major modes when exporting to file

[Bastien]

Hi Timothy,

Timothy  writes:

> I haven't responded to this concern, because I haven't been able to
> conceive of a single situation where loading the normal-mode for the
> exported file could be desirable.

Well, I could not come up with it either.

Applied in master with commit ec6d1df9b, together with tiny changes in
the commit message.

Thanks!

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> This is another update about the status of the patch.

Thank you *very much* for this work and sorry for the slow reply.

I urge everyone to test this change, as I'd like to include it in
Org 9.5 if it's ready.

I will test this myself this week and report.

Thanks!

-- 
 Bastien

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Nicolas Goaziou]

"Steven Bagley"  writes:

> I am aware of the meaning of "::". Is this a design decision or an
> implementation constraint? My intuition, obviously wrong here, is that
> link, being a special kind of object, should have priority over what
> amounts to a formatting command.

- ... :: is also a special kind of syntax. It starts before the link
  (and being a block element, it even has priority over link).

Have you tried the solution I gave you?

Regards,

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> I've had a short play with this.  Looks nice!

Thank you!

> A few points:
>
> 1. if the BiBTeX entry has, for instance, \& to escape the & for use
>with LaTeX, org translates the \ to $\backslash$ and then the &
>causes a problem compiling the resulting LaTeX.

Oops. I'll fix it in a few hours. I need to treat LaTeX-derived
back-ends specially in the context of BibTeX files. 

I'll let you know when it's done.

> 2. the suppressed author case does not seem to work.

As noted by Bruce D'Arcus, there is no more suppressed author shortcut.
You can use "year" style instead.

> 3. if I cite a paper with many authors, *all* of them get listed.  It
>would be useful to have some control over this, asking, for instance,
>for only the first or the first N to be listed in the citation (but
>all of them in the bibliography).

I don't know how to do that cleanly. However, I think this is already
too smart a feature for "basic" back-end. So, I'd like to punt on this
one.

Regards,
-- 
Nicolas Goaziou

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> So if I want to add to that mini-init file the config so that the
> basic processor is correctly setup, what am I doing wrong here?
>
> (setq org-cite-activate-processor 'basic
>   org-cite-follow-processor 'basic
>   org-cite-export-processor 'basic)

You need to (require 'oc-basic), otherwise, the `basic' processor is not
registered.

Moreover, `org-cite-export-processor' expects a more complex value than
the other variables. At the bare minimum, it should be '(basic).

Anyway, I suggest to let it nil, and select it at the document level
instead, with

  #+cite_export: basic bibstyle citestyle

syntax.

> Once I have that working, what sort of feedback are you most
> interested in from testers?

There is not much to test anyway. It boils down to trying the various
styles, with bibliography files containing entries of different types.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] lisp/ox-html.el: Move the space after exported section number

[Mingkai Dong]

Hi Bastien,

At the end of the mail is the output of `diff old.html new.html`, most
differences are caused by time and randomly generated ids.

The only exception is the Table-of-Content entries, which now has two
spaces before each section title. I find that the org-html--format-toc-headline
function first appends “. “ after each section number, and then appends
the output of html-format-headline-default-function. Thus, after moving
the space to the head of html-format-headline-default-function, there are
two spaces.

Then the problem becomes more complicated, and it might be difficult to solve
it without changing the original behavior.

I can come up with three options:

1. Stay with the two spaces in ToC, since extra spaces seldom change the
   appearance of rendered html. But it would cause problems when users use
   custom org-html-format-headline-function.

2. Further modify the org-html--format-toc-headline function to remove
   the logic of appending “. “ as below. Then the section heading in both
   the text and the ToC will have the format of “1 Section-Text”, without
   “.”. However, this changes the original appearance of ToC.

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index f2ce71f68..a17445ca5 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2396,8 +2396,7 @@ INFO is a plist used as a communication channel."
(concat
 (and (not (org-export-low-level-p headline info))
  (org-export-numbered-headline-p headline info)
- (concat (mapconcat #'number-to-string headline-number ".")
- ". "))
+ (mapconcat #'number-to-string headline-number "."))
 (apply (plist-get info :html-format-headline-function)
todo todo-type priority text tags :section-number nil)



3. Based on the second solution, further update the 
org-html-format-headline-default-function
   to append “. “ by default (rather than “ “) like below. This keeps the
   original ToC content unchanged, but changes the default in-text section
   heading format by appending one more “.” after the section number.


diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index f2ce71f68..84da95ddb 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2396,8 +2396,7 @@ INFO is a plist used as a communication channel."
(concat
 (and (not (org-export-low-level-p headline info))
  (org-export-numbered-headline-p headline info)
- (concat (mapconcat #'number-to-string headline-number ".")
- ". "))
+ (mapconcat #'number-to-string headline-number "."))
 (apply (plist-get info :html-format-headline-function)
todo todo-type priority text tags :section-number nil)

@@ -2696,7 +2695,7 @@ See `org-html-format-headline-function' for details."
   (let ((todo (org-html--todo todo info))
(priority (org-html--priority priority info))
(tags (org-html--tags tags info)))
-(concat " "
+(concat ". "
todo (and todo " ")
priority (and priority " ")
text


Both option 2 and 3 give users better control over of the section heading
format, but will alter the current behavior of html export.

What do you think?


- - - - Below is the diff of generated HTML - - - -


4c4
< 
---
> 
228,231c228,231
< 1. Terms
< 2. TME
< 3. MKTME
< 4. Configuration
---
> 1.  Terms
> 2.  TME
> 3.  MKTME
> 4.  Configuration
233c233
< 4.1. Exclusion Range MSRs
---
> 4.1.  Exclusion Range MSRs
236,237c236,237
< 5. Runtime Behavior
< 6. 管理 KeyID
---
> 5.  Runtime Behavior
> 6.  管理 KeyID
239c239
< 6.1. Guidance
---
> 6.1.  Guidance
254,255c254,255
< 
< 1 Terms
---
> 
> 1 Terms
264,265c264,265
< 
< 2 TME
---
> 
> 2 TME
276c276
< 
---
> 
289,290c289,290
< 
< 3 MKTME
---
> 
> 3 MKTME
308c308
< 
---
> 
326,327c326,327
< 
< 4 Configuration
---
> 
> 4 Configuration
334,335c334,335
< 
< 4.1 Exclusion Range 
MSRs
---
> 
> 4.1 Exclusion Range 
> MSRs
356,357c356,357
< 
< 5 Runtime 
Behavior
---
> 
> 5 Runtime 
> Behavior
364c364
< 
---
> 
390,391c390,391
< 
< 6 管理 KeyID
---
> 
> 6 管理 KeyID
400,401c400,401
< 
< 6.1 Guidance
---
> 
> 6.1 Guidance
418c418
< Created: 2021-05-03 Mon 23:53
---
> Created: 2021-05-03 Mon 23:56


Best,
Mingkai


> On May 3, 2021, at 23:31, Bastien  wrote:
> 
> Hi Mingkai,
> 
> Mingkai Dong  writes:
> 
>> * ox-html.el (org-html-headline, org-html-format-headline-default-function):
>> delete the space after the section number span format and add it back in
>> org-html-format-headline-default-function.
> 
> It looks good, thanks.
> 
> Can you show the exact difference by comparing the relevant HTML
> portion before and after this change?
> 
> -- 
> Bastien

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Steven Bagley]

I am aware of the meaning of "::". Is this a design decision or an 
implementation constraint? My intuition, obviously wrong here, is that link, 
being a special kind of object, should have priority over what amounts to a 
formatting command.

Thanks.

--Steve

On Mon, May 3, 2021, at 08:59, Nicolas Goaziou wrote:
> Hello,
> 
> Bastien  writes:
> 
> > Hi Steven,
> >
> > "Steven Bagley"  writes:
> >
> >> In emacs -Q:
> >>
> >> 1. M-x org-mode
> >> 2. insert the following line in the buffer (created by
> >> org-mac-grab-link)
> >>
> >> - [[https://rgoswami.me/posts/org-note-workflow/][An Orgmode Note
> >>   Workflow :: Rohit Goswami  Reflections]]
> >>
> >> 3. You can't follow the link using mouse-left because of the "::" in
> >> the link, which makes that line into an org "description list
> >> item". The message is "No link found".
> >
> > Confirmed, thanks for the reproducible recipe.
> 
> An item bullet followed by two colons is a special syntax in Org. It has
> precedence over the link.
> 
> Besides saying "don't do that", the usual trick is to insert a zero
> width space between the two colons.
> 
> Regards,
> -- 
> Nicolas Goaziou
> 

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Nicolas Goaziou]

Hello,

Timothy  writes:

> I anticipate that this change may be somewhat contentions because ox-md
> explicitly follows only the original Markdown spec from 2003, however
> I've thought this over and come to the conclusion that this change is
> still in keeping with that, and beneficial.
>
> Currently ox-md simply inherits the output from ox-html's handling of
> LaTeX snippets. Needless to say, the original Markdown specification
> does not mention LaTeX snippets. As such, by subtly tweaking the output
> (either adding $$ or substituting out LaTeX-style \(\) / \[\] for $ /
> $$) we are not deviating from the original specification any more than we
> already are.

This sounds reasonable.

> +(defun org-md-latex-environment (latex-environment contents info)
> +  "Transcode a LATEX-ENVIRONMENT object from Org to Markdown.
> +CONTENTS is nil.  INFO is a plist holding contextual information."
> +  (when (plist-get info :with-latex)
> +(concat "$$\n"
> +(org-html-latex-environment latex-environment contents info)
> +"$$\n")))

Nitpick: I would use `format', also the final newline character is
useless, since it will be removed later during the export process.

> + Latex Fragment
> +
> +(defun org-md-latex-fragment (latex-fragment contents info)
> +  "Transcode a LATEX-FRAGMENT object from Org to Markdown.
> +CONTENTS is nil.  INFO is a plist holding contextual information."
> +  (when (plist-get info :with-latex)
> +(let ((frag (org-html-latex-fragment contents info)))
> +  (cond
> +   ((string-match-p "^(" frag)
> +(concat "$" (substring frag 2 -2) "$"))
> +   ((string-match-p "^\\[" frag)
> +(concat "$$" (substring frag 2 -2) "$$"))
> +   (t (message "unrecognised fragment: %s" frag)
> +  frag)

Nitpick: I suggest to use `rx' macro. It really makes the code base
a better place.

You are missing some cases. The fragment could be $...$ or $$...$$
already, so you can return it as-is without sending the message.

Otherwise, it is a macro. We can assume it lives outside math mode. So
maybe the "Unrecognized fragment: %S" is in order in that situation. We
could also let HTML export back-end deal with it. I don't know what is
better.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Hi Steven,
>
> "Steven Bagley"  writes:
>
>> In emacs -Q:
>>
>> 1. M-x org-mode
>> 2. insert the following line in the buffer (created by
>> org-mac-grab-link)
>>
>> - [[https://rgoswami.me/posts/org-note-workflow/][An Orgmode Note
>>   Workflow :: Rohit Goswami  Reflections]]
>>
>> 3. You can't follow the link using mouse-left because of the "::" in
>> the link, which makes that line into an org "description list
>> item". The message is "No link found".
>
> Confirmed, thanks for the reproducible recipe.

An item bullet followed by two colons is a special syntax in Org. It has
precedence over the link.

Besides saying "don't do that", the usual trick is to insert a zero
width space between the two colons.

Regards,
-- 
Nicolas Goaziou

Re: Checkboxes in headings - opinions wanted

[Russell Adams]

Arthur,

Could you just use unicode checkbox symbols instead of TODO and DONE?

https://kdr2.com/tech/emacs/1405-orgmode-checkbox-unicode.html

That ought to be just a string, and need no patch.

On Mon, May 03, 2021 at 09:00:40AM +0200, Arthur Miller wrote:

>
> Last night I have been playing with a minor mode to enable a checkbox in
> a heading, or rather to fake a checkbox. To be honest, it was a 10
> minute job. Took me way moare time to figure out avialable key
> combination to use (which I didn't found).
>
> In general, enable mode and use S+up/down to toggle a checkbox. A
> heading with a checkbox is of form [ \t]*\\*+.*? followed by a [ ] or
> [x] before a heading. It means a [ ] can be placed somewhere after the
> leading stars, whitespaces ignored.
>
> This has nothing todo with my previous hacks of todo keywords. This one
> does not uses todo states at all so it can be used with todo states.
>
> It is just a small prototype. I will use something else than
> replace-string later on.
>
> Just wonder if the approach is sane.
>
> There is also a repo on gh for interested one:
>
> https://github.com/amno1/org-heading-checkbox



--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: [PATCH] lisp/ox-html.el: Move the space after exported section number

[Bastien]

Hi Mingkai,

Mingkai Dong  writes:

> * ox-html.el (org-html-headline, org-html-format-headline-default-function):
> delete the space after the section number span format and add it back in
> org-html-format-headline-default-function.

It looks good, thanks.

Can you show the exact difference by comparing the relevant HTML
portion before and after this change?

-- 
 Bastien

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Timothy  writes:

> Bastien  writes:
>> For now you can use statistics cookies in headline:
>> https://orgmode.org/manual/Checkboxes.html
>>
>> What would perhaps make sense would be to support [ ]/[X] on top of
>> the already supported [0%]/[100%] and [0/n]/[n/n].
>
> I've always used
> * TODO heading [/]
>
> as a substitute for
> + [  ] task [/]
>
> Other than it not automatically switching to done upon reaching 100%,
> I've been pretty happy with this.
>
> Just my 2c.

I am affraid I am not that familiar with org-mode to note what you are
suggesting there :-). I am sorry, it is on my.

What I needed as I just wrote in answer to Bastien, is something
independent of TOTO states, so I can use it side by side with TODO
labels. I am not sure how your proposal fits into that, but that is
mostly because I am really not very good with org-mode.

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Bastien  writes:

> Hi Arthur,
>
> Arthur Miller  writes:
>
>> Last night I have been playing with a minor mode to enable a checkbox in
>> a heading, or rather to fake a checkbox.
>
> Interesting, thanks.
>
> For now you can use statistics cookies in headline:
> https://orgmode.org/manual/Checkboxes.html
>
> What would perhaps make sense would be to support [ ]/[X] on top of
> the already supported [0%]/[100%] and [0/n]/[n/n].
>
> What do you think?  (I tried your mode and unless I didn't try it
> correctly, it does not seem to do that.)

Indeed, it does not do that :). It was explicitly designed to work
independently of TODO tasks/progress, so I can use it side by side with
TODO labels. With other words I just needed a plain old GUI-style
checkbox to indicate on/off value. As I understand stats checkboxes are
displaying progress based on TODO tasks and list checkboxes, so they can
not be used independently of TODO states. Maybe I am wrong, I never used
them to be honest, so I am not sure how much and what is possible there.

Anyway, I am not sure how interesting is this to a wider org-mode
community. Org-mode seems to be geared mostly toward process tracking
which is of course great for project and tasks tracking. However, I see
lots of useful things in org-mode outside of project tracking for some
other strucutured data. Example can be seen in attached screenshot from
my init file where I use org headings to form a list of packages to
install, and checkboxes to indicate if a package configuration is used
or not. 

I was able to re-purpose TODO keywords to act as checkboxes, the other
day, and it worked very well, I can "switch on/off states" with
S-left/right arrows, and I was able to disable initial and done states,
so arrows just shift between [x] and [ ] states. But that locks todo
states to this particular sequence. If I would like to be able to use
TODO states in their normal context, I can't. I needed a more "general
purpose" checkbox, so I wrote that small minor mode.

The biggest problem is, I am not sure how to connect a function per
checkbox in some convenient and simple to use way yet, I am still
thinking what would be the easiest way to add programmability, and I am
not sure why empty checkbox losses fontification.

[PATCH] lisp/ox-html.el: Move the space after exported section number

[Mingkai Dong]

* ox-html.el (org-html-headline, org-html-format-headline-default-function):
delete the space after the section number span format and add it back in
org-html-format-headline-default-function.

The requirement is well described in the reddit post
https://www.reddit.com/r/emacs/comments/bv8rli/org_mode_export_section_numbering/
which can be solved by setting the org-html-format-headline-function
variable to a custom function that adds the "." before the section title.
However, this results in something like "1 . Fist-Section-Title", rather
than "1. First-Section-Title", because of the extra space after the 
format. Moving the space to org-html-format-headline-default-function preserves
existing export behavior while allowing the users to better control the format.
---
 lisp/ox-html.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 89da823e8..f2ce71f68 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2676,7 +2676,7 @@ holding contextual information."
   (concat
(and numberedp
 (format
- "%s "
+ "%s"
  level
  (mapconcat #'number-to-string numbers ".")))
formatted-text)
@@ -2696,7 +2696,8 @@ See `org-html-format-headline-function' for details."
   (let ((todo (org-html--todo todo info))
(priority (org-html--priority priority info))
(tags (org-html--tags tags info)))
-(concat todo (and todo " ")
+(concat " "
+   todo (and todo " ")
priority (and priority " ")
text
(and tags "") tags)))
-- 
2.31.1

Re: About multilingual documents

[Aleksandar Dimitrov]

Hi Juan,

this sounds very interesting to me, as I, too, mostly write in Org
and, sometimes write documents in multiple languages, usually with
different varieties of either Latin or Cyrillic.

I have some suggestions:

Apart from the export, one of my biggest gripes is
flyspell. Specifically, the fact that you have to choose one language to
spell check the entire document with. That is insufficient in my case.

I think that the syntax you're suggesting looks good, but I'm not
sure how well it'd fit into org-mode's ecosystem. I had something in
mind that was closer to how org-babel works (it's called *babel*
for a reason, isn't it? :D)

#+begin_src org :lang pl
  … po polsku
#+end_src

#+begin_src org :lang de
  … auf deutsch
#+end_src

This would make use of org-mode's edit special environment function. It
would make it easier to persuade flyspell to do the right thing. You
could, perhaps, add

#+LANGUAGE: en

to the parent document, and then org would take care to set the correct
flyspell language (and the correct macros on LaTeX-export) and change
these parameters in the special environments.

I'm not 100% sure it should be #+begin_src org, maybe introducing a
different special environment would be better, say #+begin_lang XX where
XX is the ISO-code of said language, or the locale (think en_US
vs. en_GB.)

The drawback, and the clear disadvantage compared to your method is that
this works great only when the languages are separated by paragraph
breaks.

Therefore, I think our suggestions might be somewhat orthogonal. Yours
could be a shorthand syntax for introducing inline foreign-language
snippets.

What do you think?

Regards,
Aleks

Juan Manuel Macías writes:

> Hi all,
>
> I'm curious to see how other Org users deal with multilingual documents,
> that is, those documents (for example, philology or linguistics texts)
> that contain a significant number of online quotes in other languages.
> Naturally, this makes more sense in the LaTeX backend, since it is
> convenient to enclose these quotes in a \foreignlanguage command to
> ensure that LaTeX at least apply the correct hyphenation patterns for
> words in other languages.
>
> Luckily, in the latest versions of Babel (the Babel of LaTeX) you don't
> need to do this when it comes to languages whose script is different
> from Latin (e.g. Greek, languages with Cyrillic, Arabic, Hindi, etc.).
> We can, for example, define Russian and Greek as:
>
> #+begin_src latex
> \babelprovide[onchar=ids fonts,hyphenrules=russian]{russian}
> \babelprovide[onchar=ids fonts,hyphenrules=ancientgreek]{greek}
> #+end_src
>
> And also the fonts for both languages:
>
> #+begin_src latex
> \babelfont[russian]{rm}{Linux Libertine O}
> \babelfont[greek]{rm}]{Free Serif}
> #+end_src
>
> For Latin-based scripts it is still necessary enclose the text in the
> \foreignlanguage command. And now comes the question: how do Org users
> who work in multilingual documents to obtain this command when exporting
> to Latex?
>
> I usually use macros, which always tend to work fine. But lately I have
> been testing an alternative markup system using an export filter. The
> idea would be something like:
>
> %(lang) lorem ipsum dolor %()
>
> I start from a list of the most used languages:
>
> #+begin_src emacs-lisp
> (langs '(("en" "english")
>("fr" "french")
>("de" "german")
>("it" "italian")
>("pt" "portuguese")))
> #+end_src
>
> And other possible languages that Babel supports can be indicated
> explicitly, by prepending "--":
>
> %(fr) ... %()
>
> %(--esperanto) ... %()
>
> (If someone wants to try it, I attach a small Org document).
>
> Best regards,
>
> Juan Manuel

Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi all,

Less code is less bug and less maintainance.  So I'm considering
moving these files to the new (unmaintained) org-contrib repo at
https://git.sr.ht/~bzg/org-contrib:

- ob-abc.el --- Org Babel Functions for ABC
- ob-asymptote.el --- Babel Functions for Asymptote
- ob-coq.el --- Babel Functions for Coq
- ob-ditaa.el --- Babel Functions for ditaa
- ob-ebnf.el --- Babel Functions for EBNF
- ob-hledger.el --- Babel Functions for hledger
- ob-J.el --- Babel Functions for J
- ob-ledger.el --- Babel Functions for Ledger
- ob-lilypond.el --- Babel Functions for Lilypond
- ob-mscgen.el --- Babel Functions for Mscgen
- ob-picolisp.el --- Babel Functions for Picolisp
- ob-vala.el --- Babel functions for Vala evaluation

I suggest a criterium for keeping ob*.el files in Org could be that
the extension is known by Emacs _or_ that the supported language is
well-established.

Since I can obviously not decide alone about "well-established", would
you mind giving your advice on whether the files above can be moved to
org-contrib?  (Of course we would advertize this carefully.  And also,
there is absolutely nothing personal about perhaps moving *your* file
out of Emacs, it's just that maintainance will be easier outside.)

Are there any other?  

I'll leave this thread open during this week, no need to rush here.

Thanks,

-- 
 Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

Bastien  writes:

> Kévin Le Gouguec  writes:
>
>> Great!  One last snag that I can see: when inserting properties or
>> clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented,
>> but the /first/ :property: or CLOCK: line remains at column 0.
>
> Er.  Can you try this (hopefully last) patch and report any problem?
>
> Thanks for your patience in testing this!

Well, try as I might, I couldn't get this one to misindent  And a good
thing too, I was about to run out of synonyms for wrinkles/nits/snags
and the like 


If anyone is wondering what these exchanges are all about: with
Bastien's latest patch[1], setting org-adapt-indentation to
'headline-data results in the following behaviour, *whether
electric-indent-mode is enabled or not*:

- "* heading RET" starts an unindented line (point goes to column 0).
- The drawers inserted by org-set-property and org-clock-in are
  indented.

So, to bring the discussion back to the poll:

- If nil or 'headline-data becomes the default value, RET will no longer
  indent regular text after a headline (even with electric-indent-mode).
- The difference will be whether :DRAWERS: are indented or not.

As far as I am concerned, my preference has become:

(1) 'headline-data (indented drawers)
(2) nil (nothing indented)
(3) t (the status quo)

although I suppose an argument could be made that 'headline-data might
be a bit "young" and as such, should not be used as default value…

Let's see what the poll yields 


[1] Uncommited, to apply on branch maint:
https://orgmode.org/list/87fsz4ue9e@bzg.fr/2-fix-indent.patch

Re: [IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Bastien]

Bastien  writes:

> Bastien  writes:
>
>> The files previously stored in the contrib/ directory of Org's repo
>> now lives here: https://git.sr.ht/~bzg/org-contrib
>
> Let's announce this change on https://updates.orgmode.org.

For good!  (Sorry for the noise.)

-- 
 Bastien

Re: [POLL] Breaking change: removing `org-speed-commands-user'

[Bastien]

Bastien  writes:

> By merging `org-speed-commands-default' and `org-speed-commands-user'
> into a single `org-speed-commands' option, we make this possible, but
> this change will ignore people's `org-speed-commands-user' config, so
> this is a breaking change.

I've done so with commit d48276b8 in master.

-- 
 Bastien

Re: [PATCH] Replace call in org-columns of org-map-entries with org-scan-tags

[Bastien]

Hi Nick,

Nick Savage  writes:

> I was trying to track down the source of a bug encountered when I was
> submitting my last patch about org-columns. I'm going to walk you
> through my thought process and summarize at the end. As part of my
> experimenting, I did the following:
>
> 1. emacs -Q
> 2. open a new buffer at "/tmp/test.org"
> 3. Add a headline (something like "* test"), and run org-columns only
> be greeted by an unexpected error: "Non-existent agenda file
> /tmp/test.org.  [R]emove from list or [A]bort?"

thanks for catching this, the careful analysis and the patch.

Applied to the maint branch.

Thanks,

-- 
 Bastien

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

Hi Eric,

On Mon, May 3, 2021 at 9:47 AM Eric S Fraga  wrote:

> 2. the suppressed author case does not seem to work.

He removed the suppress author variant on the individual cited items,
so I think the same effect he means to achieve with the "year" style.

Bruce

Re: Transforming table and then exporting as CSV

[Pankaj Jangid]

Kyle Meyer  writes:

...
> I think that'd be the cleanest way, yes.  You could change
...

Thanks Kyle. Learned a bit more of Elisp.

Regards.. Pankaj

Re: [patch] documentation update (was Re: could a :var header argument refer to a data table in another file?)

[Eric S Fraga]

On Monday,  3 May 2021 at 15:43, Bastien wrote:
> Such small mistakes are okay, don't worry.  It's better to leave them
> than to edit commit messages that have already been pushed to the
> public.

Okay, thank you.  I'll try to be more careful next time!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-393-gd44bd5

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

Hello all,

I've had a short play with this.  Looks nice!

A few points:

1. if the BiBTeX entry has, for instance, \& to escape the & for use
   with LaTeX, org translates the \ to $\backslash$ and then the &
   causes a problem compiling the resulting LaTeX.

2. the suppressed author case does not seem to work.

3. if I cite a paper with many authors, *all* of them get listed.  It
   would be useful to have some control over this, asking, for instance,
   for only the first or the first N to be listed in the citation (but
   all of them in the bibliography).
  
thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-393-gd44bd5

Re: [patch] documentation update (was Re: could a :var header argument refer to a data table in another file?)

[Bastien]

Eric S Fraga  writes:

> On Monday,  3 May 2021 at 15:00, Bastien wrote:
>> Applied with commit 479a3da22 in master, thanks.
>
> Thank you Bastien.  However, as soon as I looked, I realised that my
> commit message missed out the "doc/" part of the file name for the
> manual.  Can you fix that (if necessary)?

Such small mistakes are okay, don't worry.  It's better to leave them
than to edit commit messages that have already been pushed to the public.

-- 
 Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

Hi Kevin,

Kévin Le Gouguec  writes:

> Great!  One last snag that I can see: when inserting properties or
> clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented,
> but the /first/ :property: or CLOCK: line remains at column 0.

Er.  Can you try this (hopefully last) patch and report any problem?

Thanks for your patience in testing this!

-- 
 Bastien
diff --git a/lisp/org.el b/lisp/org.el
index c0b5ee5ec..c20539a8a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18846,17 +18846,6 @@ ELEMENT."
 	 (t
 	  (goto-char start)
 	  (current-indentation
-  ((and
-	(eq org-adapt-indentation 'headline-data)
-(or (memq type '(planning clock node-property property-drawer drawer))
-;; When storing a note in a LOGBOOK drawer,
-;; `org-store-log-note' needs to insert a new line before
-;; the newly inserted note, thus the `type' at point will
-;; return `paragraph' instead of the expected `drawer', so
-;; we need to manually detect the drawer.
-(eq (org-element-type (car (org-element-lineage element))) 'drawer)))
-   (org--get-expected-indentation
-	(org-element-property :parent element) t))
   ((memq type '(headline inlinetask nil))
(if (org-match-line "[ \t]*$")
 	   (org--get-expected-indentation element t)
@@ -19000,11 +18989,12 @@ Also align node properties according to `org-property-format'."
   (interactive)
   (unless (or (org-at-heading-p)
   (and (eq org-adapt-indentation 'headline-data)
+   (not (org-at-clock-log-p))
(save-excursion
  (beginning-of-line 1)
  (skip-chars-backward "\n")
  (or (org-at-heading-p)
- (org-at-drawer-p)
+ (looking-back ":END:.*")
  (org-at-planning-p)
 (let* ((element (save-excursion (beginning-of-line) (org-element-at-point)))
 	   (type (org-element-type element)))

Re: [patch] documentation update (was Re: could a :var header argument refer to a data table in another file?)

[Eric S Fraga]

On Monday,  3 May 2021 at 15:00, Bastien wrote:
> Applied with commit 479a3da22 in master, thanks.

Thank you Bastien.  However, as soon as I looked, I realised that my
commit message missed out the "doc/" part of the file name for the
manual.  Can you fix that (if necessary)?

Thanks again,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-478-ge80be0

[PATCH] Replace call in org-columns of org-map-entries with org-scan-tags

[Nick Savage]

Hello all,

I was trying to track down the source of a bug encountered when I was 
submitting my last patch about org-columns. I'm going to walk you 
through my thought process and summarize at the end. As part of my 
experimenting, I did the following:


1. emacs -Q
2. open a new buffer at "/tmp/test.org"
3. Add a headline (something like "* test"), and run org-columns only be 
greeted by an unexpected error: "Non-existent agenda file 
/tmp/test.org.  [R]emove from list or [A]bort?"


It's clear that /tmp/test.org is not part of the agenda since it's a 
brand new file, but I was surprised that org-columns cares at all. 
Pressing "R" to remove it from the list tells the user that it wasn't in 
the agenda list (as you'd expect) and then continues to display columns 
as expected, which made me wonder why it is doing that at all. This 
issue only appears though when /tmp/test.org is not saved to disk, which 
looks like expected behaviour as per the following.


I looked into what's going on, and it relates to org-map-entries, which 
builds a list of what is in the buffer. org-map-entries calls 
org-agenda-prepare-buffers. This checks whether the given files are 
actual files or not and opens them up if they are. This makes sense I 
believe from an org-agenda perspective since it has to make sure all of 
the files are open in order to return a list of the headlines, but for 
org-columns it does not. org-columns is an interactive function that is 
only run on the current buffer, so the buffer should always be open.


org-map-entries has a lot of different paths in it based on the 
parameters, but essentially the call from org-columns does two things: 
1) call org-agenda-prepare-buffers and 2) sets "res" to the output of 
org-scan-tags. I believe that the former is unnecessary and that the 
latter is the only necessary code to run in this instance.


To summarize: I've attached a patch to this that makes a change to this. 
It replaces org-map-entries with a call instead to org-scan-tags. This 
fixes the bug I noted above, and I believe (if I'm using the profiler 
correct), makes org-columns a bit faster since it's not calling a bunch 
of functions that doesn't matter to its output. As far as I can tell, my 
patch works as expected with no obvious behaviour changes. All of the 
tests continue to pass as well. I've tested it on my own files and it is 
working as expected as well.


I'd appreciate any feedback on this, or if there are edge cases that the 
removed code breaks that I haven't been able to identify.


Nick

>From f8425ef6fe0ae59c9c4df0b71f3cb61c7bc7e975 Mon Sep 17 00:00:00 2001
From: Nicholas Savage 
Date: Mon, 3 May 2021 08:49:11 -0400
Subject: [PATCH] org-colview.el (org-columns): Replace org-map-entries with
 org-scan-tags

* lisp/org-colview.el (org-columns): Replace call to `org-map-entries'
to build cache with `org-scan-tags'.

Simplifies `org-columns' to call `org-scan-tags' instead of
`org-map-entries'. This is to fix a bug where an unexpected non-existent
agenda file error was thrown if the buffer that `org-columns' was called
on was not yet saved to disk. This also simplifies `org-columns' and
prevents unnecessary agenda preparation functions from running.
---
 lisp/org-colview.el | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 517bcdf1c..ac3fd9326 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -836,12 +836,11 @@ Also sets `org-columns-top-level-marker' to the new position."
 (defun org-columns ( global columns-fmt-string)
   "Turn on column view on an Org mode file.
 
-Column view applies to the whole buffer if point is before the
-first headline.  Otherwise, it applies to the first ancestor
-setting \"COLUMNS\" property.  If there is none, it defaults to
-the current headline.  With a `\\[universal-argument]' prefix \
-argument, turn on column
-view for the whole buffer unconditionally.
+Column view applies to the whole buffer if point is before the first
+headline.  Otherwise, it applies to the first ancestor setting
+\"COLUMNS\" property.  If there is none, it defaults to the current
+headline.  With a `\\[universal-argument]' prefix \ argument, GLOBAL,
+turn on column view for the whole buffer unconditionally.
 
 When COLUMNS-FMT-STRING is non-nil, use it as the column format."
   (interactive "P")
@@ -867,9 +866,8 @@ When COLUMNS-FMT-STRING is non-nil, use it as the column format."
 	(let ((cache
 	   ;; Collect contents of columns ahead of time so as to
 	   ;; compute their maximum width.
-	   (org-map-entries
-		(lambda () (cons (point) (org-columns--collect-values)))
-		nil nil (and org-columns-skip-archived-trees 'archive
+   (org-scan-tags
+		(lambda () (cons (point) (org-columns--collect-values))) t org--matcher-tags-todo-only)))
 	  (when cache
 	(org-columns--set-widths cache)
 	(org-columns--display-here-title)
-- 
2.20.1

Re: [PATCH]: Add elisp snippet to worg/org-contrib/org-mac.org

[Tim Visher]

On Mon, May 3, 2021 at 8:58 AM Bastien  wrote:

> Tim Visher  writes:
>
> > Here's a quick patch that fixes that up:
>
> Applied, thanks.  If you want to contribute more to Worg, please
> send me the username you want in private and I'll create an account
> for you on code.orgmode.org.
>

Thanks for the apply! :)

Re: [patch] documentation update (was Re: could a :var header argument refer to a data table in another file?)

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> On Thursday, 29 Apr 2021 at 10:51, John Kitchin wrote:
>> I don't know if it is in the manual. It would be great to have it in
>> https://orgmode.org/manual/Environment-of-a-Code-Block.html.
>
> Attached is a patch for this.  Thank you.

Applied with commit 479a3da22 in master, thanks.

-- 
 Bastien

Re: [PATCH]: Add elisp snippet to worg/org-contrib/org-mac.org

[Bastien]

Hi Tim,

Tim Visher  writes:

> Here's a quick patch that fixes that up:

Applied, thanks.  If you want to contribute more to Worg, please 
send me the username you want in private and I'll create an account
for you on code.orgmode.org.

Thanks!

-- 
 Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

Bastien  writes:

> Kévin Le Gouguec  writes:
>
>> A fews more moles to whack, maybe:
>>
>> - RET after an ":END:" starts an indented line,
>> - "* headline RET text TAB" indents "text" (and subsequent RETs are then
>>   indented).
>
> Fixed, thanks.

Great!  One last snag that I can see: when inserting properties or
clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented,
but the /first/ :property: or CLOCK: line remains at column 0.

I've looked briefly at org-indent-line; IIUC, those lines get caught in
this condition:

(save-excursion
  (beginning-of-line 1)
  (skip-chars-backward "\n")
  (or (org-at-heading-p)
  (org-at-drawer-p)
  (org-at-planning-p)))

I'm guessing we'd need to throw some (org-at-property-p) and
(org-at-clock-log-p) guards *before* skipping backward over "\n", but I
haven't thought this through completely yet.

>> should at least write test cases for them.  Will try to find the time
>> Sometime Later™.
>
> This might help: https://orgmode.org/worg/org-faq.html#indentation

Wonderful!  That will definitely help, thanks.

[patch] documentation update (was Re: could a :var header argument refer to a data table in another file?)

[Eric S Fraga]

On Thursday, 29 Apr 2021 at 10:51, John Kitchin wrote:
> I don't know if it is in the manual. It would be great to have it in
> https://orgmode.org/manual/Environment-of-a-Code-Block.html.

Attached is a patch for this.  Thank you.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-393-gd44bd5
>From 339e44b08b73ed083c15311d230db5f4d98abc8a Mon Sep 17 00:00:00 2001
From: Eric S Fraga 
Date: Mon, 3 May 2021 13:37:58 +0100
Subject: [PATCH] org-manual.org: describe external reference for :var header

* org-manual.org: the description of the :var header argument for
working with source code has been expanded to mention the possibility
of having an external reference, a reference to an element in another
file.
---
 doc/org-manual.org | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 42a12e9d4..3008d5a48 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -16797,7 +16797,11 @@ the =var= header argument.
 body.  {{{var(ASSIGN)}}} is a literal value, such as a string,
 a number, a reference to a table, a list, a literal example, another
 code block---with or without arguments---or the results of evaluating
-a code block.
+a code block.  {{{var(ASSIGN)}}} may specify a filename for references
+to elements in a different file, using a =:= to separate the filename
+from the reference.
+
+: :var NAME=FILE:REFERENCE
 
 Here are examples of passing values by reference:
 
-- 
2.29.2

Re: [PATCH]: Add elisp snippet to worg/org-contrib/org-mac.org

[Tim Visher]

Hi Bastien,

On Mon, May 3, 2021 at 12:05 AM Bastien  wrote:

>
> Tim Visher  writes:
>
> > At the recommendation of Tim Cross I've prepared a patch to worg to
> > include the elisp that I recently sent to the list that I've been
> > using to create TODO items based on the currently selected macOS
> > Mail.app message.
> >
> > Let me know if there's anything I can do to help get it applied.
>
> Applied in Worg, thanks a lot.
>

Thanks for the quick apply!

I'm surprised but I failed to notice that I never actually finished the
hyperlink to the new org-mac-mail-link.org file from org-mac.org. I only
saw it when I went to the site  to
check out the fruits of our labors. (－‸ლ)

Here's a quick patch that fixes that up:

>From 5a363a927f67d2c8571085110ce336872a073fac Mon Sep 17 00:00:00 2001
From: Tim Visher  
Date: Mon, 3 May 2021 08:25:46 -0400
Subject: [PATCH] org-mac: Fix link to org-mac-mail-link from org-mac
---
 org-mac.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/org-mac.org b/org-mac.orgindex 2addd5f0..b7c334fd
100644--- a/org-mac.org+++ b/org-mac.org@@ -33,7 +33,7 @@ applications
other than Emacs...
insert it as a hyperlink at point in an org-mode document. Written
by /Anthony Lander/.
-** org-mac-mail-link -- Hyperlink to messages in Mail.app+**
[[file:org-contrib/org-mac-mail-link.org][org-mac-mail-link]] --
Hyperlink to messages in Mail.app
A small elisp file that addresses linking to Mail.app messages
directly via the =org-capture= system. For wider application
support check out [[file:org-contrib/org-mac-link.org][org-mac-link]].--
2.30.1


0001-org-mac-Fix-link-to-org-mac-mail-link-from-org-mac.patch
Description: Binary data

Re: [IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Bastien]

Bastien  writes:

> The files previously stored in the contrib/ directory of Org's repo
> now lives here: https://git.sr.ht/~bzg/org-contrib

Let's announce this change on https://updates.orgmode.org.

-- 
 Bastien

[IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Bastien]

The files previously stored in the contrib/ directory of Org's repo
now lives here: https://git.sr.ht/~bzg/org-contrib

If you install Org from git to load packages from the contrib/ dir,
please update your configuration accordingly.

The new org-contrib.git repo is mostly for archival purpose.

Files in https://git.sr.ht/~bzg/org-contrib need new maintainers:
if you want to maintain one of these files (outside of the repo),
please contact me directly.

The plan is to build a NonGNU ELPA package called "org-contrib",
we will see if that's feasible.

Thanks,

-- 
 Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* Tim Cross  [2021-05-03 01:39]:
> This is  exactly what headline-data does. I suspect what your running
> into is electric-indent-mode and you need to turn it off to get the
> behaviour you want. So set org-adapt-indentation to hedline-data and
> turn off electric-indent-mode and you will get the indentation style you
> are after.
> 
> The issue here isn't that org-adapt-indentation changed. The issue is
> that the effect of this setting changed when org mode was updated to be
> consistent with the rest of emacs and honour electric-indent-mode, which
> is enabled by default in emacs. Previously, org ignored this wider Emacs
> default setting.

I got it after Bastien explained it.

I am just not sure if right settings should be like this:

(add-hook 'org-mode-hook (lambda () (electric-indent-mode 0)))
(add-hook 'org-mode-hook (lambda () (setq org-adapt-indentation 'heading-data)))

I understand from debate that changed was brought to make it
consistent with Emacs and users have already got habits. IMHO change
was made rather for the sake of computer program as quite number of
people like it different.

> I'm not sure the full impact of enabling electric-indent-mode was
> realised at the time. With org, I think the general principal is to try
> and have defaults set to the 'least surprising' value, particularly for
> new users. 
> -- 
> Tim Cross

That is it.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Dr. Arne Babenhauserheide]

Amin Bandali  writes:

> Bastien writes:
>
>> Various discussions convinced me that `org-adapt-indentation' should
>> be nil by default.
>>
>> With `electric-indent-mode' being activated by default in Emacs, the
>> current behavior is that RET after a headline moves the point below
>> the beginning of this headline, not the beginning of the line, which
>> might surprise users.
>>
>> Indentation is quite sensitive: what do you think of setting a new
>> default value of nil for `org-adapt-indentation' in Org 9.5?
>
> +1 from me as well.  I personally quite dislike indenting after headings
> with spaces, and instead use (add-hook 'org-mode-hook #'org-indent-mode)
> for the visual indentation effect, which I can easily toggle off when
> needed.

What’s important for me is that hitting enter on a headline does not
create indentation for the text.

I’ve been removing indentation manually ever since that change, and I
cannot just configure it out, because I often open org-files with emacs
-Q or on different systems. Therefore this default matters a lot for me.
With the current default I would have to change the default in every
emacs session on every docker or VM, and I would have to tell every new
org-user to start by changing the default just to be able to write
conveniently.

I made a point of slimming down my Emacs config, because I often sit at
a pristine emacs, and it is important for me that org-mode just works.
Before electric-indent-mode got enabled, it was one of the huge
strengths of org-mode that it just worked for most use-cases while
enabling everyone to customize it incrementally. And I vote to get that
back.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Help debugging R source code block output problem with :session

[Jeremie Juste]

Hello,

I must apologize again for the delay. I'll be more responsive from now
on.

@Jack, I have applied the patch at the bottom of the mail. It is not
your latest patch but it works as well and is able to handle R errors.

> https://orgmode.org/list/87ft7t9wqk@gmail.com/
I have also added the 2 test cases with to make sure we are aware if
this feature breaks in the future.

> https://orgmode.org/list/87h7slgbi5@gmail.com/
> I'd be interested to hear if the attached patch works for the common
> cases you encounter, such as with tibbles.


@ Ilja, sorry for the delayed reply.
Regarding tibbles we are still not out of the woods. But the current
patch would work if crayon option is removed.

#+BEGIN_SRC R :results output :session "local1" :pre
  options(crayon.enabled=FALSE)
  library(tidyr)
  library(dplyr)
  as_tibble(iris)
#+END_SRC

#+RESULTS:
#+begin_example
# A tibble: 150 x 5
   Sepal.Length Sepal.Width Petal.Length Petal.Width Species
   
 1  5.1 3.5  1.4 0.2 setosa 
 2  4.9 31.4 0.2 setosa 
 3  4.7 3.2  1.3 0.2 setosa 
 4  4.6 3.1  1.5 0.2 setosa 
 5  5   3.6  1.4 0.2 setosa 
 6  5.4 3.9  1.7 0.4 setosa 
 7  4.6 3.4  1.4 0.3 setosa 
 8  5   3.4  1.5 0.2 setosa 
 9  4.4 2.9  1.4 0.2 setosa 
10  4.9 3.1  1.5 0.1 setosa 
# … with 140 more rows
#+end_example

> 

@Chuck

> https://orgmode.org/list/352c7149-743f-4944-aca5-7a1242b5a...@health.ucsd.edu/
>If you do decide to dig into solving this, please be sure that remote
>sessions and graphical outputs are not broken. test-ob-R.el does not
>cover those cases. In fact, it is pretty short, so there are probably
>other things that could break without `make test' complaining.


The current patch have been tested for remote connections as well and
AFAIK, nothing breaks.

But I'm afraid that the graphical output is broken and has long been
even before the path. The test for graphical output is compromised and
does not do the right test. I will suggest new ones. 


Please feel free to contact me or reply on the mailing list if you have
see any improvements to be made.

Best regards,
Jeremie



On Saturday, 29 Aug 2020 at 00:24, Jack Kamm wrote:

>>From 9eaf81d708f88d06f14f9b6b9cf4182dd0fbb997 Mon Sep 17 00:00:00 2001
> From: Jack Kamm 
> Date: Sat, 29 Aug 2020 00:07:58 -0700
> Subject: [PATCH] ob-R: Fix prompt mangling in session output
>
> * lisp/ob-R.el (org-babel-R-evaluate-session): Force comint prompt
> regexp to start at beginning of line, to prevent
> org-babel-comint-with-output from splitting mid-line.
>
> Fixes https://orgmode.org/list/875zgjh8wn@gmail.com/ and
> https://orgmode.org/list/87r1rqled0.fsf@havana/
> ---
>  lisp/ob-R.el | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index 5e9d35f58..10b3b6fe3 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -450,11 +450,13 @@ (defun org-babel-R-evaluate-session
> (car (split-string line "\n")))
>(substring line (match-end 1))
>  line))
> -(org-babel-comint-with-output (session org-babel-R-eoe-output)
> -  (insert (mapconcat 'org-babel-chomp
> - (list body org-babel-R-eoe-indicator)
> - "\n"))
> -  (inferior-ess-send-input)) "\n"
> +(with-current-buffer session
> +  (let ((comint-prompt-regexp (concat "^" comint-prompt-regexp)))
> +(org-babel-comint-with-output (session 
> org-babel-R-eoe-output)
> +  (insert (mapconcat 'org-babel-chomp
> + (list body org-babel-R-eoe-indicator)
> + "\n"))
> +  (inferior-ess-send-input "\n"
>  
>  (defun org-babel-R-process-value-result (result column-names-p)
>"R-specific processing of return value.
> -- 
> 2.28.0

Re: Checkboxes in headings - opinions wanted

[Timothy]

Bastien  writes:
> For now you can use statistics cookies in headline:
> https://orgmode.org/manual/Checkboxes.html
>
> What would perhaps make sense would be to support [ ]/[X] on top of
> the already supported [0%]/[100%] and [0/n]/[n/n].

I've always used
* TODO heading [/]

as a substitute for
+ [  ] task [/]

Other than it not automatically switching to done upon reaching 100%,
I've been pretty happy with this.

Just my 2c.

--
Timothy

Re: Checkboxes in headings - opinions wanted

[Bastien]

Hi Arthur,

Arthur Miller  writes:

> Last night I have been playing with a minor mode to enable a checkbox in
> a heading, or rather to fake a checkbox.

Interesting, thanks.

For now you can use statistics cookies in headline:
https://orgmode.org/manual/Checkboxes.html

What would perhaps make sense would be to support [ ]/[X] on top of
the already supported [0%]/[100%] and [0/n]/[n/n].

What do you think?  (I tried your mode and unless I didn't try it
correctly, it does not seem to do that.)

Thanks,

-- 
 Bastien

Re: Commit message instructions on the website

[Bastien]

Hi Jeremie,

I pushed a fix for this (though a little bit before I read your public
message here) - let me know if it needs to be enhanced.

Thanks!

-- 
 Bastien

Commit message instructions on the website

[Jeremie Juste]

Hello,

The commit message instruction on the website
https://orgmode.org/contribute.html

The following instructions might help make commit message more precise
for newbies:

- Sentences should start with an uppercase letter (after the column) and end 
with a full stop
- The sentence on the first line should not end with a full stop.
- The first sentence should not start with a star.


On the website, the first line of the commit message does not start with an 
uppercase
after the column.

> main file/feature: overall change summary

> * file-changed.el (function-changed, another-function): Description of
> the change implemented, reference any relevant `other-functions' or
> `variables' here.
> (another-changed-function): Change something.  Use active voice,
> and avoid passive forms.  Please write in full sentences.

everything else is good.

Best regards,
Jeremie Juste

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

Hi Kevin,

thanks for checking.

Kévin Le Gouguec  writes:

> A fews more moles to whack, maybe:
>
> - RET after an ":END:" starts an indented line,
> - "* headline RET text TAB" indents "text" (and subsequent RETs are then
>   indented).

Fixed, thanks.

> Sorry for just dumping all these nits at your front door Bastien  I
> should at least write test cases for them.  Will try to find the time
> Sometime Later™.

This might help: https://orgmode.org/worg/org-faq.html#indentation

Thanks!

-- 
 Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

Tim Cross  writes:

> Jean Louis  writes:
>
>> If I set `org-adapt-indent' to 'headline-data, I get that same
>> behavior that after pressing ENTER on headline line, position becomes
>> indentend. So it does not make it right.
>>
>> My favour was the behaviour how it was before introduction of
>> indentation change:
>>
>> - after headline, cursors went to beginning of line; I find it
>>   usable, as that is where I write text. 
>>
>> - if I ever wanted to enter properties with C-c C-x p, those were 
>> automatically
>>   indented,
>
> This is  exactly what headline-data does. I suspect what your running
> into is electric-indent-mode and you need to turn it off to get the
> behaviour you want. So set org-adapt-indentation to hedline-data and
> turn off electric-indent-mode and you will get the indentation style you
> are after.

Note that electric-indent-mode means "RET indents according to the major
mode's canonical indentation rules", not "RET always indents".

Org's rules depend on org-adapt-indentation: ideally with
org-adapt-indentation set to 'headline-data, the canonical rules become
"only :DRAWERS: are indented", so RET should *not* indent text; things
should behave as Jean Louis prefers even with electric-indent-mode on.

Bastien has just committed a fix for this earlier today;
cf. <87fsz4gtjs@gmail.com>.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

Kévin Le Gouguec  writes:

> 'headline-data sounds like a reasonable default too, although I think it
> still has some wrinkles[2].
>
> [2] Typing "* headline RET" starts an indented line; further RETs keep
> point indented until I type in something, after which RET finally
> snaps back to column 0.  I'd expect point to always land on column 0
> when hitting RET after a headline, since "headline data"
> (e.g. :PROPERTIES:, :LOGBOOK:) will probably always be entered
> automatically via a command.

And as of 3 hours ago, this complaint is now obsolete[1][2] 

A fews more moles to whack, maybe:

- RET after an ":END:" starts an indented line,
- "* headline RET text TAB" indents "text" (and subsequent RETs are then
  indented).

Sorry for just dumping all these nits at your front door Bastien  I
should at least write test cases for them.  Will try to find the time
Sometime Later™.


[1] 
https://code.orgmode.org/bzg/org-mode/commit/c7331f859d1cc53d5c5f2c6ec58691af15f60b80
[2] 
https://code.orgmode.org/bzg/org-mode/commit/945c019176b2d23c5006377c95ce8d69b4b4de66

Checkboxes in headings - opinions wanted

[Arthur Miller]

org-heading-checkbox.el
Description: application/emacs-lisp

Last night I have been playing with a minor mode to enable a checkbox in
a heading, or rather to fake a checkbox. To be honest, it was a 10
minute job. Took me way moare time to figure out avialable key
combination to use (which I didn't found).

In general, enable mode and use S+up/down to toggle a checkbox. A
heading with a checkbox is of form [ \t]*\\*+.*? followed by a [ ] or
[x] before a heading. It means a [ ] can be placed somewhere after the
leading stars, whitespaces ignored.

This has nothing todo with my previous hacks of todo keywords. This one
does not uses todo states at all so it can be used with todo states.

It is just a small prototype. I will use something else than
replace-string later on.

Just wonder if the approach is sane.

There is also a repo on gh for interested one:

https://github.com/amno1/org-heading-checkbox