Re: Translation of the Org mode manual (was: Translation of manuals (was: SES manual French translation))

[Jean-Christophe Helary]

Ihor,

Thank you for chiming in.

> On Jan 4, 2024, at 20:34, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary 
> writes:
>> I’m not sure this is the place to discuss translation theory...
> 
> Let me steer this discussion to non-texi manuals - Org mode manual.

Sure.

> We also had a few requests about translations, although Org mode needs
> are more general compared to a very focused task of translating texi
> manuals:
> 
> 1. Org mode manual itself, just like the other Emacs manuals may need to
>   be translated. However, Org mode manual source is written in Org mode
>   format, not texi. It is just transformed to texi as one of the export
>   options.

That’s correct and that texi file seems to choke po4a, which is the 
reason my script removes it and uses the .org original instead.

I use the txt filter in po4a to convert it to po:

https://git.sr.ht/~brandelune/emacs_documentation_repository/tree/main/item/emacs_docs2po.sh#L71

The result is here:

https://git.sr.ht/~brandelune/emacs_documentation_repository/tree/main/item/doc/misc/org.org.fr.po

And looks like this:

---
#. type: Plain text
#: /Users/suzume/Documents/Repositories/Projet OmegaT de Documentation Emacs -
#: Sources/doc/misc/org.org:24
msgid ""
"Org Mode is an authoring tool and a TODO lists manager for GNU Emacs.  It "
"relies on a lightweight plain-text markup language used in files with the "
"=.org= extension."
msgstr ""

#. type: Plain text
#: /Users/suzume/Documents/Repositories/Projet OmegaT de Documentation Emacs -
#: Sources/doc/misc/org.org:31
msgid ""
"As an authoring tool, Org helps you write structured documents and provides "
"exporting facilities. Org files can also be used for literate programming "
"and reproducible research.  As a TODO lists manager, Org helps you organize "
"your tasks in a flexible way, from daily needs to detailed project-planning, "
"allowing logging, multiple views on your tasks, exporting your agendas, etc."
msgstr ""

#. type: Plain text
#: /Users/suzume/Documents/Repositories/Projet OmegaT de Documentation Emacs -
#: Sources/doc/misc/org.org:38
msgid ""
"Org mode is implemented on top of Outline mode, which makes it possible to "
"keep the content of large files well structured.  Visibility cycling and "
"structure editing help to work with the tree.  Tables are easily created "
"with a built-in table editor.  Plain text URL-like links connect to "
"websites, emails, Usenet messages, BBDB entries, and any files related to "
"the projects."
msgstr ""
---

In OmegaT it looks like this (all the po decorations are hidden - 
protected - in the editor, only the translatable parts are displayed):

---
¶

Org Mode is an authoring tool and a TODO lists manager for GNU Emacs.

It relies on a lightweight plain-text markup language used in files 
with the =.org= extension.

¶

As an authoring tool, Org helps you write structured documents and 
provides exporting facilities.

Org files can also be used for literate programming and reproducible 
research.

As a TODO lists manager, Org helps you organize your tasks in a 
flexible way, from daily needs to detailed project-planning, allowing 
logging, multiple views on your tasks, exporting your agendas, etc.

¶

Org mode is implemented on top of Outline mode, which makes it possible 
to keep the content of large files well structured.

Le cycle de visualisation et la modification de la structure aident à 
travailler avec l'arborescence.

Les tableaux sont facilement créés avec un éditeur de tableau intégré.

Les liens de type URL en texte brut se connectent aux sites Web, aux 
e-mails, aux messages Usenet, aux entrées BBDB et à tous les fichiers liés 
aux projets.

¶
---

You’ll notice that a few sentences have been translated in the last 
paragraph.

In other tools that support the PO format, similarly the PO decorations 
would be hidden from view.

> 2. Org mode website has several translations (French, Japanese, and
>   Mandarin). The website sources are written in Org mode, but the work
>   of translation was done be enthusiasts, and we have no good system to
>   maintain the main English version of the website in sync with the
>   translations.

I think you should take a look at how Debian does that, even if their 
site sources are not in org. The process is the same. Debian has a huge 
amount of experience in documentation/web localization.

> 3. A number of Org mode users are using Org sources to publish
>   multi-lingual books. Such publishing is a bit more challenging
>   compared to translation as it requires special book layout.

Indeed.

> Therefore, there is a demand to have a toolset for translating Org mode
> documents.
> 
> So far, I have been thinking about

Re: "Orgdown", the new name for the syntax of Org-mode

[Jean-Christophe Helary]

> On Nov 29, 2021, at 8:24, Jean-Christophe Helary  
> wrote:
> 
> 
> 
>> On Nov 29, 2021, at 7:57, Tom Gillespie  wrote:
>> 
>> PS Another brainstormed name: Orgsyn?
> 
> Org Agnostic Syntax Modules → OrgASM

I understand that the issue is quite moot now (and I'm sorry for my silly 
proposal), but I just found out about "CommonMark" and I thought that if org 
syntax *had* to borrow from a markdown-esque name, then CommonOrg would 
perfectly fit the endeavor.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: "Orgdown", the new name for the syntax of Org-mode

[Jean-Christophe Helary]

> On Nov 29, 2021, at 7:57, Tom Gillespie  wrote:
> 
> PS Another brainstormed name: Orgsyn?

Org Agnostic Syntax Modules → OrgASM

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: "Orgdown", the new name for the syntax of Org-mode

[Jean-Christophe Helary]

Considering the total incompatibility between markdown and org-mode it does not 
seem to me that ’orgdown’ is a useful name. It will only confuse people and 
generate useless comments and counter-comments wherever org-mode syntax is 
mentioned.

Org-mode and its syntax bring users functions that are vastly superior to 
whatever markdown does, and we should not forget that markdown’s originator (at 
least the one who is still alive today) pretty much systematically despises 
free software and the free software movement on his blog…

Jean-Christophe Helary

> On Nov 29, 2021, at 4:46, Karl Voit  wrote:
> 
> Hi Org-mode community,
> 
> At this year's EmascsConf, I had a 12 minute video where I explain why
> we do need a different name for the syntax of Org-mode in contrast to
> the Elisp implementation of GNU/Emacs Org-mode.
> 
> I would like you to read my rationale and motivate you to use the term
> "Orgdown" for the syntax and "Orgdown1" for the first (very basic)
> level of Orgdown syntax elements.
> 
> - The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside
> - Orgdown site: https://gitlab.com/publicvoit/orgdown (please contribute!)
> - My motivation article: https://karl-voit.at/2021/11/27/orgdown/
>  - This is the longer version of my 12 minute EmacsConf21 video.
> - My personal copy of the video: 
> https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu
> 
> 
> Just as a sneak preview (not as a replacement for my motivation article):
> 
> Orgdown is and will be defined in a set of levels, starting with very
> basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness
> factor of choice :-) )
> 
> - OD1 → 
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
> - OD2 → will be defined in future
> - OD3 → will be defined in future
> - ...
> - OD∞ = Org-mode (by definition)
> 
> Any OD-level needs to be compatible with Org-mode as implemented in
> Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx
> is a sub-set of the syntax elements of ODy (with y>x).
> 
> With introducing a new term specific for the syntax, we do get the
> benefit of getting a better way to handle Org-mode support in
> 3rd-party tools such as listed on
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org
> (please extend!).
> 
> Having a well-defined sub-set of Org-mode, I also do think that formal
> definitions of the Org-mode syntax will be easier to develop, starting
> with the very simple OD1 level.
> 
> It would be awesome if we start referring to syntax support in
> 3rd-party tools with the corresponding OD levels.
> 
> I want to emphasize that the goal of Orgdown is NOT and will never be
> something that is an alternative to our golden standard Org-mode. We
> will try hard not to get into the Markdown situation where you need to
> know the exact flavor of the markup in order to produce text.
> 
> So far, the response was great at the conference and I do hope that
> this idea will get a life of its own, developing the standard further,
> bringing this magnificent lightweight markup to the digital world.
> This also eases some pain for users of GNU/Emacs when it comes to
> exchanging text-based data.
> 
> Thanks for your support here!
> 
> 
> -- 
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: epresent font increase ?

[Jean-Christophe Helary]

> On Nov 9, 2021, at 21:11, Marco Wahl  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I'm trying to increase the overall font for an epresent slide show
>> that I'm presenting in 37 minutes and I keep getting this
>> "face-attribute: Invalid face: epresent-content-face" message...
>> 
>> My screen is a 15" and running that full screen makes the contents difficult 
>> to read.
>> 
>> Any solution ?
> 
> Switch to the newer epresent at https://github.com/eschulte/epresent.

Maybe there was an issue between me and the keyboard because it works now.


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: epresent font increase ?

[Jean-Christophe Helary]

> On Nov 9, 2021, at 21:10, Eric S Fraga  wrote:
> 
> No idea but you could always just create the face yourself and see what
> happens?  This is *emacs* after all...

Indeed :-)

> -- 
> : Eric S Fraga via Emacs 28.0.60, Org release_9.5-192-gd4e192
> : Latest paper written in org: https://arxiv.org/abs/2106.05096

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: epresent font increase ?

[Jean-Christophe Helary]

> On Nov 9, 2021, at 21:16, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I'm trying to increase the overall font for an epresent slide show that I'm 
>> presenting in 37 minutes and I keep getting this "face-attribute: Invalid 
>> face: epresent-content-face" message...
>> 
>> My screen is a 15" and running that full screen makes the contents difficult 
>> to read.
>> 
>> Any solution ?
> 
> Your problem is related to third-party package (epresent). You may
> better ask the package author.

You're right.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

epresent font increase ?

[Jean-Christophe Helary]

I'm trying to increase the overall font for an epresent slide show that I'm 
presenting in 37 minutes and I keep getting this "face-attribute: Invalid face: 
epresent-content-face" message...

My screen is a 15" and running that full screen makes the contents difficult to 
read.

Any solution ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Regular expressions that describe most (?) org syntax ?

[Jean-Christophe Helary]

