Re: move siblings

[Dominik Schrempf]

Hi!

Are you looking for =org-shiftmetadown= and sibling functions? I think
they are bound to SHIFT-META-ArrowDown, and so on, by default.

Cheers,
Dominik

Samuel Wales  writes:

> * aa
> ** a
> ** b
> ** c
>
> is there a command to move entry at point to below c, or to above a?

Re: Hyphen after LaTeX fragments

[Dominik Schrempf]

Great, thank you so much!

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Yuchen Guo  writes:
>>
>>> If it is deprecated in Org mode, maybe we can print a warning message in
>>> echo area?
>>
>> Not in echo area, but we can add a linter.
>
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cfe5e01e1

Re: Hyphen after LaTeX fragments

[Dominik Schrempf]

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>> Maybe the best thing to do is drop support for $...$ completely?
>
> We cannot do it. Otherwise, existing Org documents may be broken.
>

Well, and as detailed later in my mail, I meant deprecating support for
$...$. But thanks for pointing this out!

>
>> I quote the Org mode manual section about $...$ syntax:
>>
>> Text within the usual LaTeX math delimiters. To avoid conflicts with
>> currency specifications, single ‘$’ characters are only recognized
>> as math delimiters if the enclosed text contains at most two line
>> breaks, is directly attached to the ‘$’ characters with no
>> whitespace in between, and if the closing ‘$’ is followed by
>> whitespace, punctuation or a dash. For the other delimiters, there
>> is no such restriction, so when in doubt, use ‘\(...\)’ as inline
>> math delimiters.
>>
>> I think this is HIGHLY confusing. I think we should write something
>> along the lines: "Do not use $...$. Only for reasons of backwards
>> compatibility, $...$ syntax is partly (!) supported."
>
> Feel free to provide a patch.

I think that a change in the documentation alone is insufficient. We
need to make sure that all current and future maintainers of org-latex
are aware of the decision to deprecate $...$ (if we make this decision).
How do we do that?

Re: Hyphen after LaTeX fragments

[Dominik Schrempf]

I like the $...$ syntax, but since it is not fully supported, I rather
use \(...\) consistently; I do not really care.

Maybe the best thing to do is drop support for $...$ completely?

I quote the Org mode manual section about $...$ syntax:

Text within the usual LaTeX math delimiters. To avoid conflicts with
currency specifications, single ‘$’ characters are only recognized
as math delimiters if the enclosed text contains at most two line
breaks, is directly attached to the ‘$’ characters with no
whitespace in between, and if the closing ‘$’ is followed by
whitespace, punctuation or a dash. For the other delimiters, there
is no such restriction, so when in doubt, use ‘\(...\)’ as inline
math delimiters.

I think this is HIGHLY confusing. I think we should write something
along the lines: "Do not use $...$. Only for reasons of backwards
compatibility, $...$ syntax is partly (!) supported."

Dominik

Rudolf Adamkovič  writes:

> iem...@gmail.com writes:
>
>> You can write \(n\)-dimensional space.
>
> ROFL.
>
> My apologies for the laugh, but this question will keep coming over and
> over and over until the end of times.  Clearly, there is a need for the
> dash, and given the quality and syntactic stability of TeX, the problem
> is not going anywhere ... ever.
>
> Rudy

Re: Hyphen after LaTeX fragments

[Dominik Schrempf]

Hi!

I think we had this discussion quite some times already. Org Mode
supports $...$ syntax wherever possible but not in all places and
encourages the use of \(...\). I switched from using $...$ to \(...\)
everywhere, and have not had any problems since.

Dominik

Yuchen Guo  writes:

> [[PGP Signed Part:Undecided]]
> Sometimes I encounter such texts:
>
>One of the useful features of a basis $B$ in an $n$-dimensional space
>
> When entered as-is in Org mode and exported to LaTeX, the string
> "$n$-dimensional" is exported as plain text, as
>
>One of the useful features of a basis \(B\) in an \$n\$-dimensional space
>
> In cases such as "$n$;" and "$n$.", they are correctly exported as
> "\(n\);" and "\(n\).".
>
> So, are there any option that can be tweaked to export "$MATH$-text"
> correctly?

Re: Mistake in LaTeX syntax not detected, strange pdf generated

[Dominik Schrempf]

Hi!

I wanted to chime in here, because sometimes I do have a similar
problem.

Whenever I export to LaTeX + PDF, it is pretty difficult to see if the
compilation actually worked (or not). This is, because the compilation
happens asynchronously, and so, the message about the compilation
results in the modeling vanishes fast.

Usually, I open the LaTeX compilation buffer manually, but I think it
would be great if Org Mode was a bit more verbose about the result of
the compilation (not the actual export). Not sure how this would work
though... (Not very helpful, I know).

Thank you!
Dominik

alain.coch...@unistra.fr writes:

> alain.coch...@unistra.fr writes on Tue 29 Nov 2022 12:33:
>
>  > I would expect that the mistake be reported in the *Org PDF LaTeX
>  > Output* Compilation buffer.  So far, what I saw in that buffer was
>  > essentially what shows up when I run 'pdflatex org_generated_file.tex'
>  > from a terminal.  Not this time: the "regular" pdflatex compiles
>  > correctly, not the pdflatex that Org uses internally.
>
>  > I thought what Org did was simply run pdflatex+bibtex+etc. just as
>  > what one would do manually, but apparently there is some difference.
>
> Hum, I correct myself here: the compilation buffer does report the
> mistake (I hadn't looked at it).  Also, the manual compilation with
>
>pdflatex org_generated_file.tex
>
> does generate the same pdf provided that I hit  many times.
> Also, I see that the message
>
>PDF file produced with errors.
>
> appears in the *Messages* buffer.
>
> So perhaps Org could display this message in the minibuffer instead of
>
>Running /usr/bin/xdg-open /home/cochard/Org/debug3.pdf...done
>
> which leads to the impression that the compilation is OK.

Re: Org Haskell code blocks

[Dominik Schrempf]

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>> Syntax highlighting is not working, for example, with the following
>> snippet and code block:
>>
>> begin_snippet
>>
>> - An example of a function:
>>
>>   #+begin_src haskell :exports code :results none
>>   f :: a -> b
>>   #+end_src
>>
>> end_snippet
>
> Works on my side (I think).
> See the attached screenshot.
> I am on the latest main.
>
> [2. image/png; haskell-fontification.png]...

This is interesting. For me, syntax highlighting works partially. For
example, keywords are highlighted, but function names are not. See below.

Re: Org Haskell code blocks

[Dominik Schrempf]

Dear Ihor,

thank you, these are great news!

Syntax highlighting is not working, for example, with the following
snippet and code block:

begin_snippet

- An example of a function:

  #+begin_src haskell :exports code :results none
  f :: a -> b
  #+end_src

end_snippet

Note the indentation. The code block is indented by 2 spaces, because it
belongs to the list item above. The indentation makes the syntax
highlighting fail. It may well be that this is non-standard usage of
code blocks, but it is very convenient to preserve indentation in this
way.

I also fixed the detection of 'haskell-process-type'. It turns out, I
had some local configuration preferring 'cabal-repl', even without the
required project files. 'haskell-process-type' 'auto' works correctly, I
apologize.

Thank you for your help!

Dominik

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>> Ad scrambling: The scrambling happens with multi-line input. For example
>>
>> #+begin_src haskell :exports both :results output
>> let x = 10
>> let y = 12
>> x*y
>> [x,y]
>> #+end_src
>>
>> #+results:
>> :
>> : ghci> 120
>> : [10,12]
>
> I am unable to reproduce on the latest main.
> Likely because of recent fixes in ob-comint.
>
>> Do you get syntax highlighting when the source code is indented (for
>> example in list items).
>
> I have the above code fontified.
> Could you please provide an example of the code that is not being fontified?

Re: Org Haskell code blocks

[Dominik Schrempf]

Hi Bruno,

glad to hear that it works for you.


Ad 'org-babel-script-escape': I use Org version 9.6. I do not temper
with 'org-babel-script-escape', it is used by the respective babel
modules --- 'ob-haskell' in this case. The error also occurs with
'cabal-repl' as process type.


Ad 'haskell-process-type': When I use 'haskell-process-type' 'auto', it
chooses 'cabal-repl' which will also fire up 'ghci' but the setup is
faulty, because it does not find any modules, as I described. I just
checked and this is not a fault of org-mode. The command 'cabal repl'
also fails to access any modules when executed in the terminal. I think
it requires a `.cabal` file, which I usually do not have when using an
Org file. I quote the help text from 'cabal repl':

Open an interactive session for a component within the project.

I think this is not the correct default for Org mode, because usually
there is no "project", but just an Org file.

If I use 'haskell-process-type' 'ghci', all modules I have installed
along with GHC are found, as I expect them to be.


Ad scrambling: The scrambling happens with multi-line input. For example

#+begin_src haskell :exports both :results output
let x = 10
let y = 12
x*y
[x,y]
#+end_src

#+results:
:
: ghci> 120
: [10,12]

Do you get syntax highlighting when the source code is indented (for
example in list items).

Thanks for your reply!

Dominik

Bruno Barbier  writes:

> Hi,
>
> Dominik Schrempf  writes:
>
>> ...
>> However, the result output is still scrambled (e.g., empty
>> lines, unnecessary "ghci>" prompts in results)
>>
>
> For me, ghci is selected by default.
>
> Here is the config I've used to test it:
>
>   | emacs-version   |28.1 |
>   | org-version |   9.5.2 |
>   | haskell-process-type|auto |
>   | org-babel-script-escape |  |
>
>
> Here is my simple test:
>
>   #+begin_src haskell
> 1+2
>   #+end_src
>
>   #+RESULTS:
>   : 3
>
> The variable 'org-babel-script-escape' doesn't exist in the version that
> I'm using. And, the prompt is not "ghci>" but the current module name.
>
> Which version of org are you using ? Could you try with a recent version
> and provide a minimal complete example using a minimal configuration ?
> (see the org mode manual (info "(org)Feedback")).
>
> Thanks,
>
>
> Bruno

Re: Org Haskell code blocks

[Dominik Schrempf]

I apologize, the settings described in Point 1 actually have no effect.
Multi line input works out of the box (at least with "ghci" as
described). However, the result output is still scrambled (e.g., empty
lines, unnecessary "ghci>" prompts in results)

Dominik

Dominik Schrempf  writes:

> Hello,
>
> I have trouble using Haskell code blocks in Org Mode.
>
> 1. I need to use the following Org Mode file header:
>
> #+property: :header-args:haskell: :prologue ":{\n" :epilogue ":}\n"
>
> #+begin_src haskell :exports none :results none
> :set prompt-cont ""
> #+end_src
>
> Otherwise, the results of Haskell code blocks are scrambled.
>
> 2. I need to set `haskell-process-type' to `ghci'. The default
> interpreter `cabal-repl' does not find any external modules (even core
> modules included with GHC).
>
> However, I get the error message "org-babel-script-escape:
> ‘org-babel-script-escape’ expects a string", when executing the first
> code block which starts the interpreter. Seemingly, the error has no
> effect because everything works fine.
>
> 3. I have to set `org-edit-src-content-indentation` to 0, and always put
> the source code to text column 0, otherwise syntax highlighting does not
> work.
>
> Do others have the same problems? If so, have there been discussions
> about how to improve this situation?
>
> Thank you for your help!
>
> Dominik

Org Haskell code blocks

[Dominik Schrempf]

Hello,

I have trouble using Haskell code blocks in Org Mode.

1. I need to use the following Org Mode file header:

#+property: :header-args:haskell: :prologue ":{\n" :epilogue ":}\n"

#+begin_src haskell :exports none :results none
:set prompt-cont ""
#+end_src

Otherwise, the results of Haskell code blocks are scrambled.

2. I need to set `haskell-process-type' to `ghci'. The default
interpreter `cabal-repl' does not find any external modules (even core
modules included with GHC).

However, I get the error message "org-babel-script-escape:
‘org-babel-script-escape’ expects a string", when executing the first
code block which starts the interpreter. Seemingly, the error has no
effect because everything works fine.

3. I have to set `org-edit-src-content-indentation` to 0, and always put
the source code to text column 0, otherwise syntax highlighting does not
work.

Do others have the same problems? If so, have there been discussions
about how to improve this situation?

Thank you for your help!

Dominik

Re: Question about cite_export basic

[Dominik Schrempf]

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>>   title   = {{Introduction to Markov Chain Monte Carlo}},
>> ...
>> Is rendered as
>>
>> Geyer, Charles J (2011). {Introduction to Markov Chain Monte Carlo}, CRC 
>> press.
>>
>> In particular, the curly braces are printed. Curly braces are often
>> used in bib files to indicate that the capitalization is to be
>> preserved.
>>
>> Do we want to change the default behavior of the basic processor so
>> that it correctly handles these cases?
>
> This makes sense. However, I see it as something to be done by
> bibtex.el; not by Org. Or we may need to write a small exporter for
> BibTeX fields specifically. So that
> http://www.bibtex.org/SpecialSymbols/ is obeyed. We may also handle
> upcasing the title words in such exporter.
>
> For now, I reached Emacs devs asking to provide the parsing within
> bibtex.el. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712
> Lets see what they reply first.
>

Dear Ihor!

Thank you for posting the BibTeX brace problem upstream. From what I can
see by reading through the conversation, we are going down a rabbit
hole. It seems to be pretty difficult to convert a BibTeX entry to a
proper ascii string (I think this is what the basic export processor is
doing). Is that true?

Not sure how to proceed. I do not think that post processing
`bibtex-parse-entry` output which seems to contain LaTeX code makes
sense.

Best,
Dominik

Re: Images in org-mode

[Dominik Schrempf]

Maybe there are other options, but I think the canonical way is to use the
variable `org-image-actual-width’. The help mentions some ATTR_XXX options, so
you may find more answers there!

Dominik

Colin Baxter  writes:

> I seem to remember that the option
>
> #+ATTR_ORG: :width 100
>
> could scale the display of an image in an org-mode file. This no longer
> works - perhaps it never did. How should I scale an image display in an
> org-mode file (not exported)?
>
> Best wishes,
>
> Colin Baxter.

Question about cite_export basic

[Dominik Schrempf]

Hello!

When using the basic org cite export processor, that is:

#+cite_export: basic

bibliography items with curly braces are rendered in an unexpected way.

For example,

@InCollection{Geyer2011,
  author  = {Geyer, Charles J},
  title   = {{Introduction to Markov Chain Monte Carlo}},
  year= 2011,
  booktitle   = {{Handbook of Markov Chain Monte Carlo}},
  editor  = {Brooks, Steve and Gelman, Andrew and Jones, Galin and Meng,
  Xiao-Li},
  publisher   = {CRC press},
  pages   = 45,
}

Is rendered as

Geyer, Charles J (2011). {Introduction to Markov Chain Monte Carlo}, CRC press.

In particular, the curly braces are printed. Curly braces are often
used in bib files to indicate that the capitalization is to be
preserved.

Do we want to change the default behavior of the basic processor so
that it correctly handles these cases?

Thanks,
Dominik

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Dominik Schrempf]

FWIW: I have switched to lualatex years ago. In my opinion the additional
compilation time is worth much more than my time debugging problems with
weird symbols. Even when I only use Latin in the main text, most of the
time, there are some special symbols that would need special attention in
the bibliography.

Re: citation biblatex fullcite

[Dominik Schrempf]

Hi Andreas,

thank you for asking this question. I had the same problem, and I think it
should be fixed.

A workaround is described here as part of a lengthy discussion:
https://list.orgmode.org/87r16vtpmp@gmail.com/

(add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))

Then you should be able to use [cite/full:...]

Dominik

Andreas Leha  writes:

> Hi all,
>
> how can I use the (rather) new citation engine with the biblatex backend
> to export to \fullcite ?
>
> The use-case:
> When creating (beamer) presentations I prefer to have the full citation
> on the slide rather than an abbreviation.
>
> Thanks in advance!
>
> Best,
> Andreas

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

I think `fullcite' is OK, although it will be a bit verbose:

┌
│ [cite/fullcite:...]
└


Personally, I don’t mind using `full', and so having a duplicate between a style
and a variant.

But, to be honest, anything is fine with me, as long as it is readily available
and documented.

Thank you!
Dominik

“Bruce D’Arcus”  writes:

> On Wed, Mar 23, 2022 at 6:04 PM Nicolas Goaziou  
> wrote:
>>
>> Hello,
>>
>> “Bruce D’Arcus”  writes:
>>
>> > On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou  
>> > wrote:
>>
>> >> I can add it, but “full” is already the name of a variant, so
>> >> [cite/full: …] and [cite/style/full: …] would mean different things.
>> >> Is this a problem, or do you think of a better style name?
>> >
>> > FWIW, Nicolas, biblatex “fullcite” is equivalent to natbib/bibtex 
>> > “bibentry”.
>> >
>> > That might be a reasonable alternative style name?
>> >
>> >> Also, are there possible variants for this style?
>> >
>> > AFAIK, no.
>>
>> Hmm, OK. What about:
>>
>>   (“fullcite” nil “fullcite” nil nil)
>>
>> ?
>
> Seems fine by me, so long as you use the same name for natbib if and
> when you add bibentry support?
>
> Bruce

=org-cite= links do not work in the =#+title=

[Dominik Schrempf]

  ━━━
NOTES ON 
  ━━━


When using a citation in the title, it does not seem to work when exporting to 
LaTeX.

For example (in the .org file):

Exports to (in the .tex file):

\title{Notes on }

I am using the `biblatex' processor.

Did anybody else encounter this problem?

Dominik

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

“Bruce D’Arcus”  writes:

> On Mon, Mar 21, 2022 at 8:41 AM Dominik Schrempf
>  wrote:
>>
>> Thank you, I can use `citar-insert-edit` to perform this action.
>
> You can actually just use org-cite-insert, which is context aware.
>
>> Now, I failed to create a full citation in the text. This corresponds to the
>> `\fullcite{}’ command in LaTeX. Is there an option for this?
>
> No, but we should add one, as natbib has a similar command.
>
> And, of course, per Timothy’s point, you can customize
> org-cite-biblatex-styles to include it in the meantime. If you want to
> experiment with this, contact me off-list, as there’s some nuances
> with citar.

Great, that was easy, thank you:

(add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))

(This or something similar should be added upstream).

>
>> In summary, it is a bit painful to use `org-cite` compared to using 
>> `org-ref`.
>> In my opinion, the main reasons are:
>>
>> • Documentation is missing for `org-cite`.
>> • The citation commands seem to be incomplete (or at least not documented).
>
> The documentation is admittedly thin. Thoughts on what we should add?
>
> The styles, and how to customize them with oc-biblatex?

I know writing documentation is a lot of work. It is easy to complain, but hard
to contribute. I think we need:
• A complete description of styles and variants (for the actual citation
  command, and also for `#+cite_export: ...') or at least a link to an
  up-to-date table.
• An improved description of the capabilities of `org-cite-insert' (i.e., that
  it can change the citation style and variant).

>
> Bruce

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

Thank you, I can use `citar-insert-edit` to perform this action.

Now, I failed to create a full citation in the text. This corresponds to the
`\fullcite{}' command in LaTeX. Is there an option for this?

In summary, it is a bit painful to use `org-cite` compared to using `org-ref`.
In my opinion, the main reasons are:

• Documentation is missing for `org-cite`.
• The citation commands seem to be incomplete (or at least not documented).

I am aware that all this is a lot of work, and I am really grateful that we have
`org-cite` and `org-ref` available!

Thank you,
Dominik

“Bruce D’Arcus”  writes:

> On Mon, Mar 21, 2022 at 4:24 AM Dominik Schrempf
>  wrote:
>
>> I am trying out `org-cite’ right now. It works much better than the last 
>> time (I
>> am using the `biblatex’ backend right now). However, I can not find any
>> documentation about the available /styles/.
>>
>> They are mentioned here: <https://orgmode.org/manual/Citations.html>
>>
>> But no styles are provided.
>
> I have come to believe the best approach to handling available styles
> and previews is in the style selection UI. So that one can see what
> one is waiting when selecting.
>
> In citar, those styles and preview are currently hard-coded in a
> defcustom, but I’d like to figure out how to do that dynamically,
> using org-cite-supported-styles etc.
>
> In the meantime, Timothy’s article should help (see the table on the styles):
>
> <https://blog.tecosaur.com/tmio/2021-07-31-citations.html>
>
>> For example, I need citations in the text (showing up as “Author(s) (Year)”).
>> With BibTeX, this would be `\citet{}’ (or `\textcite{}’ with BibLaTeX). But
>> there is a lot more. See: 
>> <http://tug.ctan.org/info/biblatex-cheatsheet/biblatex-cheatsheet.pdf>).
>
> You want the “text” style; (NO_ITEM_DATA:doe20), or with the shortcut
> (/t: NO_ITEM_DATA:doe20).
>
> Bruce

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

Hi,

I am trying out `org-cite' right now. It works much better than the last time (I
am using the `biblatex' backend right now). However, I can not find any
documentation about the available /styles/.

They are mentioned here: 

But no styles are provided.

For example, I need citations in the text (showing up as “Author(s) (Year)”).
With BibTeX, this would be `\citet{}' (or `\textcite{}' with BibLaTeX). But
there is a lot more. See: 
).