> On Oct 30, 2021, at 14:18, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I am looking for a set of regular expressions that roughly describe most of 
>> the important org syntax.
> 
> You need to study org-element.el starting from
> `org-element--current-element'.

Thank you Ihor !

Jean-Christophe 

Regular expressions that describe most (?) org syntax ?

[Jean-Christophe Helary]

I am looking for a set of regular expressions that roughly describe most of the 
important org syntax.

A bit like

@code\{[^\}]*\}|@command\{[^\}]*\} ...

describes part of the texi code found in the Emacs manuals.

I could figure something out, but I thought maybe there is already something 
around…


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Problems generating the org-mode documentation

[Jean-Christophe Helary]

> On Oct 22, 2021, at 15:34, Pedro Andres Aranda Gutierrez  
> wrote:
> 
> I have checked on a MacBook Pro with 16G running non-virtualised 

Same here. It is not a resource problem.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: A quick LaTeX reference guide in Org

[Jean-Christophe Helary]

> On Oct 25, 2021, at 0:37, Emmanuel Charpentier  
> wrote:
> 
> "A quick LaTeX reference guide"...
> 
> Nice oxymoron !

But it looks good in org-mode :-)
Thank you Juan !


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Problems generating the org-mode documentation

[Jean-Christophe Helary]

> On Oct 18, 2021, at 20:51, Pedro Andres Aranda Gutierrez  
> wrote:
> 
> Hi,
> 
> I'm trying to generate the documentation on a freshly pulled emacs-28 branch 
> with
> 
> make doc
> 
> and get the following error when creating  the org-mode documentation:
> 
> [195] [196] Chapter 14 [197] [198] [199] [200] [201] [202] [203] [204] [205]
> [206] [207] Chapter 15 [208]
> ./org.texi:17579: TeX capacity exceeded, sorry [input stack size=5000].

Takesi Ayanokoji found that there was an extra line break that broke the 
conversion. Maybe there is an easy fix, but I have not tested that yet.

> org.orgについてですが、これはもしかしてEmacsのバージョン28からでしょうか(masterブランチでは見つかりましたが、emacs-27ブランチには存在しないみたいです)。
> 
> http://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/org.texi?h=emacs-27.2#n7375
> 
> ↑emacs-27の問題箇所を見直してみると@itemの中の@footnoteの中の改行を処理できてないようです。
> 
> 一方、masterのorg.orgでは@itemが
> 
> http://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/org.org#n6650
> 
> ここで参照されている[fn:78]の同じ箇所に改行があるので、この改行を削除すればpo4aで処理できる形式になるかもしれません。
> 
> http://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/org.org#n21590



-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

face for org-capture template

[Jean-Christophe Helary]

I just found how to change the face based on the major mode thanks to 
buffer-face-mode and I'd like to know if there is a similar mechanism to apply 
a given face to the template buffer.

What I have is:

;; polices fixes pour modes
;; https://www.emacswiki.org/emacs/FacesPerBuffer#toc3
(defun my-buffer-face-mode-fixed ()
  "Sets a fixed width (monospace) font in current buffer"
  (interactive)
  (setq buffer-face-mode-face '(:family "PT Mono" :height 115))
  (buffer-face-mode))

(add-hook 'org-capture-mode-hook ’my-buffer-face-mode-fixed)

But that applies the fixed font to the capture target and not to the template 
buffer...

I'm sure the answer is somewhere right under my nose...

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: [emacs-humanities] Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

Better solution found: quit sr.ht and move to a gitea implementation.

No hassle, org files are fully recognized.

Jean-Christophe 

> On Oct 2, 2021, at 14:20, Jean-Christophe Helary  
> wrote:
> 
> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
> Markdown syntax for their readme/wiki files.
> 
> Since I work in Emacs/org-mode to write my documents (and try to stick to 
> that), I'd like to know if there is an elegant way to export org syntax to 
> MarkDown.
> 
> I was thinking that the export-dispatch had an option for Plain Text / 
> Markdown, but that doesn't seem to be the case.
> 
> As a workaround, I thought I'd work on a README.org file that I export to 
> HTML, change the name to .md and edit the contents to reduce the markup to 
> the strict minimum... But when I saw the contents of the HTML, I thought that 
> would be way too much work.
> 
> *BUT* MarkDown bien basically HTML *without* the head/body tags, it seems to 
> me that the HTML export-dispatch thing could have a "super simplified MD 
> compatible" HTML option...
> 
> Either way, I need a method to export to something that sr.ht will recognize 
> and process as MD so:
> 
> 1) is there an external "approved" process to convert org-mode syntaxt to an 
> MD-compatible format ?
> 2) if no, what is the not too hard way to hack the HTML output to produce 
> what I need with export-dispatch ?
> 
> ---side note--
> And, Hello to Emacs-Humanities! I was away from the emacs-lists for a year 
> and when I came back I found that this amazing list was born. Last year I 
> started a "go-back-to-school" process that will eventually conclude with me 
> finishing an MA in Japanese studies, and I wrote my first 57 pages research 
> report last year with org-mode/Zotero/NeoOffice (a macOS only LibreOffice), 
> and that was fun. This year I work remotely as a part-time lecturer in 
> translation studies where I'll teach how to use free software in translation 
> (OmegaT/Opaki Framework/Maxprograms) and I wanted to write my teaching 
> material in org on sr.ht, but...
> 
> -- 
> Jean-Christophe Helary @brandelune
> https://mac4translators.blogspot.com
> https://sr.ht/~brandelune/omegat-as-a-book/
> 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 21:18, Morgan Willcock  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
>> Markdown syntax for their readme/wiki files.
> 
> Hi Jean-Christophe,
> 
> If this is just for SourceHut you can use an HTML export and upload it
> via the API instead of committing a Markdown based file.
> 
> https://man.sr.ht/git.sr.ht/#setting-a-custom-readme

Morgan,

Thank you for the pointer.

Actually, Noah and Drew suggested that on sr.ht, but I really have *no* idea 
what an API is, how I work with it, what is the graphql thing and all.

It looks like a super-powerful thing that smart people use, but it will 
probably take me quite some time before I can actually know where to start with 
all that info (I did check graphql tutorials but I was like: "ok, and where do 
I type all that?")...

Besides, org's md export works like a charm.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 16:44, Tim Cross  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> I'm trying to work with SourceHut (sr.ht) and right now they only accept 
>> Markdown syntax for their readme/wiki files.
>> 
>> Since I work in Emacs/org-mode to write my documents (and try to stick to 
>> that),
>> I'd like to know if there is an elegant way to export org syntax to MarkDown.

> Org does have an exporter for markdown. You need to enable it (see the
> manual).

That's what I had missed. Thank you.

> Note that 'markdown' is a somewhat generic term - there is no 'standard'
> for markdown.

Well, there is John Gruber's original definition.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 16:00, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> Next (related) question:
>> 
>> Why that ugly number in front of headers defined with  in HTML ?
> 
> I have little knowledge about HTML export... I blind guess is that you
> may disable org-export-with-section-numbers
> (see "14.1.5 Options for the exporters" section of the manual)

Thank you for the pointer.

> As for "ugly", it is probably subjective.

HTML does not require the addition of a number to indicate the heading level. 
The exported number is very much unexpected. Numbers (or ordering indicators) 
are expected in an  context, but nowhere else.

> Can you share a screenshot and
> suggest a concrete improvement?

Disable that by default.

> Also, are you on Org 9.5?

I'm on the latest update in a locally recently built emacs/master.

> I have seen some patches in that area lately.

Thank you for the information.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 15:24, Ihor Radchenko  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> My follow-up question is, most of the ox-stuff seem to be installed by 
>> default, as far as I can tell. Why is ox-md not ?
> 
> Not most. The default export backends are:
> 
>> org-export-backends is a variable defined in org.el.
>> 
>> Value
>> (ascii html icalendar latex odt)
> 
> You can also customise this variable instead of direct (require 'ox-md)
> 
> Why not all backends are loaded? Mostly to reduce Org loading speed that
> some people complain about.

Also, I could have checked the manual... It was all there... Apologies for the 
noise.

Next (related) question:

Why that ugly number in front of headers defined with  in HTML ?


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

> On Oct 2, 2021, at 14:57, Protesilaos Stavrou  wrote:
> 
> On 2021-10-02, 14:20 +0900, Jean-Christophe Helary 
>  wrote:
> 
>> I'm trying to work with SourceHut (sr.ht) and right now they only
>> accept Markdown syntax for their readme/wiki files.
>> 
>> Since I work in Emacs/org-mode to write my documents (and try to stick
>> to that), I'd like to know if there is an elegant way to export org
>> syntax to MarkDown.
>> 
>> I was thinking that the export-dispatch had an option for Plain Text /
>> Markdown, but that doesn't seem to be the case.
> 
> Hello Jean-Christophe,
> 
> Have you tried the 'ox-md' which is part of Org?  Like this:
> 
>(require 'ox-md)
>(add-to-list 'org-export-backends 'md)
> 
> The export dispatched should then have an "Export to Markdown" option
> bound to 'm'.
> 
> There are more export backends as well.  If you do M-x find-library and
> search for "ox-" you will find more options.
> 
> All the best,
> Protesilaos (or simply "Prot")

Prot, Ihor,

Thank you *very much* for the pointers.

My follow-up question is, most of the ox-stuff seem to be installed by default, 
as far as I can tell. Why is ox-md not ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Elegant way to export org to Markdown ?

[Jean-Christophe Helary]

I'm trying to work with SourceHut (sr.ht) and right now they only accept 
Markdown syntax for their readme/wiki files.

Since I work in Emacs/org-mode to write my documents (and try to stick to 
that), I'd like to know if there is an elegant way to export org syntax to 
MarkDown.

I was thinking that the export-dispatch had an option for Plain Text / 
Markdown, but that doesn't seem to be the case.

As a workaround, I thought I'd work on a README.org file that I export to HTML, 
change the name to .md and edit the contents to reduce the markup to the strict 
minimum... But when I saw the contents of the HTML, I thought that would be way 
too much work.

*BUT* MarkDown bien basically HTML *without* the head/body tags, it seems to me 
that the HTML export-dispatch thing could have a "super simplified MD 
compatible" HTML option...

Either way, I need a method to export to something that sr.ht will recognize 
and process as MD so:

1) is there an external "approved" process to convert org-mode syntaxt to an 
MD-compatible format ?
2) if no, what is the not too hard way to hack the HTML output to produce what 
I need with export-dispatch ?

---side note--
And, Hello to Emacs-Humanities! I was away from the emacs-lists for a year and 
when I came back I found that this amazing list was born. Last year I started a 
"go-back-to-school" process that will eventually conclude with me finishing an 
MA in Japanese studies, and I wrote my first 57 pages research report last year 
with org-mode/Zotero/NeoOffice (a macOS only LibreOffice), and that was fun. 
This year I work remotely as a part-time lecturer in translation studies where 
I'll teach how to use free software in translation (OmegaT/Opaki 
Framework/Maxprograms) and I wanted to write my teaching material in org on 
sr.ht, but...

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: export dispatch → change the default "Contents" string

[Jean-Christophe Helary]

Thank you Juan.

It does not seem to work as I expected, but that's OK, I just removed the ToC.

Jean-Christophe 

> On Oct 2, 2021, at 1:35, Juan Manuel Macías  wrote:
> 
> Hi, jean-Christophe,
> 
> Jean-Christophe Helary writes:
> 
>> What is the parameter to change the default "Contents" ToC string when 
>> exporting to PDF ?
> 
> If I'm not wrong, I think there is no native Org way to change the
> default string for LaTeX literals. But if you use babel (the LaTeX
> package), you can add this command:
> 
> #+LaTeX_Header: \addto{\captionsenglish}{\renewcommand\contentsname{foo}}
> 
> That's the old way of doing it, and it still works. The latest Babel
> versions also incorporate this other variant:
> 
> \setlocalecaption{language-name}{caption-name}{string}
> 
> for example:
> 
> \setlocalecaption{english}{contents}{Table of Contents}
> 
> NB: I strongly recommend using babel always for LaTeX, in any of its
> flavors (pdfLaTeX, XeLaTeX, LuaLaTeX), instead of polyglossia, which is
> a very buggy package. This package came up when babel didn't support
> XeTeX and LuaTeX, years ago, but now it doesn't sense to use it.
> 
> Best regards,
> 
> Juan Manuel 
> 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

export dispatch → change the default "Contents" string

[Jean-Christophe Helary]

What is the parameter to change the default "Contents" ToC string when 
exporting to PDF ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

org.texi and po4a

[Jean-Christophe Helary]

It looks like po4a can't convert org.texi to the PO format.

$ po4a-gettextize -f texinfo -M utf8 -m org.texi -p org.texi.fr.po

→ Complex regular subexpression recursion limit (32766) exceeded at 
/opt/local/lib/perl5/5.26/Locale/Po4a/TeX.pm line 697.

I don't suppose that there are issues with the texi itself, it looks like the 
texi conversion in po4a is a bit weak, but it would be awesome if somebody 
could check if there is something that could be simplified (org.texi is the 
*only* manual in the whole emacs distribution that faults at the conversion).

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: org-mode export to (latex) PDF

[Jean-Christophe Helary]

> On Jul 16, 2021, at 18:20, Stefan Nobis  wrote:
> 
> The last glyph ("TELEPHONE RECEIVER") is not visible for me. Remember,
> that Unicode gets expanded quite often and it is not easy for font
> developers to keep up. I still think that the expectation, that Org
> and/or LaTeX will support the whole Unicode range out of the box is a
> little bit too far fetched.

If I may insist, my original question was about a "good enough" *or* easily 
understandable setting for org export to PDF.

I *never* suggested that I, or someone, expected org to support the *whole 
Unicode range* at any moment.

Since org uses Latex to achieve export to PDF, which is quite a common demand 
nowadays, something that normal org users can understand should be posted 
somewhere (*should*, with the meaning that I'd love to do that if I understood 
even half the discussion here, but it is sadly not the case.)

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: org-mode export to (latex) PDF

[Jean-Christophe Helary]

> On Jul 15, 2021, at 4:05, Stefan Nobis  wrote:
> 
>> Is it possible to provide reasonable defaults for fonts?
> 
> I do not think so. You want Cyrillic. But what about Japanese,
> Chinese, Devanagari, Tamil, Arabic etc? I doubt that there exists a
> single font that supports all these scripts satisfactorily.

The issue I'm pointing at is that we don't need "satisfactorily", we need "good 
enough".

There are a number of fonts that have 30k+ glyphs. That's good enough for a lot 
of org-mode users.

https://en.wikipedia.org/wiki/Unicode_font

What we need is 1 or 2 well-documented settings where we specify:

1) the back end
2) the font

It can be org proprieties, or extra elisp code, it doesn't matter. But we need 
to have good enough PDF export out of the box. We're in the 21st century. 
People expect (I know, free software, etc. but I'm not talking about that) 
proper font support for PDF, and well-documented workaround solutions.

I don't mind going through the org→ODF→PDF route, but it's a waste of time. 
Still, it works *well enough* so it's actually the only viable option.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: help with a regexp

[Jean-Christophe Helary]

> On Jul 15, 2021, at 13:41, Timothy  wrote:
> 
> 
> Hi John,
> 
> John Kitchin  writes:
> 
>> Hi all, I could use a bit of help with a regexp. I am trying to fine tune
>> the org-ref citation regexp to make it orthogonal to org-cite.
>> 
>> I want to recognize these as org-ref links
>> 
>> [[cite:schuett-2018-schnet]]
>>   cite:schuett-2018-schnet
>> 
>> but not
>> 
>> [cite:@schuett-2018-schnet]
>> 
>> so either 0 or 2 [[ can prefix it to be a cite link in org-ref, but not 1 [.
>> 
>> right now the cite: in the org-cite syntax is getting flagged as bad cite
>> link which I want to avoid.
>> 
>> is this doable?
> 
> I'd think so. Let me know if https://regex101.com/r/Ud6HVY/1 helps :)

cite:[^@][A-Za-z0-9_-]+|\[\[cite:[^@][A-Za-z0-9_-]+\]\]

There are no reasons to limit the string after : to ascii.

in isearch I tried:

\[\{2\}cite.*\]\{2\}\|[^\[]cite:[^ \
]*

And it seems to do the job.



-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: org-mode export to (latex) PDF

[Jean-Christophe Helary]

> On Jul 10, 2021, at 23:38, Juan Manuel Macías  wrote:
> 
> Hi Jean-Christophe,
> 
> Jean-Christophe Helary writes:
> 
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
> 
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf

Thank you very much Juan.

I understand that Latex has excellent support for multilingual files. I use it 
sometimes for very complex multilingual texts (ancient Japanese and French for 
ex).

But with UTF-8 being ubiquitous on computers nowadays, I really can't be 
bothered to have to type all those sequences to have org-mode properly export 
to PDF something that it exports perfectly well to ODT without requiring 
anything extra.

Which is the reason why I was wondering about a "generic" default setting where 
the conversion engine behind org could just use a default multilingual package 
and a default "wide enough" generic font. I really mean a "good enough" export 
where all the characters are visible, nothing fancy.

Jean-Christophe 

> 
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
> 
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
> 
> #+LaTeX_Header: \usepackage[several langs]{babel}
> 
> @@latex:\begin{otherlanguage*}{german}@@
> 
> ... some text in german ...
> 
> @@latex:\end{otherlanguage*}@@
> 
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
> 
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}
> 
> #+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
> #+begin_quote
> Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
> Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
> sich in ihr vorgesetzt, sowie über die Veranlassungen und das
> Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
> Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
> einer philosophischen Schrift nicht nur überflüssig, sondern um der
> Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
> #+end_quote
> 
> Best regards,
> 
> Juan Manuel 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: org-mode export to (latex) PDF

[Jean-Christophe Helary]

> On Jul 10, 2021, at 22:52, Juan Manuel Macías  wrote:
> 
> Hi Jean-Christophe,
> 
> Jean-Christophe Helary writes:
> 
>> I guess it is an issue with the Latex backend and could have been solved 
>> with the proper Latex settings, but it seems weird that the default settings 
>> do not allow for out-of-the-box multilingual support.
> 
> I agree with you that Org should have multilingual support. A few months
> ago I started this thread here, with some proposals:
> https://orgmode.org/list/87o8d95pvo@posteo.net/

Juan,

That's a very interesting proposal. Thank you for the reference.

I had given up on Latex because mixing languages sounded like a huge pain in 
the butt but I see that without some org-level infrastructure it is not 
possible to achieve much when exporting to Latex/PDF (unless I missed 
something).

So I guess I'll just keep my current workflow for now, with ODT as my "pivot" 
format.

Thank you again, Juan.


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

org-mode export to (latex) PDF

[Jean-Christophe Helary]

I was busy last year going back to school and I wrote a research paper for my 
first year of master almost entirely in org-mode.

My workflow was trivial:

- write in org-mode
- enter the bibliography with Zotero
- export to ODT and open in NeoOffice
- modify in NeoOffice
- deliver

At first, I tried to export the document to PDF but all the Japanese quotes I 
had were removed from the document, which led me to prefer ODT export because 
it handled them properly.

I guess it is an issue with the Latex backend and could have been solved with 
the proper Latex settings, but it seems weird that the default settings do not 
allow for out-of-the-box multilingual support.

Is there an easy way to have that as the default behavior?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Step by step tutorial on Worg on how to create a new export backend

[Jean-Christophe Helary]

> On Feb 16, 2020, at 17:05, Marcin Borkowski  wrote:
> 
> 
> On 2020-02-16, at 01:46, Jean-Christophe Helary 
>  wrote:
> 
>>> On Feb 16, 2020, at 2:55, Marcin Borkowski  wrote:
>>> 
>>> 
>>> On 2020-02-14, at 21:48, Bastien  wrote:
>>> 
>>>> We have a good reference documentation for creating export backends:
>>>> https://orgmode.org/worg/dev/org-export-reference.html
>>>> 
>>>> But we *badly* need a step by step tutorial on Worg.
>>>> 
>>>> Anyone would like to volunteer for writing such a tutorial?
>>> 
>>> I might try to at least start it, though I'll need some time.  When is
>>> that needed?  (I assume that the sooner, the better, so if there is
>>> anyone who would beat me to it, go on.  I might do some proofreading
>>> then.)
>> 
>> Marcin,
>> 
>> Aren't you supposed to write a book about Emacs already ? ;)
> 
> Yep, point taken.

I'm really not picking on you or anything :) I just realized that I would have 
written *exactly* the same thing in other contexts knowing that my plate is 
already over-full.

> But the tutorial is a much smaller thing, and
> I already did a similar thing (the Emacs Conf 2015 talk on creating
> derived exporters), so much of the work is already done.

And I'd love to read that.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: Step by step tutorial on Worg on how to create a new export backend

[Jean-Christophe Helary]

> On Feb 16, 2020, at 2:55, Marcin Borkowski  wrote:
> 
> 
> On 2020-02-14, at 21:48, Bastien  wrote:
> 
>> We have a good reference documentation for creating export backends:
>> https://orgmode.org/worg/dev/org-export-reference.html
>> 
>> But we *badly* need a step by step tutorial on Worg.
>> 
>> Anyone would like to volunteer for writing such a tutorial?
> 
> I might try to at least start it, though I'll need some time.  When is
> that needed?  (I assume that the sooner, the better, so if there is
> anyone who would beat me to it, go on.  I might do some proofreading
> then.)

Marcin,

Aren't you supposed to write a book about Emacs already ? ;)


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: Format of Effort estimates should be mentioned in its Info node

[Jean-Christophe Helary]

> On Jan 4, 2020, at 14:20, Kisaragi Hiu  wrote:
> 
> It didn't work for me because I gave it "10m" which actually means 10 months, 
> I've realized.
> 
> Still, Durations as defined by org-duration.el should be described in the 
> manual like how Timestamps are.

This does look like a potential contribution to the package.

Jean-Christophe Helary

> 
> 2020年1月4日 11:55 差出し人： k...@kyleam.com:
> 
>> Kisaragi Hiu  writes:
>> 
>>> Currently, the Info node about effort estimates does not mention what
>>> format should it be written in. This causes confusion, as a user might
>>> assume that it's the same format as schedulers (10m, 6h, etc.) like I
>>> did.
>>> 
>>> Simply mentioning "Effort estimates need to have the format H:MM"
>>> 
>> 
>> I don't personally use effort estimates, but quickly poking around I see
>> some indication that estimates should work fine with things like 10min
>> rather than 0:10.  In particular org-set-effort has a bit that looks
>> like this:
>> 
>> (org-refresh-property '((effort . identity)
>> (effort-minutes . org-duration-to-minutes))
>> value)
>> 
>> The presence of org-duration-to-minutes hints to some sort of
>> normalization:
>> 
>> (org-duration-to-minutes "10min") ; => 10.0
>> (org-duration-to-minutes "0:10")  ; => 10.0
>> 
>> And it looks like org-agenda-compare-effort uses the effort-minutes text
>> property.  That's presumably why, when I view the entries below in the
>> agenda, org-agenda-filter-by-effort (bound to "_") treats them the same:
>> 
>> * TODO a
>> :PROPERTIES:
>> :Effort:  10min
>> :END:
>> 
>> * TODO b
>> :PROPERTIES:
>> :Effort:   0:10
>> :END:
>> 
>> But that's just one use of effort values, and it sounds like you've hit
>> into cases where the 10min form didn't work as expected.  Could you
>> provide more details?
>> 
>>> (copied from the docstring or org-effort-property, the only*
>>> description of the format I could find) in the Info node would be
>>> enough.
>>> 
>> 
>> Given the above, it seems like org-effort-property's docstring is at
>> least somewhat inaccurate.
>> 
> 
> 

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: using #+ to define faces

[Jean-Christophe Helary]

> On Dec 31, 2019, at 18:57, Nicolas Goaziou  wrote:
> 
> Hello,
> 
> Jean-Christophe Helary 
> writes:
> 
>> I would like to define faces on a file basis by using #+ but I'm not
>> finding relevant info in the manual.
>> 
>> Is it possible ?
> 
> You may be able to set faces using file-local variables (info
> "(emacs)File Variables"), but I haven't checked.

Thank you Nicolas, I'll check later.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

using #+ to define faces

[Jean-Christophe Helary]

I would like to define faces on a file basis by using #+ but I'm not finding 
relevant info in the manual.

Is it possible ?


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

Thank you Stefan. I'll try to reproduce the issue and then I'll report.

Jean-Christophe

> On Nov 27, 2019, at 12:24, Stefan Monnier  wrote:
> 
>> What should happen is that
>> 1) packages.el should see that I'm trying to install a package that requires
>> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
>> installed and do I really want to do that, etc.
>> 
>> 2) *or* just consider that it's better for me to use 9.2.6 instead of
>> whatever comes with emacs and make sure that the older package is forgotten
>> by emacs.
> 
> I think 2 is the right option.  package.el was designed such that you
> can have various versions of a given package installed.  Only one of the
> can be activated at any given time, because Emacs Lisp doesn't provide any
> way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> should be a perfectly normal situation.
> 
> Any misbehavior that results from this should be reported as a bug
> (especially if it can be reproduced).
> 
> 
>Stefan

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

> On Nov 27, 2019, at 11:59, Cook, Malcolm  wrote:
> 
> Tim,
>  
> Yes, it is a bit of dependency hell.

I see 2 solutions here:

1) org is only provided as a built-in package and updated there when necessary
2) org is removed from the built in packages

The current situation is really weird.

Jean-Christophe

>  
> Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 8.3.x :
>  
>  
> Here's what I do, at the shell:
>  
>   emacs -Q -batch -eval "(progn (require 'package) (add-to-list 
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\;;))  
> (package-initialize) (package-refresh-contents) (package-install 
> 'org-plus-contrib))"
>  
> This assures that org is not already loaded when org is compiled, which I've 
> learned is the source of creating a mess.
>  
> Note: I use org-plus-contrib from melpa instead of org.  If you want just 
> org, 
> you could simply:
>  
>   emacs -Q -batch -eval "(progn (require 'package) 
> (package-initialize) 
> (package-refresh-contents) (package-install 'org-plus-contrib))"
>  
> HTH,
>  
> Malcolm
>  
>  
>  
> From: Emacs-orgmode  On Behalf 
> Of Tim Cross
> Sent: Tuesday, November 26, 2019 3:41 PM
> To: Nick Dokos 
> Cc: Org-mode ; Emacs developers 
> Subject: Re: org 9.2.6 and org 9.1.9
>  
> CAUTION: This email was received from an External Source
>  
> 
> There is a very important rule which must be followed wrt org-mode 
> installation. It is critical that no version of org is already loaded before 
> installing a new version. This can be quite tricky as many of us have org 
> setups which automatically load some org functionality without explicitly 
> opening an org file or agenda view (for example, you might be using an org 
> add-on for email). Situation is worse if we are loading org as part of our 
> init.el.
>  
> I'm also not sure that tweaking the load-path order is sufficient if your 
> installing org via M-x package-install as there is a 'chicken and egg' 
> problem with the initial install. If your init.el file is loading org 
> functionality and you only have the built-in org version installed, that 
> version will be loaded before you run package-install. Probably works if you 
> install via your init.el though.
>  
> I've found the safest thing to do is only use autoload or use-package with 
> deferred loading for org and whenever updating org (I use the 
> org-plus-contrib package from the org elpa repo) only update immediately 
> after a fresh restart of emacs and before doing anything else.  Failing to do 
> this often results in a broken build as you get a set of new org elc files 
> which contains definitions from two different org versions. When the versions 
> are only different in minor version numbers, this mixed build may not even be 
> noticeable, but when major version differences exist, you get the symptom of 
> broken functionality, missing definitions or unbound symbols.
>  
> The situation is made worse by package maintainers specifying the latest org 
> version rather than the version built into Emacs when the bundled version 
> would be sufficient.
>  
> It took me a while to structure my init.el file such that no org 
> functionality was loaded until I used something which depends on it. However, 
> once I did, provided I only update org in a fresh new session, all works 
> flawlessly. I found use-package package really helped with this. 
>  
>  
>  
> On Wed, 27 Nov 2019 at 06:22, Nick Dokos  wrote:
> Jean-Christophe Helary  writes:
> 
> > org 9.1.9 is a built-in
> >
> > but org 9.2.6 comes as a dependency to some packages and having both 
> > installed creates conflicts.
> >
> 
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
> 
> (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
> 
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
> 
>(delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
> 
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
> 
> > Why

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

Nick, thank you for your reply.

> On Nov 27, 2019, at 4:15, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> org 9.1.9 is a built-in
>> 
>> but org 9.2.6 comes as a dependency to some packages and having both 
>> installed creates conflicts.
>> 
> 
> What conflicts are you seeing?

At one point I was unable to archive subtrees because some function was 
undefined.
I uninstalled 9.2.6 and the issues was fixed.

> I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems:

Obviously you are not the typical user... :)

What should happen is that
1) packages.el should see that I'm trying to install a package that requires 
9.2.6 as a dependency and it should notify me that 9.1.9 is already installed 
and do I really want to do that, etc.

2) *or* just consider that it's better for me to use 9.2.6 instead of whatever 
comes with emacs and make sure that the older package is forgotten by emacs.

But honestly, I think 1) should be the default for any package.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

org 9.1.9 is a built-in

but org 9.2.6 comes as a dependency to some packages and having both installed 
creates conflicts.

Why does that happen ?

Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues with that 
situation and that's extremely confusing. What is the best way to solve that ?



Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] sync a single subtree to a different file

[Jean-Christophe Helary]

I'm looking for a way to sync a given subtree to a different file, 
semi-automatically (it at the launch of a command).

Is there something like that in org-mode ?

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Capture template issue ?

[Jean-Christophe Helary]

The issue is systematic.

I have changed my settings to:

 org-hide-leading-stars nil
 org-startup-folded nil 

But that doesn't change anything.

I have quasi systematically the issue I described when the file that will be 
modified by the capture is not visible when I capture, and generally I don't 
have it when it is visible when I do.

Currently, the place where that happens most (?) is when I add captured text in 
a "file+datetree" structure right over a "file+headline" structure.

Jean-Christophe Helary 

> On Sep 17, 2019, at 8:48, Jean-Christophe Helary 
>  wrote:
> 
> I have an issue with my capture templates where if I add an item at the end 
> of list, the item seems to "eat" the following line break and merges with the 
> item that follows:
> 
> * List 1
> ** item 1
> ** item 2
> * List 2
> ** item 3
> ** item 4
> 
> displayed
> 
> * List 1 ...
> * List 2 ...
> 
> I add item 5 to List 1, I should get:
> 
> * List 1
> ** item 1
> ** item 2
> ** item 5
> * List 2 ...
> 
> But instead I get
> 
> * List 1
> ** item 1
> ** item 2
> ** item 5 * List 2 ...
> 
> which makes List 2 disappear for all practical purposes.
> 
> That's pretty systematic, and very annoying.
> 
> Nearly all my templates show a similar behavior.
> 
> This one was:
> 
>  (file+headline "~/org/journal.org" "Dictionnaire")
>   "* %? :%^{tag}:\n")
> 
> I'm using the built-in 9.1.9 version, with an emacs from master built a few 
> days ago, on macos.
> 
> And my org setup is this:
> 
> (setq org-use-speed-commands t
>  org-directory "~/org"
>  org-default-notes-file (concat org-directory "/notes.org")
>  org-refile-targets '((org-agenda-files :maxlevel . 3))
>  org-refile-use-outline-path 'file
>  org-outline-path-complete-in-steps nil
>  org-refile-allow-creating-parent-nodes 'confirm
>  org-startup-indented t
>  org-use-fast-todo-selection t
>  org-return-follows-link t
>  org-link-abbrev-alist '(("message" . "mailto"))
>  org-todo-keywords
>  '((sequence "TODO(t)" "|" "DONE(d)")
>   (sequence "WAIT(w)" "|" "IN-PROGRESS" "|" "CANCELED(c)"))
>  org-agenda-files
>  '("/Users/suzume/org/" "/Users/suzume/Library/Application 
> Support/Notational Data/")
>  org-indirect-buffer-display 'current-window
>  org-modules
>  '(org-bbdb org-bibtex org-docview org-habit org-info org-irc org-mhe 
> org-protocol org-rmail)
>  org-support-shift-select t
>  org-todo-keyword-faces
>  '(("IN-PROGRESS" . "orange") ("WAIT" . "magenta") ("CANCELED" . 
> "darkgreen") ("TODO" . "pink") ("DONE" . "green")))
> 
> 
> Where should I investigate to fix this ?
> 
> 
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
> 
> 
> 

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] Capture template issue ?

[Jean-Christophe Helary]

I have an issue with my capture templates where if I add an item at the end of 
list, the item seems to "eat" the following line break and merges with the item 
that follows:

* List 1
** item 1
** item 2
* List 2
** item 3
** item 4

displayed

* List 1 ...
* List 2 ...

I add item 5 to List 1, I should get:

* List 1
** item 1
** item 2
** item 5
* List 2 ...

But instead I get

* List 1
** item 1
** item 2
** item 5 * List 2 ...

which makes List 2 disappear for all practical purposes.

That's pretty systematic, and very annoying.

Nearly all my templates show a similar behavior.

This one was:

   (file+headline "~/org/journal.org" "Dictionnaire")
   "* %? :%^{tag}:\n")

I'm using the built-in 9.1.9 version, with an emacs from master built a few 
days ago, on macos.

And my org setup is this:

(setq org-use-speed-commands t
  org-directory "~/org"
  org-default-notes-file (concat org-directory "/notes.org")
  org-refile-targets '((org-agenda-files :maxlevel . 3))
  org-refile-use-outline-path 'file
  org-outline-path-complete-in-steps nil
  org-refile-allow-creating-parent-nodes 'confirm
  org-startup-indented t
  org-use-fast-todo-selection t
  org-return-follows-link t
  org-link-abbrev-alist '(("message" . "mailto"))
  org-todo-keywords
  '((sequence "TODO(t)" "|" "DONE(d)")
(sequence "WAIT(w)" "|" "IN-PROGRESS" "|" "CANCELED(c)"))
  org-agenda-files
  '("/Users/suzume/org/" "/Users/suzume/Library/Application 
Support/Notational Data/")
  org-indirect-buffer-display 'current-window
  org-modules
  '(org-bbdb org-bibtex org-docview org-habit org-info org-irc org-mhe 
org-protocol org-rmail)
  org-support-shift-select t
  org-todo-keyword-faces
      '(("IN-PROGRESS" . "orange") ("WAIT" . "magenta") ("CANCELED" . 
"darkgreen") ("TODO" . "pink") ("DONE" . "green")))


Where should I investigate to fix this ?


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] org-megaup

[Jean-Christophe Helary]

Thank you Nick for the help.

It looks like I some kind of interference between the built-in org-mode and the 
most recent package available in melpa. Everything is fixed now.

> On Aug 31, 2019, at 4:42, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> When I use org-megaup I get a "Invalid function:
>> org-preserve-local-variables" is there a way to fix that ?
>> 
> 
> org-megaup is not defined AFAICT - do you mean `org-metaup'?
> 
> If not, disregard the rest of this message.
> 
> If yes, I don't see any problems, so you might want to provide the
> context (e.g. are trying to move subtrees up, move table rows up or
> move items in a list up?) Check also the value of `org-metaup-hook' to
> see if something weird crept in there.
> 
> If it happens regardless of context, I would edebug the org-metaup
> function and see where the error message comes from - BTW,
> org-preserve-local-variables is a macro, not a function (so that might
> have something to do with it), defined in org-macs.el. If your setup
> is curdled, that might not be loaded, so try `(load-library org-macs)`
> and see if that resolves if: if it does, then you have to figure out
> whether there is something wrong with your setup (if it doesn't load
> that file automatically) or how it got curdled (if it does).
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
> 
> 

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] org-megaup

[Jean-Christophe Helary]

> On Aug 31, 2019, at 4:42, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> When I use org-megaup I get a "Invalid function:
>> org-preserve-local-variables" is there a way to fix that ?
>> 
> 
> org-megaup is not defined AFAICT - do you mean `org-metaup'?

Yes, thank you. I'll check everything you wrote this we.

Jean-Christophe

> If not, disregard the rest of this message.
> 
> If yes, I don't see any problems, so you might want to provide the
> context (e.g. are trying to move subtrees up, move table rows up or
> move items in a list up?) Check also the value of `org-metaup-hook' to
> see if something weird crept in there.
> 
> If it happens regardless of context, I would edebug the org-metaup
> function and see where the error message comes from - BTW,
> org-preserve-local-variables is a macro, not a function (so that might
> have something to do with it), defined in org-macs.el. If your setup
> is curdled, that might not be loaded, so try `(load-library org-macs)`
> and see if that resolves if: if it does, then you have to figure out
> whether there is something wrong with your setup (if it doesn't load
> that file automatically) or how it got curdled (if it does).
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] org-megaup

[Jean-Christophe Helary]

When I use org-megaup I get a "Invalid function: org-preserve-local-variables" 
is there a way to fix that ?

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] Changing the face of the capture template ?

[Jean-Christophe Helary]

Sorry for asking such a beginner question.

I'm using a non monospace font for my daily work and I'd like to have the 
capture template buffer be in monospace. How do I do that ?


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] message:// links

[Jean-Christophe Helary]

Thank you Nicolas.

Jean-Christophe 

> On Nov 10, 2018, at 16:28, Nicolas Goaziou  wrote:
> 
> Hello,
> 
> Jean-Christophe Helary  writes:
> 
>> I'm pasting a message:// link into an org-mode file but it fails to be
>> recognized as a link that should open in a mail client.
>> 
>> What is a simple way to have org-mode recognize such links ?
> 
> One simple way is to define "message:" as an alias for "mailto:;, which
> is the Org syntax for such links.  This is done with
> `org-link-abbrev-alist' variable, or in-buffer "LINK" keyword:
> 
>  (setq org-link-abbrev-alist '(("message" . "mailto")))
> 
> One drawback is that you cannot write plain links with abbreviations. So
> [[message:f...@bar.baz]] works, but message:@f...@bar.baz does not.
> 
> If that is an issue, you can also define a new link with
> `org-link-set-parameters':
> 
>(org-link-set-parameters "message" 
> :follow (lambda (path) (browse-url (concat "mailto:; path
> 
> HTH,
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] message:// links

[Jean-Christophe Helary]

I'm pasting a message:// link into an org-mode file but it fails to be 
recognized as a link that should open in a mail client.

What is a simple way to have org-mode recognize such links ?

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] bug#27140: Different key bindings between GUI emacs and terminal emacs

[Jean-Christophe Helary]

Sorry, I missed that. Proceed with closing and if there is an issue I'll send a 
report again.

Jean-Christophe 

> On Jul 7, 2018, at 20:12, Nicolas Goaziou  wrote:
> 
> Nicolas Goaziou  writes:
> 
>> I think I fixed it in Org's master branch (aka Org 9.2).
>> 
>> Meanwhile, I think setting `org-use-extra-keys' to a non-nil value
>> should do the trick.
>> 
>> Could you confirm it?
> 
> I'm closing this report. Since there was no answer from the OP, I assume
> the issue is fixed.

Re: [O] info URL « open at point » patch

[Jean-Christophe Helary]

> On Jun 24, 2018, at 15:57, Vincent Belaïche  wrote:
> 
> Bonjour tout l'monde !
> I am writing to both Emacs-devel and org-mode list because this concerns
> browsing URL, and Org-mode already has quite some stuff on this.
> Recently I came across this that in an Info file a « file: » protocol
> URL is not opened at point. Please find attached a patch to make it
> known to the Emacs info browser.
> My point was that I have some manual that are only in HTML or PDF, like
> the SVN manual, In have a local copy, and I want to find it through a
> manual index that I written in Texinfo to get an info node with this
> index.

> 

Wouldn't it be shorter and easier to understand/maintain to explicitly describe 
the protocols:

+ ((setq node (Info-get-token (point) 
"\\(?:f\\(?:ile\\|tp\\)\\|https?\\)://"

???

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 13, 2018, at 7:48, Göktuğ Kayaalp <s...@gkayaalp.com> wrote:
> 
> People/packages can define their own keywords for in buffer settings,
> and again here translations can cause breakage.

That's a design problem, not a l10n problem.

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 12, 2018, at 20:07, Göktuğ Kayaalp <s...@gkayaalp.com> wrote:

> How do you know that if you first learned the translated version?

Because (define eklemek +)

If you run Scheme, you either know or can discover that.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 12, 2018, at 7:23, Göktuğ Kayaalp <s...@gkayaalp.com> wrote:
> 
>>> I really don't see the point of trying to localize org keywords. To
>>> me, they are like the keywords in any programming language - part of
>>> the language. Would you consider translating C or LISP keywords?
>> 
>> There are no practical reasons why that should not be possible. The
>> current state of affairs is only due to design constraints when the
>> languages were conceived.
>> 
>> In Scheme, for ex. you can actually redefine all the language keywords
>> very easily without any impact on the interpreter.
> 
> Practical reason: communication.  I'm a Turkish speaker, suppose I'm
> monolingual, and I have a problem with the function
> ‘güncel-devamla-çağır’ in Scheme.

If you have a problem with that function and you use Scheme, you know that it 
is mapped to call-with-current-continuation and you know where to look for 
information. And if you're monolingual, chances are that you won't be able to 
make sense of what you find in English.

> The language of programming is English.

And of course, when 2 Turkish programmers talk about programming they shift to 
English... No, they don't. Keywords are arbitrary strings. Try APL and see how 
"English" applies.

> Org allows drawers with
> arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
> :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
> :LOGBOOK: reserved.  This means that you can't reliably know if anybody
> has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
> Same thing with todo keywords, tags, etc.

And that is a good thing.

>> Localization, when properly done is never a nightmare to maintain.
> 
> I appreciate your efforts on i18n and l10n on Emacs, but unfortunately I
> am yet to find a properly localised piece of software, especially in the
> FOSS community.

Proprietary software has so many issues that most pro-grade software is not 
even localized.

>  Also, when I need help online, I need the English
> messages anyways (and translated manuals, if they ever exist, are a joke
> all the time).

If FOSS activists took as much time fixing manuals as they take for fixing code 
that would not be an issue. l10n is not as good as code *because* it is not 
defined with a higher priority and a better consciousness of the linguistic 
issues, and that is because monolingual activists think one language is 
sufficient (funny how that does not apply to programming languages, but they 
don't seem to be conscious of that contradiction...)


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 10, 2018, at 0:41, Diego Zamboni <di...@zzamboni.org> wrote:
> 
> 
> On Wed, May 9, 2018 at 3:48 PM, Jean-Christophe Helary <brandel...@gmail.com 
> <mailto:brandel...@gmail.com>> wrote:
> You misquoted me. I was talking about design constraints when C and Lisp were 
> created, which kept language creators from "inventing" proper language 
> localization. I was specifically replying to Diego Zamboni regarding that.
> 
> I don't think it was only those constraints. Imagine if C and LISP had been 
> designed with "keywords in your own language" in mind.

That was not physically possible at the time. It is now. And as I wrote, Scheme 
can do that easily. But that's not the topic of the current thread. Sorry for 
that.

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Jean-Christophe Helary]

You misquoted me. I was talking about design constraints when C and Lisp were 
created, which kept language creators from "inventing" proper language 
localization. I was specifically replying to Diego Zamboni regarding that.

> On May 9, 2018, at 22:25, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> 
> Hello,
> 
> Jean-Christophe Helary <brandel...@gmail.com> writes:
> 
>> There are no practical reasons why that should not be possible.
> 
> Yet, I gave some already. Consider the following three documents:


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Localized org-mode

[Jean-Christophe Helary]

> On May 9, 2018, at 21:07, Kaushal Modi <kaushal.m...@gmail.com> wrote:
> 
> Hello all,
> 
> On Wed, May 9, 2018, 8:01 AM Diego Zamboni <di...@zzamboni.org 
> <mailto:di...@zzamboni.org>> wrote:
> I really don't see the point of trying to localize org keywords. To me, they 
> are like the keywords in any programming language - part of the language. 
> Would you consider translating C or LISP keywords?

There are no practical reasons why that should not be possible. The current 
state of affairs is only due to design constraints when the languages were 
conceived.

In Scheme, for ex. you can actually redefine all the language keywords very 
easily without any impact on the interpreter.

> In addition to the trouble of supporting something like this within Emacs, 
> think of the growing ecosystem of tools which support org mode - they would 
> all need to be aware of these localizations. It would be a nightmare to 
> maintain.

Localization, when properly done is never a nightmare to maintain.

> So much +1 on that! Supporting multi-language keywords will make it difficult 
> for 3rd party Org parsers to adopt them too, resulting in even lesser Org 
> adoption.

Genuine question: how many 3rd party tools do support the org format ?

> I like Nicolas' idea where display properties are used to replace the English 
> keywords with the translation; that way the actual Org source remains 
> untouched. 

What matters is that users find org easy to use in their language. But emacs 
(the main org user) is so far behind in that respect compared to the rest of 
the FLOSS ecosystem that even having one mode that implements some sort of l10n 
would be huge. Although, it would be nice to have that work nicely with already 
existing l10n processes. 


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

[O] 3 manuals fail to export to PO (gnus, idlwave, org)

[Jean-Christophe Helary]

'

elisp.texi:167: (po4a::tex)
unmatched end of environment 'html'

modes.texi:2631: (po4a::tex)
unmatched end of environment 'ftable'



Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] 3 manuals fail to export to PO (gnus, idlwave, org)

[Jean-Christophe Helary]

> On Apr 16, 2018, at 0:00, Eli Zaretskii <e...@gnu.org> wrote:
> 
>> 3 manuals distributed with emacs fail to export to po format when using the 
>> following command:
>> 
>> po4a-gettextize -f texinfo -M utf8 -m name.texi -p name.texi.fr.po
>> 
>> gnus.texi
>> 
>> Use of uninitialized value $newfilepath in string eq at 
>> /opt/local/lib/perl5/5.24/Locale/Po4a/TeX.pm line 961.
>> po4a::tex: Can't find gnus.texi with kpsewhich
> 
> I don't understand what this error message means, in terms of the
> Texinfo sources.  Can you explain, please?  Taken at face value, it
> looks like a bug in TeX.pm, whereby a variable is not initialized.

I just sent the report, my idea is that it's po4a issues but the po4a-devel 
list doesn't respond.

Jean-Christophe 

> 
>> idlwave.texi
>> 
>> idlwave.texi:370: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:1242: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:2964: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:3101: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:3497: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:3559: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:4021: (po4a::tex)
>> unmatched end of environment 'html'
>> idlwave.texi:4078: (po4a::tex)
>> unmatched end of environment 'html'
> 
> These all seem bogus, because the source looks correct to me.  Here's
> the first instance:
> 
>  @html
>  
>  @end html
> 
> I see nothing wrong here; do you?
> 
> (Maybe you are using an old version of the manual; I looked in what's
> currently on the emacs-26 branch of the Emacs Git repository.)
> 
>> idlwave.texi:4088: (po4a::tex)
>> un-balanced { in 'Whenever an IDL error occurs or a breakpoint is hit, I get'
> 
> Nothing wrong here, either:
> 
>  @enumerate
> 
>  @item @strong{Whenever an IDL error occurs or a breakpoint is hit, I get
>  errors or strange behavior when I try to type anything into some of my
>  IDLWAVE buffers.}
> 
> The Texinfo manual says it's okay to have multi-line text after @item:
> 
> Write the text of the enumerated list in the same way as an itemized
>  list: write a line starting with '@item' at the beginning of each item
>  in the enumeration.  It is ok to have text following the '@item', and
>  the text for an item can continue for several paragraphs.
> 
> Looks like po4a doesn't support this feature of the Texinfo language?
> 
>> org.texi
>> 
>> perl just keeps churning data without outputting anything.
> 
> Hard to do anything with this, without more diagnostic data.
> 
>> A number of other manuals output errors but are properly exported to po:
> 
> These looks bogus as well.  E.g.:
> 
>> cmdargs.texi:726: (po4a::tex)
>> unmatched end of environment 'vtable'
> 
> There's a matching "@vtable @env" on line 674.
> 
> So I submit these problems are bugs in po4a, and the Emacs manuals are
> OK.
> 
> Thanks.

Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: [O] Applescript help

[Jean-Christophe Helary]

> On Nov 13, 2017, at 17:39, Alan Schmitt <alan.schm...@polytechnique.org> 
> wrote:
> 
> On 2017-11-11 20:06, Jay Iyer <jayiye...@gmail.com> writes:
> 
>> Hi, in my Org workflow, I am trying to use the do-applescript function to
>> hide an active Emacs session.  Can you tell me what I am doing wrong with
>> the following that I think should work but is not?  Thanks. -jay
>> 
>> (do-applescript "tell application \"Finder\" set visible of application
>> process \"Emacs\" to false")
> 
> Don't you need an "end tell"?

"end tell" if it's a block "to" if it's a line:

>> (do-applescript "tell application \"Finder\" to set visible of application 
>> process \"Emacs\" to false")



Jean-Christophe Helary
---
@brandelune http://mac4translators.blogspot.com

Re: [O] htmlize

[Jean-Christophe Helary]

Thank you Jonas !

Jean-Christophe 


> On Oct 25, 2017, at 21:51, Jonas Bernoulli  wrote:
> 
> This was discussed here: https://github.com/hniksic/emacs-htmlize/issues/7.

[O] htmlize

[Jean-Christophe Helary]

I tried to export to html and org told me to first install htmlize ( 
https://github.com/hniksic/emacs-htmlize).

I tried to find an emacs-htmlize in the package list, and found nothing, so I 
went to the github page and since  saw it was a seemingly normal el package 
called htmlize I checked again in the packages, found it and installed it 
directly from emacs.

Why doesn't org suggest to use package.el to install htmlize? That would be 
less confusing to users who don't have it installed by default.

Jean-Christophe 

Re: [O] capture templates and ^{prompt}

[Jean-Christophe Helary]

Sorry to send this question again:

> Are there cases where %\1 ... %\N would be used *outside* of a string in a 
> template?

Jean-Christophe 


> On Jun 30, 2017, at 20:04, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:
> 
>> 
>> On Jun 30, 2017, at 18:47, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
>> 
>> Jean-Christophe Helary <jean.christophe.hel...@gmail.com> writes:
>> 
>>> * TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n
>>> 
>>> gives
>>> 
>>> * TODO stuff [/]
>>>  
>>> ** TODO %^A stuff 
>>> 
>>> Why is that ?
>> 
>> In a string, backslash needs to be escaped: %\\1
> 
> That's certainly something to add to the documentation:
> 
> %\1 ... %\N   Insert the text entered at the Nth %^{prompt}, where N is a 
> number, starting from 1.
> 
> Are there cases where %\1 ... %\N would be used *outside* of a string in a 
> template?
> 
> Jean-Christophe

Re: [O] capture template and writeroom mode ?

[Jean-Christophe Helary]

Thank you Bsstien.

> On Jul 3, 2017, at 12:46, Bastien  wrote:
> 
>> What would be the best way to have writeroom mode called in one
>> given capture template and not the others ?
> 
> I would you a (file+)function to get the location:
> 
>`(file+function "path/to/file" function-finding-location)'
>  A function to find the right location in the file.
> 
>`(function function-finding-location)'
>  Most general way: write your own function which both visits
>  the file and moves point to the right location.
> 
> then tell the function to use writeroom-mode.

I'm already using the file+datetree target so I guess that's not possible, 
unless I define a function that triggers the writeroom mode *and* adds the 
datetree...

 ("j" "Journal" entry (file+datetree "~/org/journal.org")   
  
   "* %^{Titre} [%<%H:%M>]\n%?\n") ;;; :clock-in t :clock-resume t) 
   

Jean-Christophe 

[O] capture template and writeroom mode ?

[Jean-Christophe Helary]

What would be the best way to have writeroom mode called in one given capture 
template and not the others ?

Jean-Christophe 

Re: [O] capture templates and ^{prompt}

[Jean-Christophe Helary]

> On Jun 30, 2017, at 18:47, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> 
> Jean-Christophe Helary <jean.christophe.hel...@gmail.com> writes:
> 
>> * TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n
>> 
>> gives
>> 
>> * TODO stuff [/] 
>>
>> ** TODO %^A stuff 
>> 
>> Why is that ?
> 
> In a string, backslash needs to be escaped: %\\1

That's certainly something to add to the documentation:

%\1 ... %\N Insert the text entered at the Nth %^{prompt}, where N is a 
number, starting from 1.

Are there cases where %\1 ... %\N would be used *outside* of a string in a 
template?

Jean-Christophe

Re: [O] capture templates and ^{prompt}

[Jean-Christophe Helary]

* TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n

gives

* TODO stuff [/]

** TODO %^A stuff 

Why is that ?

Jean-Christophe 
   


> On Jun 30, 2017, at 18:21, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:
> 
> Ooops, yes, that was totally under my nose :)
> Thank you very much.
> 
> Jean-Christophe 
> 
>> On Jun 30, 2017, at 18:18, numbch...@gmail.com wrote:
>> 
>> Check out the docstring of variable `org-capture-templates`.
>> There is a doc like this:
>> ```
>> %\1 ... %\N Insert the text entered at the nth %^{prompt}, where N
>>   is a number, starting from 1.

Re: [O] capture templates and ^{prompt}

[Jean-Christophe Helary]

Ooops, yes, that was totally under my nose :)
Thank you very much.

Jean-Christophe 

> On Jun 30, 2017, at 18:18, numbch...@gmail.com wrote:
> 
> Check out the docstring of variable `org-capture-templates`.
> There is a doc like this:
> ```
> %\1 ... %\N Insert the text entered at the nth %^{prompt}, where N
>   is a number, starting from 1.

[O] capture templates and ^{prompt}

[Jean-Christophe Helary]

I'm looking for a way to use the string acquired by prompt in a second location 
in the template, like:

* TODO %^{prompt} [/] :sometag:\n** TODO (value of ^{prompt} comes here) 
:someothertag:\n

What's the best way to get that "value of ^{prompt}" ?

Jean-Christophe 

Re: [O] keybindings again...

[Jean-Christophe Helary]

> On Jun 30, 2017, at 17:14, Nicolas Goaziou  wrote:

>> So, I have a few suggestions to improve that part of the documentation:
>> 1) add a list of preset keys in the manual
>> 2) add a line about speed keys in the compact guide
>> 
>> That's something I could do if the idea is accepted.
> 
> Sure! Improvements to documentation are always welcome.

Ok, I'll put that on my todo list now that I have solved that shortcut issue... 
:)