Thank you for working on `org-cite', and `org-ref'!
Dominik

Timothy  writes:

> Hi John,
>
> Thanks for your considered response.
>
> When you contrast org-cite and org-ref, you say:
>
>> With org-ref, bib(la)tex export is almost fully supported, and is easy,
>
> I find this odd as org-cite supports bib(la)tex export, and rather easily.
>
> ┌
> │ #+bibliography: references.bib
> │ #+cite_export: biblatex authortitle/authortitle-ibid
> │
> │ (NO_ITEM_DATA:key) etc.
> │
> │ #+print_bibliography:
> └
>
> The limitation which I think is on your mind is that not all bib(la)tex 
> commands
> are supported, and not in the “usual” form. For instance, to get `pnotecite’ 
> one
> would use `[cite/locators:]’. However, to get a 1-to-1 name mapping, you can 
> just
> customise `org-cite-biblatex-styles’. For instance, `parencite’ is not 
> currently
> available, but if I just add `(“parencite” nil “parencite” nil nil)’ I can 
> then do
> `[cite/parencite:]’ or if I replace the first `“parencite”’ with `“paren”’, 
> just
> `[cite/paren:]’.
>
> A package could be created, say `org-cite-literal-biblatex’ which is just a 
> copy
> of `oc-biblatex.el’ with a different default `org-cite-biblatex-styles’ and
> `org-cite-biblatex-style-shortcuts’ (or just sets those variables in
> `org-cite-biblatex’). As far as I can tell this would provide exactly the
> functionality you say org-cite can’t provide but org-ref does.
>
> You can already use `.bib’ files, and so frankly I cannot myself see the 
> point in
> org-ref’s existence beyond bifurcating the community on this. At this point 
> the
> only remaining motivation I see is old documents and current users, and for 
> this
> a migration tool seems more appropriate.
>
> I don’t mean to be overly critical, however this is my current honest 
> assessment
> of the situation.
>
> –
> All the best,
> Timothy
>
> John Kitchin  writes:
>
>> I do not think it is productive for the community to say or consider it
>> is a sad situation. Many good things have emerged from these
>> discussions, even if it is not yet consensus on a solution. It is a
>> complex problem, with many years of effort by many people on each side.
>> That is an indication of how ambitious this project is and that there
>> may be more than one solution that is needed. It pains me quite a bit
>> there is a sentiment of fractionation, and that I may be contributing to
>> it.
>>
>> My regular job workload the past few years has been crushing, and I have
>> not had the time to participate in this that I wish I had. I am not sure
>> I can add much here without sounding or feeling defensive about org-ref,
>> and my decision to continue supporting and developing it. I have thought
>> about this for most of the day, and in the (very long, apologies in
>> advance) response that follows I will do my best to provide a balanced
>> perspective (from my point of view) on the situation.
>>
>> Some specific context that is important to me is that I wrote org-ref
>> long ago to solve a specific problem for me in the preparation of
>> scientific publications that are destined for LaTeX export. I intended
>> it to provide nearly equivalent bib(la)tex citation export, and as
>> reasonable an export as possible for everything else. I use org-ref
>> professionally, and it is a complete solution for me. I simply cannot
>> compromise on the capability org-ref provides me, or wait for an
>> alternative complete solution in org-mode. I have work I have to do now,
>> and org-ref lets me do it. This alone is reason enough for me to
>> continue using, developing and supporting org-ref. I understand org is
>> not intended to be a substitute for writing LaTeX, but it is a fact of
>> my job that I have to do that.
>>
>> There are more than 8 years of legacy org-ref documents. I have written
>> 40+ scientific papers with it, and countless technical documents with
>> more than 8000 cite links among them. org-ref has exceeded 190K
>> downloads from MELPA, so I feel obligated to maintain org-ref for
>> myself, and those users. org-ref may be heavyweight in bundling a lot of
>> capability together that could be separated into individual packages,
>> but it is also convenient for people who need it, and a GitHUB issue or
>> pull request away from new features. I remain committed to supporting
>> this, and I do it in a way I can manage, hence the monolithic package
>> design.
>>
>> org-cite was 

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

“Bruce D’Arcus”  writes:

> On Sun, Mar 20, 2022 at 4:21 PM Dominik Schrempf
>  wrote:
>
>> For what it’s worth, I use `org-ref` because fine-grained citation export 
>> with
>> LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
>> `org-cite`.
>
> Part of the challenge is this isn’t an apples-apples comparison;
> org-cite a framework, and it’s the processors that really provide the
> functionality.
>
>> If I remember correctly, `org-cite` exports the formatted citations into the
>> LaTeX file …
>
> This is not true.

Thanks for correcting me on that. I remember having LaTeX files with full
citations in them, but maybe I messed something up.

>
> Or rather, it’s only true if you use the oc-csl export processor; you
> can use other export processors (like oc-biblatex) to get whatever
> LaTeX output you want, and …
>
>>  …. it is really difficult to use different style files, etc. With
>> `org-ref`, I can use BibLaTeX with specific style files. (Journal require
>> different style files). I can even use my personal LaTeX classes (with 
>> specific
>> bibliography styles) for Org export.
>
> … I believe Nicolas recently added support for customizing the
> export styles for biblatex.
>
> Bruce

When I tried setting `org-cite` up, it didn’t work. Maybe I should give it
another try at some point. For now, I am happy with `org-ref`.

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

“Thomas S. Dye”  writes:

> Ihor Radchenko  writes:
>
>> Vikas Rawal  writes:
>>
>>> What is the general view of the community about this? Is there a
>>> comprehensive discussion of pros and cons of each?
>>
>> Prof. Kitchin himself provided a summary on why he decided to give up on
>> using org-cite. See 
>>
> This claim in Kitchin’s summary surprised me:
>
> “It comes down to org-ref using bibtex/biblatex as the predominant citation
> processor, and org-cite using CSL. These two processors have different 
> syntaxes,
> and I don’t think it is possible to have a single approach that works for both
> of them without making compromises in capability.”
>
> I wonder what are the “compromises in capability” required to support both?
>
> I haven’t found them yet, though I’m just now finishing old projects started
> prior to the release of org-cite and haven’t worked through a LaTeX export
> project with it.  My first, and so far only, project with org-cite was for a
> simple html-based presentation using CSL, and I was pleased with the results 
> and
> relative ease of setup.
>
> All the best,
> Tom

For what it’s worth, I use `org-ref` because fine-grained citation export with
LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
`org-cite`.

If I remember correctly, `org-cite` exports the formatted citations into the
LaTeX file, which is a no-go for me (let me know if I am wrong). Then, for
example, it is really difficult to use different style files, etc. With
`org-ref`, I can use BibLaTeX with specific style files. (Journal require
different style files). I can even use my personal LaTeX classes (with specific
bibliography styles) for Org export.

Not sure if this helps…, but this is maybe what John Kitchin is referring to.

Dominik

Org lint and named source blocks

[Dominik Schrempf]

Thank you for the Haskell fix! I found another issue (not a bug but could be
handled better):

Running =org-lint= on an Org file containing

#+NAME:Hello
#+BEGIN_SRC emacs-lisp :exports code
#+END_SRC

I get the following error:
#+begin_quote
Debugger entered--Lisp error: (search-failed "^[ \11]*#\\+[A-Za-z]+: +Hello *$")
#+end_quote

The code is faulty because there should be a space between #+NAME: and Hello,
like so:

#+NAME: Hello
#+BEGIN_SRC emacs-lisp :exports code
#+END_SRC

However, this should probably be reported by =org-lint= as an Org syntax error,
and not lead to an error when executing =org-lint=.

What do you think?

Thank you,
Dominik

Re: Org lint and Haskell source code blocks

[Dominik Schrempf]

Thank you, org-lint works just fine after applying your patch!

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>> whenever I have a Haskell source code block in my Org mode file, and I 
>> execute
>> =org-lint=, I get the following error:
>
> Confirmed.
>
> Can you try with the attached patch?
>
> Best,
> Ihor
>
> [2. text/x-diff; 
> 0001-Fix-org-babel-header-args-haskell-not-being-an-alist.patch]
> From f640249d08a14bfde417c38274634b88c789d1c7 Mon Sep 17 00:00:00 2001
> Message-Id: 
> 
> From: Ihor Radchenko 
> Date: Tue, 21 Sep 2021 15:10:45 +0800
> Subject: [PATCH] Fix org-babel-header-args:haskell not being an alist
>
> * lisp/ob-haskell.el (org-babel-header-args:haskell): The old value of
> the variable was not argument alist, as expected by Org babel code.
>
> Fixes https://orgmode.org/list/87fsty7750@gmail.com
> ---
>  lisp/ob-haskell.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
> index a6f0e55f7..971e1ce6a 100644
> --- a/lisp/ob-haskell.el
> +++ b/lisp/ob-haskell.el
> @@ -70,7 +70,7 @@ (defcustom org-babel-haskell-compiler "ghc"
>:package-version '(Org "9.4")
>:type 'string)
>  
> -(defconst org-babel-header-args:haskell '(compile . :any)
> +(defconst org-babel-header-args:haskell '((compile . :any))
>"Haskell-specific header arguments.")
>  
>  (defun org-babel-haskell-execute (body params)

Org lint and Haskell source code blocks

[Dominik Schrempf]

Hi,

whenever I have a Haskell source code block in my Org mode file, and I execute
=org-lint=, I get the following error:

#+begin_quote
Debugger entered--Lisp error: (wrong-type-argument listp :any)
#+end_quote

(This was obtained with a minimal file just having:
#+BEGIN_SRC haskell
inc n = n+1
#+END_SRC
)

Do you have an idea about what could be the problem? =org-lint= works just fine
in other buffers without Haskell code blocks.

Please find the full error message below.

Thank you,
Dominik

--

Debugger entered--Lisp error: (wrong-type-argument listp :any)
  mapcar(car (compile . :any))
  #f(compiled-function (l) #)("haskell")
  mapcan(#f(compiled-function (l) #) ("haskell"))
  cl-mapcan(#f(compiled-function (l) #) ("haskell"))
  #f(compiled-function (datum language headers) #)((src-block (:language "haskell" :switches nil :parameters nil 
:begin 1 :end 43 :number-lines nil :preserve-indent nil :retain-labels t 
:use-labels t :label-fmt nil :value "inc n = n+1\n" :post-blank 0 
:post-affiliated 1 :parent (section (:begin 1 :end 43 :contents-begin 1 
:contents-end 43 :post-blank 0 :post-affiliated 1 :parent (org-data nil #31)) 
#1))) "haskell" nil)
  #f(compiled-function (datum) #)((src-block (:language 
"haskell" :switches nil :parameters nil :begin 1 :end 43 :number-lines nil 
:preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "inc 
n = n+1\n" :post-blank 0 :post-affiliated 1 :parent (section (:begin 1 :end 43 
:contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent 
(org-data nil #31)) #1
  #f(compiled-function (--data) #)((src-block (:language 
"haskell" :switches nil :parameters nil :begin 1 :end 43 :number-lines nil 
:preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "inc 
n = n+1\n" :post-blank 0 :post-affiliated 1 :parent (section (:begin 1 :end 43 
:contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent 
(org-data nil #31)) #1
  mapc(#f(compiled-function (--data) #) ((src-block 
(:language "haskell" :switches nil :parameters nil :begin 1 :end 43 
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t 
:label-fmt nil :value "inc n = n+1\n" :post-blank 0 :post-affiliated 1 :parent 
(section (:begin 1 :end 43 :contents-begin 1 :contents-end 43 :post-blank 0 
:post-affiliated 1 :parent (org-data nil #33)) . #2)
  #f(compiled-function (--data) #)((section (:begin 1 :end 
43 :contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent 
(org-data nil #1)) (src-block (:language "haskell" :switches nil :parameters 
nil :begin 1 :end 43 :number-lines nil :preserve-indent nil :retain-labels t 
:use-labels t :label-fmt nil :value "inc n = n+1\n" :post-blank 0 
:post-affiliated 1 :parent #1
  mapc(#f(compiled-function (--data) #) ((section (:begin 1 
:end 43 :contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 
:parent (org-data nil . #2)) (src-block (:language "haskell" :switches nil 
:parameters nil :begin 1 :end 43 :number-lines nil :preserve-indent nil 
:retain-labels t :use-labels t :label-fmt nil :value "inc n = n+1\n" 
:post-blank 0 :post-affiliated 1 :parent #3)
  #f(compiled-function (--data) #)((org-data nil (section 
(:begin 1 :end 43 :contents-begin 1 :contents-end 43 :post-blank 0 
:post-affiliated 1 :parent #1) (src-block (:language "haskell" :switches nil 
:parameters nil :begin 1 :end 43 :number-lines nil :preserve-indent nil 
:retain-labels t :use-labels t :label-fmt nil :value "inc n = n+1\n" 
:post-blank 0 :post-affiliated 1 :parent #4)
  org-element-map((org-data nil (section (:begin 1 :end 43 :contents-begin 1 
:contents-end 43 :post-blank 0 :post-affiliated 1 :parent #1) (src-block 
(:language "haskell" :switches nil :parameters nil :begin 1 :end 43 
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t 
:label-fmt nil :value "inc n = n+1\n" :post-blank 0 :post-affiliated 1 :parent 
#4 (babel-call inline-babel-call inline-src-block keyword node-property 
src-block) #f(compiled-function (datum) #))
  org-lint-wrong-header-argument((org-data nil (section (:begin 1 :end 43 
:contents-begin 1 :contents-end 43 :post-blank 0 :post-affiliated 1 :parent #1) 
(src-block (:language "haskell" :switches nil :parameters nil :begin 1 :end 43 
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t 
:label-fmt nil :value "inc n = n+1\n" :post-blank 0 :post-affiliated 1 :parent 
#4)
  #f(compiled-function (c) #)(#s(org-lint-checker :name 
wrong-header-argument :description "Report wrong babel headers" :categories 
(babel) :trust high))
  mapcan(#f(compiled-function (c) #) (#s(org-lint-checker 
:name duplicate-custom-id :description "Report duplicates CUSTOM_ID prop..." 
:categories (link) :trust high) #s(org-lint-checker :name duplicate-name 
:description "Report duplicate NAME values" :categories (babel link) :trust 
high) #s(org-lint-checker :name duplicate-target :description "Report duplicate 
targets" 

Re: Org babel source blocks ignore buffer-local variables

[Dominik Schrempf]

Thank you, this solution works. May I ask about the reasons of such a
distinction?

Dominik

"Berry, Charles"  writes:

>> On Sep 4, 2021, at 5:30 AM, Dominik Schrempf  
>> wrote:
>> 
>> Hello,
>> 
>> I use directory local environments with =envrc= [1], and run into trouble 
>> when
>> using (Bash) Org Babel source code blocks. The buffer local environment 
>> seems to
>> be ignored (see the example at the bottom).
>> 
>> This seems to have been discussed in the course of a GitHub issue of
>> =inheritenv= [2], which is pulled in by =envrc=. Also, on this mailing list,
>> there was a short discussion [3].
>> 
>> Do you have any thoughts on this? Is there an easy way to make Org Babel 
>> source
>> blocks honor buffer local setups?
>> 
>> Thank you!
>> Dominik
>> 
>> #+name: Scratch
>> #+begin_src sh :exports both :results output verbatim
>> function path () { echo "$PATH" | tr ':' '\n'; }
>> path
>> #+end_src
>> 
>> #+RESULTS: Scratch
>> #+begin_example
>> /home/dominik/Evolutionary-Biology/Scripts/nix-flakes
>> /home/dominik/Evolutionary-Biology/Scripts
>> /home/dominik/bin/nix-flakes
>> /home/dominik/bin
>> /run/wrappers/bin
>> /home/dominik/.nix-profile/bin
>> /etc/profiles/per-user/dominik/bin
>> /nix/var/nix/profiles/default/bin
>> /run/current-system/sw/bin
>> /nix/store/3l9lddwxz1mayaxvw8iy50ygzzfh1s1b-emacs-27.2/libexec/emacs/27.2/x86_64-pc-linux-gnu
>> #+end_example
>> 
>> The Emacs =exec-path= variable has the following value:
>> 
>> #+begin_quote
>> exec-path is a variable defined in ‘C source code’.
>> Its value is
>> ("/nix/store/cnxncxyghj3gfpfvng6z4l8k4hfl48wq-ghc-8.10.6-with-packages/bin/" 
>> "/nix/store/435paza0j48aa9vgvf6r2l12nrg4ld11-patchelf-0.12/bin/" 
>
> [snip]
>
> Indeed, ~exec-path~ and ~(getenv "PATH")~ can differ.
>
> If you want to set PATH for a shell src block, you can do something like:
>
> #+begin_src sh :results output verbatim :var PATH=(mapconcat 'identity 
> exec-path ":")
>   echo $PATH
> #+end_src
>
> HTH,
>
> Chuck
>
>   

Org babel source blocks ignore buffer-local variables

[Dominik Schrempf]

Hello,

I use directory local environments with =envrc= [1], and run into trouble when
using (Bash) Org Babel source code blocks. The buffer local environment seems to
be ignored (see the example at the bottom).

This seems to have been discussed in the course of a GitHub issue of
=inheritenv= [2], which is pulled in by =envrc=. Also, on this mailing list,
there was a short discussion [3].

Do you have any thoughts on this? Is there an easy way to make Org Babel source
blocks honor buffer local setups?

Thank you!
Dominik

#+name: Scratch
#+begin_src sh :exports both :results output verbatim
function path () { echo "$PATH" | tr ':' '\n'; }
path
#+end_src

#+RESULTS: Scratch
#+begin_example
/home/dominik/Evolutionary-Biology/Scripts/nix-flakes
/home/dominik/Evolutionary-Biology/Scripts
/home/dominik/bin/nix-flakes
/home/dominik/bin
/run/wrappers/bin
/home/dominik/.nix-profile/bin
/etc/profiles/per-user/dominik/bin
/nix/var/nix/profiles/default/bin
/run/current-system/sw/bin
/nix/store/3l9lddwxz1mayaxvw8iy50ygzzfh1s1b-emacs-27.2/libexec/emacs/27.2/x86_64-pc-linux-gnu
#+end_example

The Emacs =exec-path= variable has the following value:

#+begin_quote
exec-path is a variable defined in ‘C source code’.
Its value is
("/nix/store/cnxncxyghj3gfpfvng6z4l8k4hfl48wq-ghc-8.10.6-with-packages/bin/" 
"/nix/store/435paza0j48aa9vgvf6r2l12nrg4ld11-patchelf-0.12/bin/" 
"/nix/store/4xs1xyj8728yvh9y5v6ji819kwgfy2fv-gcc-wrapper-10.3.0/bin/" 
"/nix/store/dlni53myj53kx20pi4yhm7p68lw17b07-gcc-10.3.0/bin/" 
"/nix/store/6z35qvn00xrjvaznv9kfy8xddbbdz4gl-glibc-2.33-47-bin/bin/" 
"/nix/store/1570w56jrkvr90w9x158vyb5vahnk18v-coreutils-8.32/bin/" 
"/nix/store/29bjq5hw1qglybp1a5f3ij9gxc2fyf94-binutils-wrapper-2.35.1/bin/" 
"/nix/store/v8imx1nvyz0hgvx9cbcmh6gp4ngw3ffj-binutils-2.35.1/bin/" 
"/nix/store/iz7bgfvjmwdz3vgmzryhfkqwbn8zr2jn-ncurses-6.2/bin/" 
"/nix/store/w07a7k61dw5gnsyxj3kgcq3shr76jax8-bash-interactive-4.4-p23/bin/" 
"/nix/store/xhxll8hx0x9szhlvvd8h1c35glszlj34-cabal-install-3.4.0.0/bin/" 
"/nix/store/gbxdjp9z1bjx1zl6icckw093yv0vn21r-haskell-language-server-1.2.0.0/bin/"
 "/nix/store/mx8v4f0hq8nff5ab7mcgmmbxn5rk6al4-aeson-pretty-0.8.8/bin/" 
"/nix/store/xygkar338ssrwqjcpmmbv1pkkpqc1yfy-ghc-8.10.6/bin/" 
"/nix/store/w16zhm17a73sn3sshqgpxjk3r265vb9l-ghcide-1.4.0.3/bin/" 
"/nix/store/isja3hvzjmmg7278mdsyyn0k4s7k6cf8-constraints-extras-0.3.1.0/bin/" 
"/nix/store/9kz9pwpgnq4miywf5bk97xpn4qqz1h2c-hie-bios-0.7.5/bin/" 
"/nix/store/wfpjw96bjc1kwx5spddwgpi8r4jrbc6b-hiedb-0.4.0.0/bin/" 
"/nix/store/il7l9fjr7r0sq00iy0jr6pcwcb97227p-shake-0.19.5/bin/" 
"/nix/store/9i7z6c6ydhkw1ch37hvpi6fywbfkyrm0-implicit-hie-0.1.2.6/bin/" 
"/nix/store/88kdasbl46rhfnz249dxnh5n9amr27pv-retrie-1.0.0.0/bin/" 
"/nix/store/i7djw6911qk0vkkxv5rsm2zh95arfmjp-brittany-0.13.1.2/bin/" 
"/nix/store/5mpyw1f5jamnvnhsawj147vyvwpw054s-floskell-0.10.5/bin/" 
"/nix/store/aj2q5q38wzlsl60vwcxirlc133p3i8hj-fourmolu-0.3.0.0/bin/" 
"/nix/store/mr0algmndmq73ybhnk3752ylhpnp7918-apply-refact-0.9.3.0/bin/" 
"/nix/store/k9h1adjqqwmq39iik3253cgxdd5drgz8-hlint-3.2.7/bin/" 
"/nix/store/rdjb7sx4clhzjfal0xhb41x1k62nchf0-cpphs-1.20.9.1/bin/" 
"/nix/store/wlh74ffhf19ychrcf65885jsx8xy5f8d-hscolour-1.24.4/bin/" 
"/nix/store/1lbb1bzjqcblb946av3703g76ng18jx1-ormolu-0.1.4.1-bin/bin/" 
"/nix/store/jvx2rcmbcrjpsvz4p8z5zll4gchmhl75-stylish-haskell-0.12.2.0/bin/" 
"/nix/store/h0yyp8i85y3cahd1wyxb0a0izxqz2gxj-stack-2.7.3/bin/" 
"/nix/store/62m5yxq7f9gz4xn3qlvkvkna237vz92k-hpack-0.34.4/bin/" 
"/nix/store/ki59g3c2y2ahpjja9hch3wxgl7gki5f3-mustache-2.3.1/bin/" 
"/nix/store/1wdm2g4mz9is77iihfkbycq3m8c2frrv-open-browser-0.2.1.0/bin/" 
"/nix/store/1570w56jrkvr90w9x158vyb5vahnk18v-coreutils-8.32/bin/" 
"/nix/store/ihxk2vlm0vi7c4j3gpm084kbxvz6v585-findutils-4.8.0/bin/" 
"/nix/store/kjx1mv85c5cgsrr4bwar22j7hbwj834m-diffutils-3.7/bin/" 
"/nix/store/gm2w08wwsa3vd500d8vq879s2lv65ldh-gnused-4.8/bin/" 
"/nix/store/v0slhpb2y3xa7gmv4q6gblkdk7n0f09j-gnugrep-3.6/bin/" 
"/nix/store/2wn093wbc6ps4brcsppxjd14vxvaa8a2-gawk-5.1.0/bin/" 
"/nix/store/5bxrjkyvqmzn1p897652y3lwa9fxagpw-gnutar-1.34/bin/" 
"/nix/store/liva1jnjdskrn57s42kfawr2zz66szzm-gzip-1.10/bin/" 
"/nix/store/ih2zkh2mbrx2c766ryk2i9hhlkly7snr-bzip2-1.0.6.0.2-bin/bin/" 
"/nix/store/pvkiiw0mp1yx0b21b7k105yywccychgh-gnumake-4.3/bin/" 
"/nix/store/dpjnjrqbgbm8a5wvi1hya01vd8wyvsq4-bash-4.4-p23/bin/" 
"/nix/store/aicl3kwfnaizk45aygm8bviqv7lk0a16-patch-2.7.6/bin/" 
"/nix/store/7jk6k46f56rszzc1bxi8mdrvcw53pym4-xz-5.2.5-bin/bin/" 
"/home/dominik/Evolutionary-Biology/Scripts/nix-flakes/" 
"/home/dominik/Evolutionary-Biology/Scripts/" "/home/dominik/bin/nix-flakes/" 
"/home/dominik/bin/" "/run/wrappers/bin/" "/home/dominik/.nix-profile/bin/" 
"/etc/profiles/per-user/dominik/bin/" "/nix/var/nix/profiles/default/bin/" 
"/run/current-system/sw/bin/" 
"/nix/store/3l9lddwxz1mayaxvw8iy50ygzzfh1s1b-emacs-27.2/libexec/emacs/27.2/x86_64-pc-linux-gnu/")
Original value was 
("/nix/store/cnxncxyghj3gfpfvng6z4l8k4hfl48wq-ghc-8.10.6-with-packages/bin" 

Re: Emacs as an Org LSP server

[Dominik Schrempf]

Hello!

I am infrequent active participant on this list but follow some discussions.
This one I found particularly interesting. I do see both of your points Tim
Cross, and Jean Louis, thank you for your detailed explanations including the
references.

As a user of Emacs and Org mode (and not so much as a developer), I am mostly
interested in an editor that works well with the features and languages I use.
For example, I am writing a lot of Haskell, and the Haskell Language Server
provides excellent development support. The Haskell Language Server is not
developed exclusively by Emacs users. To the contrary, it's probably developed
mostly by non-Emacs users. Would I use Emacs to write Haskell code if I could
not use the Haskell Language Server? I don't know although I love Emacs. (I am
sure I would, but I would be a little disappointed).

More generally, on https://langserver.org/ I found a very good argument for why
we need a specification such as the LSP.

I quote:

The problem: "The Matrix"
   Go   JavaTypeScript  ...
Emacs  X  X X
VimX  X X
VSCode X  X X
...

The solution: Lang[uage] servers and clients
Go X
Java   X
TypeScript X
...

Emacs  X
VimX
VSCode X

I think this is an excellent idea. However, I am not familiar with the legal
aspects mentioned by Jean. So far I had good experiences with language servers.
On the other side, Org mode is Emacs specific, so this argument does not really
apply. Do we want Org mode to stay Emacs specific? I don't know.

Dominik

Jean Louis  writes:

> There is definitely nothing wrong in providing Org language server
> that runs for different editors who could support the LSP protocol, it
> will boost collaboration.
>
> That is pretty much separate subject of the centralization and
> strategies we spoke about.
>
> * Tim Cross  [2020-12-14 23:19]:
>> This is just ill informed nonsense. The LSP is nothing more than a
>> specification. The fact it was initially defined/proposed by Microsoft
>> is completely irrelevant.
>
> I truly wish it would be that simple.
>
> There are many tools and inventions by Microsoft. Some of them appear
> to be free, but all of them are there to contribute to profit
> making. I am not against profit making. But we have to look into the
> tool as having the purpose to contribute to THEIR profit
> making. History of Microsoft is clear. Sorry, I do not share the
> narrowed viewpoint that they will invest so much money "to help other
> free software developers". That it is defined by Microsoft in
> collaboration with others is very relevant there.
>
> First question to clarify is if it is really patented or not. While
> you as user you can download some Rust server software or Java
> software and run server that will work with various editors, somebody
> else may not be able to do so if there is patent on it. That imposes
> freedom obstacles in future.
>
> Does this patent description correspond to the subject:
> https://uspto.report/patent/app/20190149346
>
>> It is NOT server based in the sense you mean. In fact, it is
>> actually precisely what you argue it should be. LSP is simply a
>> "generic definitions how editor could act, and editor could load
>> those generic definitions locally."
>
> I am well aware that you as user may download the piece of software
> and run it as server on your computer and that you wish to distinguish
> how user may not need a remote server. We clarified this
> already.
>
> Corporation will not have use of your personal use, they will promote
> their servers and push people to get hooked and trapped into it. It
> will become questionable if other entities become able to do the same
> if such process is patented.
>
> That it is server based should be undisputable. The whole protocol
> speaks of sparing client's CPU time, so CPU time will be spared when
> process does not run on the same CPU. You can run it now for
> yourself. Sure. But the strategy is visible from their very open
> descriptions. Large company is not interested in those single
> users. Single users had "git" under their control but nobody had
> enough money and power to centralize 50 million developers.
>
> Innocent example is: https://melpa.org/#/lsp-pascal package that
> requires: https://github.com/arjanadriaanse/pascal-language-server
>
> But it is made and designed as a server for third parties to take
> advantage of it one time in future.
>
> https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
>
> If one would like to improve all editors to use centralized
> specifications than that could be done also by providing server-less
> specification that every editor could load and thus function in the
> same way. Then editor developers could make their underlying language
> module that would understand the extension
> specificiation. Then users would just need to import or load the
> general specification something like XML file or similar type of a
> document that 

Re: The Website Revamp: The final stretch

[Dominik Schrempf]

Hello,

thank you very much for working on the new Org Mode web site!

Just one thing which might already have been said:

The scrolling is weird. I use keys to scroll the browser, and there is a delay
and some weird smooth scrolling behavior. Is this desired?

Thanks,
Dominik

TEC  writes:

> Hello everyone,
>
> I'm pleased to announce that after chatting with Bastien, my little
> revamp project seems to be nearing the point where it may replace the
> current site.
>
> Two things that would be good to get sorted:
> 1. Translation of the index page to French/Japanese ::
>I'm english only, and Bastien is busy, so volunteers would be much
>   appreciated!
> 2. Picking the best 'Hero banner' on the home page ::
>Concerns were raised over the lack of contrast between the logo and
>the current banner background. I've chatted to someone else with
>some ideas and we've produced a few concepts which we'd like to get
>your feedback on.
>See the file attached, and if you could give say your top three
>picks (ordered), and any relevant reasoning/considerations/comments
>that would be great!
>
> All the best,
>
> Timothy.
>
> p.s. I haven't had much luck with attachments in the past, if this fails
> I'll reply with the attachment.

Re: multiple EXPORT_LATEX_HEADER lines

[Dominik Schrempf]

Hello,

are you looking for, e.g.,

#+latex_header: \addbibresource{bibliography.bib}
#+latex_header_extra: do some stuff
#+latex_header_extra: and even more

I don't use the EXPORT keyword at the beginning, I am not sure if it is needed.

Best,
Dominik

Alan Schmitt  writes:

> Hello,
>
> I would like to have a multi-line export header when exporting a
> subtree. I tried this:
>
> :EXPORT_LATEX_HEADER: \makeatletter
> :EXPORT_LATEX_HEADER+: \@setplength{refvpos}{\useplength{toaddrvpos}}
> :EXPORT_LATEX_HEADER+: \makeatother
>
> The problem is that it's exported on a single line, and as such it does
> not work. Is there a way to have the multiple properties exported as
> multiple lines, or to specify in the property there is a line break?
>
> Thanks,
>
> Alan

Re: Necessity of `org-fill-paragraph'