Jean-Christophe 

Re: [O] keybindings again...

[Jean-Christophe Helary]

> On Jun 30, 2017, at 14:27, Nicolas Goaziou  wrote:
> 
>> It would be nice if the org manual mentioned that too, and give
>> alternative keybindings for use in the terminal because that's
>> extremely confusing.
> 
> It does: (info "(org) TTY keys").

The alternative to M-S-RET is C-c C-x M = C-c C-x S-m

Why set an alternative like this when ESC RET S- does exactly the 
same thing and is way shorter/more practical ?

> See also `org-replace-disputed-keys'.

After looking at the "big" manual, I found about speed keys which seem to be a 
much more pragmatic approach to sorting that gui/tty key issue in org-mode. But 
except for a small paragraph and a few items in the tty section I could not 
find any reference to them, and nothing at all in the compact manual.

So, I have a few suggestions to improve that part of the documentation:
1) add a list of preset keys in the manual
2) add a line about speed keys in the compact guide

That's something I could do if the idea is accepted.

Jean-Christophe 

ps: section C3 of the manual has this line about Sacha Chua: "Sacha Chua 
suggested copying some linking code from Planner, and helped make Org pupular 
through her blog." It should be "popular" not "pupular".

Re: [O] keybindings again...

[Jean-Christophe Helary]

Eli and Yuri,

Thank you *so much* for the thorough explanations. Now I know.
After having finally understood how git was working I was going back to my list 
of things to do for/with emacs and got frustrated by that shortcut that kept 
not working...

Jean-Christophe 

> On Jun 30, 2017, at 15:17, Eli Zaretskii <e...@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.hel...@gmail.com>
>> Do you mean that Shift is not recognized as a modified key by the terminal ?
> 
> No, that's not it.

Re: [O] keybindings again...

[Jean-Christophe Helary]

> On Jun 30, 2017, at 14:27, Nicolas Goaziou  wrote:

>> It would be nice if the org manual mentioned that too, and give
>> alternative keybindings for use in the terminal because that's
>> extremely confusing.
> 
> It does: (info "(org) TTY keys").

Thank you for the pointer. Although I don't think I ever used a teletypewriter 
in my life :) Maybe sometimes in the 21st century we'll have to think about a 
change in terminology...

I use the compact manual as a reference for my uses and I find it extremely 
useful for beginners. Would it be possible to insert a few line on that subject 
in there too? Something like "People who use org-mode in a tty terminal should 
refer to section 15.9 of the manual for alternative key bindings."

> See also `org-replace-disputed-keys'.

Thank you.

Jean-Christophe

Re: [O] keybindings again...

[Jean-Christophe Helary]

> On Jun 30, 2017, at 11:51, Kaushal Modi <kaushal.m...@gmail.com> wrote:
> 
> On Thu, Jun 29, 2017 at 10:43 PM Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com <mailto:jean.christophe.hel...@gmail.com>> 
> wrote:
> I'm using emacs built from master, emacs -nw, after moving .emacs.el and 
> .emacs.d away, on OSX 10.12.
> 
> 
> I'm trying to assign M-S-RET to org-insert-todo-heading because for some 
> reason it is not assigned by default: every time I hit ESC S-RET I get ESC 
> RET only.
> 
> It's the limitation of the terminal.

Do you mean that Shift is not recognized as a modified key by the terminal ?

> If you do C-h c Esc+Shift+Return, Emacs will detect only Esc+Return. So you 
> will see M-RET in the echo area.
> 
> You probably just need to use some other binding.

It would be nice if the org manual mentioned that too, and give alternative 
keybindings for use in the terminal because that's extremely confusing.

Jean-Christophe Helary 

[O] keybindings again...

[Jean-Christophe Helary]

I'm using emacs built from master, emacs -nw, after moving .emacs.el and 
.emacs.d away, on OSX 10.12.