[Dominik Schrempf]

Dear Nicolas!

Thank you for your fast reply! I now use a custom =org-unfill-toggle= which does
the same as =unfill-toggle= but uses =org-fill-paragraph=. It just took me a
while to see where the problem lies! For cases like these, it would be
advantageous if major modes could redefine certain functions. Like
=fill-paragraph= in this case. Instead, they usually (have to?) rebind the
keys...

Kind regards,
Dominik

Nicolas Goaziou  writes:

> Hello,
>
> Dominik Schrempf  writes:
>
>> I am using a global keybinding for =M-q=, so that I can fill and unfill
>> paragraphs with one key stroke (unfill.el):
>>
>> : (global-set-key (kbd "s-q") 'unfill-toggle)
>>
>> For a long time, I thought that =fill-paragraph= was broken in Org mode, 
>> because
>> it doesn't work well on code blocks, on lists, and on many other things [1].
>> Just now, I realized that Org mode uses a specialized version of
>> `fill-paragraph`, called `org-fill-paragraph`.
>>
>> Hence, the aforementioned global key binding breaks behavior in Org mode,
>> although the function =unfill-toggle= is just a wrapper around
>> =fill-paragraph=.
>
> You could detect if you're in an Org document beforehand.
> `org-fill-paragraph' obeys to `fill-column'.
>
>> Is it necessary to have the specialized function =org-fill-paragraph=? Is it
>> possible to use the canonical =fill-paragraph=?
>
> There is `fill-paragraph-function', but it only kicks when no region is
> selected. Using it would break region filling. There is also
> `fill-forward-paragraph-function', but I think it is too limited.
>
> In a nutshell, I didn't find any way to fill correctly Org documents
> using `fill-paragraph' mechanism. So I wrote the current implementation
> of `org-fill-paragraph', which is a wrapper around `org-fill-element'.
>
> Regards,

Necessity of `org-fill-paragraph'

[Dominik Schrempf]

Hello,

I am using a global keybinding for =M-q=, so that I can fill and unfill
paragraphs with one key stroke (unfill.el):

: (global-set-key (kbd "s-q") 'unfill-toggle)

For a long time, I thought that =fill-paragraph= was broken in Org mode, because
it doesn't work well on code blocks, on lists, and on many other things [1].
Just now, I realized that Org mode uses a specialized version of
`fill-paragraph`, called `org-fill-paragraph`.

Hence, the aforementioned global key binding breaks behavior in Org mode,
although the function =unfill-toggle= is just a wrapper around =fill-paragraph=.

Is it necessary to have the specialized function =org-fill-paragraph=? Is it
possible to use the canonical =fill-paragraph=?

Thanks,
Dominik

[1] https://github.com/syl20bnr/spacemacs/issues/13384

Re: [O] Feature Proposal: Titled Paragraphs

[Dominik Schrempf]

Hello!

I agree with this proposal. At some point I already asked if the following
structure is possible:

#+begin_example
* Title
** Section I
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor
tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis
eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis
parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor.
Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum.
Nam vestibulum accumsan nisl.

Another paragraph that is not related to Section I, but doesn't deserve a
section title. Another paragraph that is not related to Section I, but doesn't
deserve a section title. Another paragraph that is not related to Section I, but
doesn't deserve a section title. Another paragraph that is not related to
Section I, but doesn't deserve a section title.
#+end_example

With titled paragraphs, this document structure could be achieved.

All the best,
Dominik

Christoph Michelbach  writes:

> On 2019-10-23 15:24, Fraga, Eric wrote:
>> Why not use a further headline if you are exporting to LaTeX?  In the
>> default configuration, the 4th level heading corresponds to \paragraph
>> in LaTeX.
>>
>
> 1. Because headlines and paragraphs are different things. One is used for
> hierarchical structuring and description, the other only for description.
> 2. Because that'd mean skipping hierarchical levels when using paragraphs on a
> high level.
> 3. Because headlines are collapsed by default. I realize the default can be
> changed but if you like hierarchical levels to be collapsed, you still have to
> expand paragraphs far up individually or expand all the hierarchical levels
> below by dobule-tabbing.

[O] org-lint reports non-existent file for html links

[Dominik Schrempf]

Hi,

I have the following in-buffer variable set:

#+SETUPFILE: https://path/to/some/setupfile.setup

Org lint reports

17 low   Non-existent setup file "https://path/to/some/seutpfile.setup

This is true, but also not very relevant. Should we check for URLs with
org-lint?

Kind regards,
Dominik

Re: [O] Latex export with \begin{equation}

[Dominik Schrempf]

Hello,

I tried to follow your suggestions. Please let me know, if the patch is OK like
this.

The patch only adds one footnote. It is unfortunate, that all subsequent
footnotes are changed too.

Best,
Dominik

>From 4b97952b0d6d218de7d7cab6f7017f87b68b966c Mon Sep 17 00:00:00 2001
From: Dominik Schrempf 
Date: Tue, 18 Sep 2018 15:04:47 +0200
Subject: [PATCH] Mention peculiarities of Math in HTML code. TINYCHANGE.

---
 doc/org-manual.org | 132 +++--
 1 file changed, 68 insertions(+), 64 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 0732c1d97..90b2dbd12 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12638,7 +12638,7 @@ is.
 #+vindex: org-html-mathjax-options~
 LaTeX math snippets (see [[*LaTeX fragments]]) can be displayed in two
 different ways on HTML pages.  The default is to use the [[http://www.mathjax.org][MathJax]],
-which should work out of the box with Org[fn:123].  Some MathJax
+which should work out of the box with Org[fn:123][fn:124].  Some MathJax
 display options can be configured via ~org-html-mathjax-options~, or
 in the buffer.  For example, with the following settings,
 
@@ -12650,7 +12650,7 @@ in the buffer.  For example, with the following settings,
 #+texinfo: @noindent
 equation labels are displayed on the left margin and equations are
 five em from the left margin.  In addition, it loads the two MathJax
-extensions =cancel.js= and =noErrors.js=[fn:124].
+extensions =cancel.js= and =noErrors.js=[fn:125].
 
 #+vindex: org-html-mathjax-template
 See the docstring of ~org-html-mathjax-options~ for all supported
@@ -12713,7 +12713,7 @@ line.
 #+vindex: org-export-html-todo-kwd-class-prefix
 #+vindex: org-export-html-tag-class-prefix
 You can modify the CSS style definitions for the exported file.  The
-HTML exporter assigns the following special CSS classes[fn:125] to
+HTML exporter assigns the following special CSS classes[fn:126] to
 appropriate parts of the document---your style specifications may
 change these, in addition to any of the standard classes like for
 headlines, tables, etc.
@@ -12953,7 +12953,7 @@ LaTeX export back-end finds the compiler version to use from
 Org file.  See the docstring for the
 ~org-latex-default-packages-alist~ for loading packages with certain
 compilers.  Also see ~org-latex-bibtex-compiler~ to set the
-bibliography compiler[fn:126].
+bibliography compiler[fn:127].
 
 *** LaTeX specific export settings
 :PROPERTIES:
@@ -13564,7 +13564,7 @@ a limit to a level before the absolute limit (see [[*Export Settings]]).
 
 The ODT export back-end handles creating of OpenDocument Text (ODT)
 format.  Documents created by this exporter use the
-{{{cite(OpenDocument-v1.2 specification)}}}[fn:127] and are compatible
+{{{cite(OpenDocument-v1.2 specification)}}}[fn:128] and are compatible
 with LibreOffice 3.4.
 
 *** Pre-requisites for ODT export
@@ -13965,7 +13965,7 @@ document in one of the following ways:
  variables ~org-latex-to-mathml-convert-command~ and
  ~org-latex-to-mathml-jar-file~.
 
- If you prefer to use MathToWeb[fn:128] as your converter, you can
+ If you prefer to use MathToWeb[fn:129] as your converter, you can
  configure the above variables as shown below.
 
  #+begin_src emacs-lisp
@@ -13975,7 +13975,7 @@ document in one of the following ways:
"/path/to/mathtoweb.jar")
  #+end_src
 
- To use LaTeX​ML[fn:129] use
+ To use LaTeX​ML[fn:130] use
 
  #+begin_src emacs-lisp
  (setq org-latex-to-mathml-convert-command
@@ -14295,7 +14295,7 @@ with the =#+ATTR_ODT= line.  For a discussion on default formatting of
 tables, see [[*Tables in ODT export]].
 
 This feature closely mimics the way table templates are defined in the
-OpenDocument-v1.2 specification.[fn:130]
+OpenDocument-v1.2 specification.[fn:131]
 
 #+vindex: org-odt-table-styles
 For quick preview of this feature, install the settings below and export the
@@ -14329,7 +14329,7 @@ templates, define new styles there.
 
 To use this feature proceed as follows:
 
-1. Create a table template[fn:131].
+1. Create a table template[fn:132].
 
A table template is set of =table-cell= and =paragraph= styles for
each of the following table cell categories:
@@ -14368,7 +14368,7 @@ To use this feature proceed as follows:
== element of the content template file
(see [[x-orgodtcontenttemplate-xml][Factory styles]]).
 
-2. Define a table style[fn:132].
+2. Define a table style[fn:133].
 
#+vindex: org-odt-table-styles
To define a table style, create an entry for the style in the
@@ -15395,7 +15395,7 @@ If you want to publish the Org file as an =.org= file but with
 ~org-publish-org-to-org~.  This produces =file.org= and put it in the
 publishing directory.  If you want a htmlized version of this file,
 set the parameter ~:htmlized-source~ to ~t~.  It produces
-=file.org.html= in the publishing directory[fn:133].
+=file.org.html= in t

Re: [O] Latex export with \begin{equation}

[Dominik Schrempf]

Oh thanks,

I thought it would be good to add a comment to the Org mode manual although it
is of course not really Org mode related.

I decided that a good location would be
https://orgmode.org/manual/Math-formatting-in-HTML-export.html#Math-formatting-in-HTML-export

A proposed patch is attached, please let me know what you think.

Best,
Dominik

--- org-manual.org	2018-09-17 18:48:17.868785307 +0200
+++ org-manual.org.new	2018-09-17 18:48:09.708751068 +0200
@@ -12655,7 +12655,9 @@
 #+vindex: org-html-mathjax-template
 See the docstring of ~org-html-mathjax-options~ for all supported
 variables.  The MathJax template can be configure via
-~org-html-mathjax-template~.
+~org-html-mathjax-template~.  Please note that formulas will be part
+of an HTML document, and that signs such as =<=, =>=, or =&= have
+special meanings (see [[http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX support]]).
 
 If you prefer, you can also request that LaTeX fragments are processed
 into small images that will be inserted into the browser page.  Before


Nick Dokos  writes:


Dominik Schrempf  writes:



so I found the reason. Both Org versions behave the same, sorry for the
confusion. The original equation that does not get exported correctly 
contained

angles:

\begin{equation}
  = \frac{\sum_i w_i k_{eff}(i)}{\sum_i w_i}.
\end{equation}

This equation is correctly rendered when using a .tex file and native LaTeX.
If the angles are removed, the Org Mode HTML export works:

\begin{equation}
 k_{eff} = \frac{\sum_i w_i k_{eff}(i)}{\sum_i w_i}.
\end{equation}

Does anybody know why? Is this expected behavior? Can this be changed?



Maybe this explains it:

"...Also, since the mathematics is initially given as text on the
page, you need to be careful that your mathematics doesn’t look like
HTML tags to the browser (which parses the page before MathJax gets to
see it). In particular, that means that you have to be careful about
things like less-than and greater-than signs (< and >), and ampersands
(&), which have special meaning to the browsers. For example,

... when $xhttp://docs.mathjax.org/en/latest/tex.html

the section entitled "TeX and LaTeX in HTML documents":

Re: [O] Latex export with \begin{equation}

[Dominik Schrempf]

Hi,

so I found the reason. Both Org versions behave the same, sorry for the
confusion. The original equation that does not get exported correctly contained
angles:

\begin{equation}
  = \frac{\sum_i w_i k_{eff}(i)}{\sum_i w_i}.
\end{equation}

This equation is correctly rendered when using a .tex file and native LaTeX.
If the angles are removed, the Org Mode HTML export works:

\begin{equation}
 k_{eff} = \frac{\sum_i w_i k_{eff}(i)}{\sum_i w_i}.
\end{equation}

Does anybody know why? Is this expected behavior? Can this be changed?

Dominik Schrempf  writes:


Hi,

I have the following document:

\begin{equation}
foobar
\end{equation}

I perform an HTML export.

The equation is not rendered with MathJax when using Org Mode 9.1.14
(Spacemacs).

The equation is correctly rendered with =emacs -Q=; then, Org Mode 9.1.9 is
used.

I am sure that Spacemacs sets other variables that may influence the HTML
export, but even then LaTeX export works perfectly when using dollar signs to
mark the equation.

Help much appreciated!

Thanks,
Dominik

[O] Latex export with \begin{equation}

[Dominik Schrempf]

Hi,

I have the following document:

\begin{equation}
foobar
\end{equation}

I perform an HTML export.

The equation is not rendered with MathJax when using Org Mode 9.1.14
(Spacemacs).

The equation is correctly rendered with =emacs -Q=; then, Org Mode 9.1.9 is 
used.


I am sure that Spacemacs sets other variables that may influence the HTML
export, but even then LaTeX export works perfectly when using dollar signs to
mark the equation.

Help much appreciated!

Thanks,
Dominik

[O] Org-capture, empty lines and date tree

[Dominik Schrempf]

Hi,

I am using date trees with org-capture with the =:empty-lines n= directive.
The list item of =org-capture-templates= looks similar to this one:

#+BEGIN_EXAMPLE
(list "j" "Journal" 'entry
 (list 'file+olp+datetree journal-file)
 "* %^{Entry}\n%?\n"
 :empty-lines 1)
#+END_EXAMPLE

Now, whenever a new day is inserted, for instance today,

: *** 2018-04-06 Friday

There is no empty line before that line but between this line and the actual
headline of the captured entry. So the complete captured entry looks like this:

: Some text in the file that was already present before the Org capture process.
: Bla.
: *** 2018-04-06 Friday
:
:  TODO The newly captured entry
:  Some text.

However, I think it should rather look like this:

: Some text in the file that was already present before the Org capture process.
: Bla.
:
: *** 2018-04-06 Friday
: (OPTIONAL EMPTY LINE HERE)
:  TODO The newly captured entry
:  Some text.

Only, if I enter another entry, the line should be left empty, like

: Some text in the file that was already present before the Org capture process.
: Bla.
:
: *** 2018-04-06 Friday
: (OPTIONAL EMPTY LINE HERE)
:  TODO The newly captured entry
:  Some text.
: (MANDATORY EMPTY LINE HERE)
:  TODO The new newly captured entry
:  Bla bla bla.

Please let me know what you think.

Dominik

[O] [Capture] Monthly/weekly date tree

[Dominik Schrempf]

Hello,

I am interested in a capture template that creates date trees collected into
months (or weeks as another possibility). The reason is that creating a headline
for each day (=file+old+datetree=) is too precise for my use cases and hides
information in unnecessarily deep headlines.

An example:

: * 2017
: ** 2017-11 November
: *** An interesting captured headline
: With some very interesting details.
: * 2018
: ** 2018-02 February
: *** Another headline which has been captured
: And so on.
: *** Another one
: --> The newly captured headline should be appended here

Is this feature already available or how could I imitate this feature? If not,
would you be positive towards a possible pull request from my side (would take
me a while because I am not a lisp expert)?

Thanks,
Dominik

[O] Org capture + datetree + language specification

[Dominik Schrempf]

Hello,

usually, my Org mode documents are in English.  However, now I need to
create an Org document in German.  I would like to use Org Capture, to
create a date tree in German (but only for this document).  Is there a
way to specify this?

Thank you,
Dominik

Re: [O] Bug: Error upon HTML export of LaTeX source code [8.3.4 (release_8.3.4-831-gbf93e1 @ /home/dominik/.emacs.d/org-mode/lisp/)]

[Dominik Schrempf]

Hello,

you are right.  I found the problem.  I had the following code in my
initialization file to treat latex beamer \frametitle commands as
sections.

(defun my-reftex-mode-hook ()
  "Tell reftex to treat \frametitle as section commands."
  (add-to-list 'reftex-section-levels
   '("frametitle" . 2))
  (reftex-reset-mode))
(add-hook 'reftex-mode-hook 'my-reftex-mode-hook)

It turned out that (reftex-reset-mode) broke org mode html export.  I
thought that this line was needed to make reftex aware of the newly
defined section labels but double checked now and it turns out that it
doesn't need the reset anyway.

Just so that you know the cause.

Thanks and best wishes,
Dominik



On Mon, May 23 2016, Nicolas Goaziou wrote:
> Hello,
>
> Dominik Schrempf <dominik.schre...@gmail.com> writes:
>
>> I try to export a fontified LaTeX source code listing with HTML export.
>> It boils down to an error that is thrown upon execution of the following
>> function during HTML export:
>>
>> (org-html-fontify-code "\\begin{tabular}{@{} l @{}}\n\\hline\nno
>> leading space\n\\hline\n\\end{tabular}\n" "latex")
>>
>> The debugging information is:
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   expand-file-name(nil)
>>   reftex-TeX-master-file()
>
> I cannot reproduce the error. 
>
> I do not use reftex. However I tried to 
>
>   (add-hook 'TeX-mode-hook #'turn-on-reftex)
>
> to no avail. This might be something in your config.
>
>
> Regards,

[O] Bug: Error upon HTML export of LaTeX source code [8.3.4 (release_8.3.4-831-gbf93e1 @ /home/dominik/.emacs.d/org-mode/lisp/)]

[Dominik Schrempf]

Hello,

I try to export a fontified LaTeX source code listing with HTML export.
It boils down to an error that is thrown upon execution of the following
function during HTML export:

(org-html-fontify-code "\\begin{tabular}{@{} l @{}}\n\\hline\nno leading 
space\n\\hline\n\\end{tabular}\n" "latex")

The debugging information is:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  reftex-TeX-master-file()
  reftex-reset-scanning-information()
  reftex-reset-mode()
  my-reftex-mode-hook()
  run-hooks(reftex-mode-hook)
  reftex-mode(t)
  turn-on-reftex()
  run-hooks(change-major-mode-after-body-hook text-mode-hook TeX-mode-hook 
LaTeX-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook text-mode-hook 
TeX-mode-hook LaTeX-mode-hook))
  TeX-run-mode-hooks(text-mode-hook TeX-mode-hook LaTeX-mode-hook)
  TeX-latex-mode()
  apply(TeX-latex-mode nil)
  latex-mode()
  org-html-fontify-code("\\begin{tabular}{@{} l @{}}\n\\hline\nno leading 
space\n\\hline\n\\end{tabular}\n" "latex")
  eval((org-html-fontify-code "\\begin{tabular}{@{} l @{}}\n\\hline\nno leading 
space\n\\hline\n\\end{tabular}\n" "latex") nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

All the best,
Dominik

Re: [O] Feature Request: Time Line in Lab Book

[Dominik Schrempf]

Hi John,

thanks for your long answer.  I could take out a lot of it.  I think I
did not describe my problem well although all of you seemed to guess it!
Just a short rephrase with vocabulary from your posts:

I want a logbook/journal where I always append text about new stuff to
the end.  Only, when I work on a task that has arisen before, I file
this text under this task.  This text should belong to the task only.
Text after the task should belong to the top level (but this is not
possible as you pointed out).

The thing is, I can't really do this with headings only, because I often
append text after a task in the same minute and it does not make sense
to create a new headline then.  I now use drawers to achieve this.  That
was not intuitive to me but it seems to work well!  I can now fold the
task-specific text under the tasks.  If I expand all text but the
drawers, I get the view that I wanted (at least within Emacs).

The setup would be perfect if I could file tasks without headlines, kind
of (is this clear?).  This may correspond to what you called "inline
tasks" (because I want my tasks to show up next to where I take my
notes).

E.g.:
--
Top level entries.  This is all very interesting (A).

** TODO A task bla bla.
   :DESCRIPTION:
   We have to do this, because...
   And then, ten days later we finished it using...
   :END:

This is the top level again and text here may be written directly after
I wrote (A) from above and filed the task.
--

Do I make myself clear now?

Thanks,
Dominik

On Thu, Mar 31 2016, John Hendy wrote:
> On Thu, Mar 31, 2016 at 3:12 AM, Dominik Schrempf
> <dominik.schre...@gmail.com> wrote:
>> Hello,
>>
>
> [snip]
>
>> A possible example:
>>
>> * February 2016
>> February 10th: Some text and stuff in February 2016.
>>
>> ** TODO A task to be done. Filed on February 10th.
>>E.g., February 24th: Some text that should belong to the task only.
>>I could not work on this task before February 18th.
>>
>> February 18th: Some more text belonging to February 2016 and not to the
>> task.
>>
>> * March 2016
>
> Like Eric, I'm a little confused of what you would want instead. The
> above is great for what currently happens, but could you do a similar
> example of what you want? You ask if this "feature" exists, but I'm
> not sure what it would be... all I can envision as a modification to
> above is:
>
> * Feb 2016
>
> Feb 10th: blah blah blah notes
>
> Feb 18th: blah blah notes
>
> ** TODO filed feb 10th, but *done* on 2/24
>
>> And so on.  Maybe this feature does already exist, but I am not aware of
>> it.  I know that especially upon export, this is hard to realize,
>> because all text always belongs to the previous headline.  But maybe it
>> is worth thinking about it because at least to me this would be highly
>> useful (e.g., having different styles in HTML export for the text under
>> the task and the text of the top level, the time line).
>
> I've wrestled with this a lot myself, at least if I put this in the
> bucket of "what's the *best* way to organize an org file." To expand
> on Nick's comments, something can only be in one hierarchy at a time,
> and everything afterward will live in that parent/child, unless you
> start a new sibling. The downside is you can't "escape" a current
> sub-heading to return to "just the parent heading" again. I've not
> quite wrestled with that, but moreso the desire to have one thing live
> in several places at the same time. I posted some structure questions
> when I migrated from TiddlyWiki in 2010; you could take a look at
> these threads if you're interested:
> - https://lists.gnu.org/archive/html/emacs-orgmode/2010-03/msg00390.html
> - http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01173.html
>
> If your example is accurate, why not make everything it's own
> headline? The notes from 2/18 wouldn't, then, "belong" to the todo
> filed on 2/10 and completed on 2/24. You'd just have:
>
> ** Feb 10
> blah blah
> ** TODO Feb 10 something
> Notes about task
> ** Feb 18
> blah blah
>
> It seems the core of your issue is not being certain on whether or not
> you want the TODO to be represented in the date tree according to
> creation or completion. That, or you don't like that you have to
> decouple the todo itself and your notes about it, which would lead to
> separate entries, one for the todo on 2/10 and one for the notes about
> what you did to complete it on 2/24. Are any of those accurate? I
> think clarification would be helpful if I've missed what you're
> wrestling with.
>
> I've taken to a pure datetree for 

Re: [O] Feature Request: Time Line in Lab Book

[Dominik Schrempf]

Hi Eric,

thanks for your answer.  I guess drawers in general are the solution to
my problems because then I can associate text to a specific headline.  I
introduced a DESCRIPTION drawer that includes the description of my
problem/task and I log the solution or outcome into the LOGBOOK drawer
when setting the state to DONE.  The drawer names are of course
arbitrary.  I also tried to use a single LOGBOOK drawer but Org mode
always adds notes at the top in the respective drawer.  I guess this is
fine in general but not expected behavior in this setting, that's why I
use two of them.

Thanks,
Dominik

On Thu, Mar 31 2016, Eric S Fraga wrote:
> Hi Dominik,
>
> it's not entirely clear what you want but I can suggest what I do.  I
> use the following capture rule to add entries to my journal (equivalent
> to your lab book):
>
> #+begin_src emacs-lisp
>   ("j" "journal" entry
>(file+datetree+prompt "~/s/notes/journal.org")
>"* %(format-time-string \"%H:%M\") %^{Entry} %^G\n%i%?")
> #+end_src 
>
> You could have two such capture rules, one for notes and one for TODO
> items.  To add notes to the TODO items, you could use the logging
> capability so that org prompts for a note every time a TODO item changes
> state.  Have a look at org-log-state-notes-into-drawer.

[O] Feature Request: Time Line in Lab Book

[Dominik Schrempf]

Hello,

I want to write a lab book with Org mode.  Thereby my workflow is as
follows: New stuff is appended to the bottom of the document (with time
stamps in chronological order).  Sometimes, especially when I discuss
something in a meeting, tasks pop up that can only be done later.  These
tasks are filed into TODO entries.  However, new stuff is being appended
to the end of the document before I can come back to getting these tasks
done.  When I work on a task, I document it below this task and do not
append it to the bottom of the document.  This new stuff should belong
to that task and not to the top level (i.e., the time line).  New stuff
belonging to the time line should belong to the top level and not to any
task above it.  I want to fold tasks together with text belonging to
them while the time line is still visible below them.  I am not sure if
I make myself clear.

A possible example:

* February 2016
February 10th: Some text and stuff in February 2016.

** TODO A task to be done. Filed on February 10th.
   E.g., February 24th: Some text that should belong to the task only.
   I could not work on this task before February 18th.
   
February 18th: Some more text belonging to February 2016 and not to the
task.

* March 2016

And so on.  Maybe this feature does already exist, but I am not aware of
it.  I know that especially upon export, this is hard to realize,
because all text always belongs to the previous headline.  But maybe it
is worth thinking about it because at least to me this would be highly
useful (e.g., having different styles in HTML export for the text under
the task and the text of the top level, the time line).

Thanks and best wishes,
Dominik

[O] Bug: Invalid search bound (wrong side of point) upon latex code execution [8.3.4 (release_8.3.4-607-gaa7815 @ /home/dominik/.emacs.d/org-mode/lisp/)]

[Dominik Schrempf]

Hello,

if I try to execute the following latex code block after a list item and
followed by two blank lines I get an error.  If I remove one blank line
the code executes fine.

--
- Very convenient for typesetting the integral variable =dx=:
  #+BEGIN_SRC latex :exports code :results html
\newcommand{\ud}{\,\mathrm{d}}
  #+END_SRC


--

The error message is:
Debugger entered--Lisp error: (error "Invalid search bound (wrong side of 
point)")
  re-search-forward("^[ 
]*#\\+RESULTS\\(?:\\[\\(?:\"<([0-9]{4}-[0-9]{2}-[0-9]{2}
 ?[^.\n>]*?)>\"\\)?\\([[:alnum:]]+\\)\\]\\)?:[  ]*$" 387 t)
  
byte-code("\212\214~\210\306!\211.\307>\203Z.\310\311\310\312\"\".\310\313\"b\210\314\nw\210\315\316`\nW\205T.\317
 
.\306!\320=\205S.\310\321\"\322\230\205S.\f\204D.`\202S.`\310\313\"b\210\323\324x\210`|\210`)\"\210)\202\335.

\325>\203\330.\310\326\"\211.\205l.\327.!\211.%\206v.\310\313\"b\210.%\203\222.\330.&!\203\212.\331.&\"\210\315\316`\"\210\202\324.
\204\324.m\204\324.\332 .'\212\310\333.'\"b\210\334 
).(.)\335P.*\336.+\337.*.(\336#,\203\324.\340 
\210\330.&!\203\317.\331\324.&\"\210\315\316`\"\210*\202\335.\315\316\324\"\210+\f\205.
\212\310\313\"d^b\210\314\324x\210\324y\210n\204\374.\341c\210\202.
m\204

.\310\342\"\343U\203.
\344c\210\202.
\324y\210\331\310\326\".&\"\210`)\207" 
[context val limit result insert name org-element-type (inline-babel-call 
inline-src-block) org-element-property :contents-end :parent :end " \n" 
throw :found org-element-context macro :key "results" " " nil (babel-call 
src-block) :name org-babel-find-named-result org-babel--clear-results-maybe 
org-babel--insert-results-keyword org-element-at-point :post-affiliated 
line-end-position "$" t re-search-forward beginning-of-line "\n\n" :post-blank 
0 "\n" named-results hash next end org-babel-result-regexp empty-result-re 
case-fold-search] 7)
  org-babel-where-is-src-block-result(nil ("latex" 
"\\newcommand{\\ud}{\\,\\mathrm{d}}" ((:comments . "") (:shebang . "") (:cache 
. "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "code") 
(:results . "html replace") (:hlines . "no") (:session . "none")) "" nil 388))
  org-babel-remove-result(("latex" "\\newcommand{\\ud}{\\,\\mathrm{d}}" 
((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . 
"no") (:tangle . "no") (:exports . "code") (:results . "html replace") (:hlines 
. "no") (:session . "none")) "" nil 388))
  #[nil "\302=\203 .\303 \207\304  !\207" [type info inline 
org-babel-remove-inline-result org-babel-remove-result] 2]()
  org-babel-exp-do-export(("latex" "\\newcommand{\\ud}{\\,\\mathrm{d}}" 
((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . 
"no") (:tangle . "no") (:exports . "code") (:results . "html replace") (:hlines 
. "no") (:session . "none")) "" nil 388) block nil)
  org-babel-exp-src-block(("latex" ":exports" "code" ":results" "html"))
  org-babel-exp-process-buffer(#<2>>)
  org-export-execute-babel-code()
  org-export-as(html nil nil nil (:output-file "./programming.html"))
  org-export-to-file(html "./programming.html" nil nil nil nil nil)
  org-html-export-to-html(nil nil nil nil)
  org-export-dispatch(nil)
  call-interactively(org-export-dispatch nil nil)
  command-execute(org-export-dispatch)

Emacs  : GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-10 on foutrelis
Package: Org-mode version 8.3.4 (release_8.3.4-607-gaa7815 @ 
/home/dominik/.emacs.d/org-mode/lisp/)

Thanks,
Dominik

Re: [O] Bug: LaTeX in HTML export [8.3.2 (release_8.3.2-380-g64aee4 @ /home/dominik/.emacs.d/org-mode/lisp/)]

[Dominik Schrempf]

Hi Rasmus,

thanks for your answer.  I asked the people from MathJax and the problem
is HTML related. 

[O] Bug: LaTeX in HTML export [8.3.2 (release_8.3.2-380-g64aee4 @ /home/dominik/.emacs.d/org-mode/lisp/)]

[Dominik Schrempf]

Hello,

I am trying to export a LaTeX code block into HTML and have a problem
when using lower (<) signs (maybe it also happens with greater signs but
I did not check that).

E.g., the following Org code leads to an error when viewing the HTML
file because the '<' sign is interpreted in a wrong way (I don't know
how but it seems to be interpreted as part of a tag) and MathJax does
not succeed then.

Org code:
#+BEGIN_SRC latex :results html
  \begin{equation}
\text{if } 0