I'm trying to assign M-S-RET to org-insert-todo-heading because for some reason 
it is not assigned by default: every time I hit ESC S-RET I get ESC RET only.

So, I tried things from
http://ergoemacs.org/emacs/keystroke_rep.html

First, this works fine:
(global-set-key (kbd "M-b") 'org-insert-todo-heading)

But this doesn't:
(global-set-key (kbd "M-") 'org-insert-todo-heading)

What I get here is the old M-return = org-insert-heading.

What is the problem here ?

Jean-Christophe 

Re: [O] emacs vs emacs -nw

[Jean-Christophe Helary]

> On May 31, 2017, at 20:30, Eli Zaretskii <e...@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.hel...@gmail.com>
>> Date: Wed, 31 May 2017 19:41:00 +0900
>> Cc: Org-mode <emacs-orgmode@gnu.org>
>> 
>> Ok, I just tried something else:
>> 
>> (setq  ns-function-modifier 'meta) and what I get is *very* similar to the 
>> issue I have with ESC:
>> 
>> FN-x correctly "calls" M-x
>> FN-left in a level 2 header in org mode triggers beginning-of-buffer and 
>> *not* org-promote-header.
>> 
>> So the problem is not limited to ESC, and maybe not limited to org-mode.
> 
> AFAIR, the remapping of Meta-something to ESC-something happens
> automatically only for characters, not for function keys.  For
> function keys, this remapping must be set somewhere, or it won't
> happen.  You can see in bindings.el how some of these remappings are
> set up.

Yes, I realized after Yuri's comment that the comparison with ESC was a bit 
far-fetched.

Jean-Christophe 

Re: [O] emacs vs emacs -nw

[Jean-Christophe Helary]

> On May 31, 2017, at 19:04, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:

>> On X11/GNU/Linux, I get header promotion with Alt+Left but word
>> navigation on Esc Left.
> 
> Now that I think about it, I just tried this:
> 
> (setq  ns-right-command-modifier 'meta)
> 
> And I get the expected behavior in GUI emacs. So it's really an issue about 
> ESC that is not recognized in GUI mode for *some* bindings in org-mode.

Ok, I just tried something else:

(setq  ns-function-modifier 'meta) and what I get is *very* similar to the 
issue I have with ESC:

FN-x correctly "calls" M-x
FN-left in a level 2 header in org mode triggers beginning-of-buffer and *not* 
org-promote-header.

So the problem is not limited to ESC, and maybe not limited to org-mode.

Jean-Christophe

Re: [O] [org] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

> On May 31, 2017, at 19:01, Eric S Fraga  wrote:
> 
> On Wednesday, 31 May 2017 at 02:38, Tim Cross wrote:
>> I'm sure this has been checked, but make sure it isn't the window
>> manager/OS 'stealing' the keys. When I install emacs on any system,
> 
> My own experience over the years is that this is indeed usually the
> culprit, especially for keys such as M-arrows which are often bound to
> functions like changing workspace views.

In this case, M-Left (ESC-left) triggers backward-word instead of the expected 
org-promote-subtree.

It does not seem to me that the OS is stealing anything.

Jean-Christophe

Re: [O] emacs vs emacs -nw

[Jean-Christophe Helary]

> On May 31, 2017, at 18:41, Yuri Khan <yuri.v.k...@gmail.com> wrote:
> 
> On Wed, May 31, 2017 at 3:58 PM, Jean-Christophe Helary
> <jean.christophe.hel...@gmail.com> wrote:
> 
>>> Could you provide an example and/or a recipe to demonstrate the issue?
>> 
>> • Open an org file with a few headers and different header levels.
>> • Select a lower level header
>> • Hit M-left
> 
> I believe this last step may be a bit unclear and misleading. Today,
> Meta is not a real key. You only get it via emulation from ESC or a
> modifier key, normally Alt on PCs. I don’t know the convention on Mac.

Ooops, you're right. Indeed.

On my machine I *systematically* use ESC for META.

> On X11/GNU/Linux, I get header promotion with Alt+Left but word
> navigation on Esc Left.

Now that I think about it, I just tried this:

(setq  ns-right-command-modifier 'meta)

And I get the expected behavior in GUI emacs. So it's really an issue about ESC 
that is not recognized in GUI mode for *some* bindings in org-mode.

Jean-Christophe 

> 
>> Expected result:
>> • the header is promoted
>> 
>> Result in GUI Emacs (Aquamacs too)
>> • The cursor jumps to the beginning of the previous word

Re: [O] [org] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

Apologies,

> On May 31, 2017, at 12:51, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com> wrote:

> This morning I have installed emacs from macport (emacs-app-devel) and I've 
> also built it from the repository (./configure with-ns).
> 
> In the locally build version Esc-Left promotes a header. But Esc-Right does 
> not demote it, it only moves to the next word.

The above it incorrect. I had modified the file before the build. I get the 
same result as I've got so far. Sorry for that.

Jean-Christophe 

Re: [O] [org] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

> On May 31, 2017, at 11:38, Tim Cross  wrote:
> 
> It is certainly a weird issue. 

I couldn't agree more :)

> If there was a problem at the OS, window manager or interface library (i.e. 
> gtk) level, it should affect all bindings. 

That's correct.
Basically, what happens in that in GUI mode, the ESC key is not recognized as 
META in org-mode (only as far as I can tell).

> I should also mention that Ubuntu (well Debian really) install a versino of 
> emacs which is customized and not stock-stnadard emacs. Also, my macOS 
> version of emcs is built using brew install and not brew cask install, so it 
> is built from the git repo and not using the macforosx binaries the cask 
> version uses. 

This morning I have installed emacs from macport (emacs-app-devel) and I've 
also built it from the repository (./configure with-ns).

In the locally build version Esc-Left promotes a header. But Esc-Right does not 
demote it, it only moves to the next word.

Macport emacs shows the same behavior as brew emacs: in GUI, Esc is not 
recognized as Meta.

Weird.

Jean-Christophe 

Re: [O] [org] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

> On May 31, 2017, at 7:28, Tim Cross  wrote:
> 
> Just add my confirmation that I have no issues with GUI bindings on either 
> MacOS Sierra with emacs 25.2 and org 9.0.7 or under Linux with Ubuntu 17.04 
> (same emacs and org versions). 

There were *some* people on help-emacs that could reproduce the issue on GTK+ 
and Xubuntu, I'm not saying it's everybody :)

> What happens if
> 
> 1. You use emacs -q and just load the version of org which is bundled with 
> emacs?

I've checked -Q with the bundled files and I get the same result.

> 2. you use emacs -q and just load latest org from elpa?

I always keep my packages up to date so I guess I have the latest package. I'll 
check.

Jean-Christophe 

[O] [org] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

> On May 30, 2017, at 21:21, Tim Visher <tim.vis...@gmail.com> wrote:
> 
> Sometimes your Terminal application captures these 'extended' bindings.

It is the opposite that's happening. Terminal works fine. It is the GUI that 
does not accept the bindings. And as I wrote, it is not limited to my macOS 
(Emacs.app and Aquamacs show the same behavior) but to other people's GTK+ 
linux or Xubuntu. So it seems that's something that aught to be investigated 
and eventually fixed.

> I've always just accepted that org mode keybindings differ between terminal 
> and gui.

Except that I don't *have* most bindings in GUI. There is probably a rational 
reason what that is happening. I'm fine with helping with the investigation but 
I fear that's an area where I can't do much more than that.

Jean-Christophe

> 
> On Tue, May 30, 2017 at 3:37 AM, Jean-Christophe Helary 
> <jean.christophe.hel...@gmail.com <mailto:jean.christophe.hel...@gmail.com>> 
> wrote:
> 
> > On May 30, 2017, at 15:51, Nicolas Goaziou <m...@nicolasgoaziou.fr 
> > <mailto:m...@nicolasgoaziou.fr>> wrote:
> >
> >> http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html 
> >> <http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html>
> >>
> >> Let me know if you need extra information.
> >
> > What happens if you replace, e.g.,
> >
> >  (org-defkey org-mode-map [(meta left)]  'org-metaleft)
> >
> > with
> >
> >  (org-defkey org-mode-map (kbd "M-")  'org-metaleft)
> >
> > in "org.el"?
> 
> Nothing changes.
> 
> Jean-Christophe
> 
> 

Re: [O] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

> On May 30, 2017, at 15:51, Nicolas Goaziou  wrote:
> 
>> http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html
>> 
>> Let me know if you need extra information.
> 
> What happens if you replace, e.g.,
> 
>  (org-defkey org-mode-map [(meta left)]  'org-metaleft)
> 
> with
> 
>  (org-defkey org-mode-map (kbd "M-")  'org-metaleft)
> 
> in "org.el"?

Nothing changes.

Jean-Christophe 

[O] different key binding between GUI emacs and emacs -nw

[Jean-Christophe Helary]

I've just filed a bug report on emacs and was advised to report it here too.

It's bug#27140.

Basically, when I start GUI emacs (macOS, but also Aquamacs, also reported in 
Xubuntu and GTK+/Linux), I don't get the default org-mode bindings. Only emacs 
-nw gets them.

Even if I start both with -Q, I get the exact same behavior: proper default key 
bindings for org-mode in emacs -nw, some bindings overridden in GUI emacs.

The discussion thread on help-gnu-emacs is here:

http://lists.gnu.org/archive/html/help-gnu-emacs/2017-05/msg00306.html

Let me know if you need extra information.

Jean-Christophe 

Re: [O] org compact guide texinfo bug ?

[Jean-Christophe Helary]

> 2016/04/09 5:53、Nicolas Goaziou <m...@nicolasgoaziou.fr> のメール：
> 
>> @itemx @key{TAB}
>> 
>> and
>> 
>> @itemx @key{RET}
>> 
>> are not subsequent entries of @item mouse-3 but entries on their own.
>> 
>> They should be coded as @item.
> 
> Fixed. Thank you.

Thank you very much !

Jean-Christophe Helary 

[O] org compact guide texinfo bug ?

[Jean-Christophe Helary]

It's my fist message to the list so I hope I'm not missing anything.

In section 10.4 "Commands in the agenda buffer" the View/Go to Org file 
commands are described as:

@tsubheading{View/Go to Org file}
@item mouse-3
@itemx @key{SPC}
Display the original location of the item in another window.
With prefix arg, make sure that the entire entry is made visible in the
outline, not only the heading.
@c
@itemx @key{TAB}
Go to the original location of the item in another window.  Under Emacs
22, @kbd{mouse-1} will also work for this.
@c
@itemx @key{RET}
Go to the original location of the item and delete other windows.
@c

According to the Texinfo documentation:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040itemx.html

It seems like:

@itemx @key{TAB}

and

@itemx @key{RET}

are not subsequent entries of @item mouse-3 but entries on their own.

They should be coded as @item.

Jean-Christophe Helary