Re: [O] Proposal: references from code to text.

[John Kitchin]

I believe you can do that with the Library of Babel (
https://orgmode.org/worg/org-contrib/babel/library-of-babel.html)

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Wed, May 16, 2018 at 7:58 PM, ZHUO QL (KDr2)  wrote:

>
> Hooray!
>
> Do we have a way to make that piece of code a predefined and callable code
> block that can be seen and called in any Org file?
>
> Greetings.
>
> ZHUO QL (KDr2, http://kdr2.com)
>
>
>
> On Wednesday, May 16, 2018, 10:26:41 PM GMT+8, John Kitchin <
> jkitc...@andrew.cmu.edu> wrote:
>
>
> * Main document
>
> See [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
> support two args]] (text to text) for notes about this function. The
> addition is done in line [[(add)]] (text to code).
>
> Here we put names on different kinds of elements so we can put them into a
> tangled file later.
>
> #+NAME: DOC-OF-ADD
> We use the function add to calculate the sum of two numbers.
>
> #+NAME: add-options
> - one
> - two
> - three
> - and of course "optional things"
>
>
> We use a block like this to get the contents of an org-element by name as
> a string, and possibly transform it some how, e.g. in this case I escape
> quotes. I guess you could also use an exporter to convert it to what ever
> form you want. You might bury this block at the end in an appendix so it
> isn't in the middle of your document like this.
>
> #+name: get-string
> #+BEGIN_SRC emacs-lisp :var name="add-options"
> (let ((el (org-element-map (org-element-parse-buffer)
> org-element-all-elements
> (lambda (el)
>   (when (string= (org-element-property :name el) name)
> el))
> nil t)))
>   (let ((s (buffer-substring (org-element-property :contents-begin el)
>  (org-element-property :contents-end el
> (replace-regexp-in-string "\\\"" "\"" s)))
> #+END_SRC
>
>
> Now, we can use those elements in a src-block like this.
>
> #+NAME: ADD
> #+BEGIN_SRC emacs-lisp -n -r :noweb yes :tangle test.el
> (defun add (x y)
>   "One line description of adding X and Y.
>   <> ;; code to code
>   <>"
>   ;; [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
> support two args]] code to text
>   (+ x y) (ref:add)
>   ;; it appears the coderef needs to be on it's own line, otherwise you
> get a org-link-search: No match for coderef: add when you click on the link.
>   )
> #+END_SRC
>
> #+RESULTS: ADD
> : add
>
> The above block tangles to this for me:
>
> #+BEGIN_SRC emacs-lisp
> (defun add (x y)
>   "One line description of adding X and Y.
>   We use the function add to calculate the sum of two numbers.
>;; code to code
>   - one
>   - two
>   - three
>   - and of course \"optional things\"
>   "
>   ;; [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
> support two args]] code to text
>   (+ x y)
>   ;; it appears the coderef needs to be on it's own line, otherwise you
> get a org-link-search: No match for coderef: add when you click on the link.
>   )
>
> #+END_SRC
>
>
> ** Notes
>
> *** There is a reason we only support two args
> :PROPERTIES:
> :ID:   BAD97113-3561-4A4A-BA07-0CD5BF6BA35F
> :END:
>
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
> On Wed, May 16, 2018 at 12:04 AM, ZHUO QL (KDr2)  wrote:
>
> Oh, that makes sense.
>
> So in this way, we must put the text into quotes, and then into a txt code
> block. And also we don't have a chance to do any transformation of the
> text(e.g. org-mode list to javadoc format).
>
> I think the direct reference from code to text is better. I will try to
> implement it, but I'm not very familiar with the code base and don't have
> much time, so I can't give any commitment. But once I have anything to
> show, I'll be back here  :)
>
> Greetings.
>
> ZHUO QL (KDr2, http://kdr2.com)
>
>
>
> On Tuesday, May 15, 2018, 6:05:31 PM GMT+8, Eric S Fraga <
> esfli...@gmail.com> wrote:
>
>
> On Tuesday, 15 May 2018 at 04:49, ZHUO QL (KDr2) wrote:
>
> > 2. The bug Eric just found while putting a <> link within
> > quotes, although, it may be easy to fix.
>
>
> I realised afterwards that it is not a bug but is a feature: org assumes
> that anything before the << start of the link should be repeated on each
> line of the incorporated src block.  This allows for easy incorporation
> of code into a comment block, e.g. for C or sh etc.
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b
>
>
>

Re: [O] Proposal: references from code to text.

[Samuel Wales]

interesting package!  but i'm not sure it would work with org as well
as org-link-minor-mode does.

On 5/16/18, John Kitchin  wrote:
> You might want to check out linkd: https://www.emacswiki.org/emacs/linkd.el
>
> It does a lot of what you describe independently of org-mode.
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
> On Wed, May 16, 2018 at 12:37 PM, Samuel Wales 
> wrote:
>
>> i'm not sure if i understand the goal.  is it babel-only?
>>
>> this email might be off-topic.
>>
>> what i want is links, using something like org-id,
>>
>>   - from non-org [for example, a link in file.el in a comment]
>>   - to non-org [for example, a named or id'ed location in the same file]
>>   - or to org [e.g. an org-id'ed org entry, or a named or id'ed
>> location in a babel block]
>>
>> that can be, if needed, effectively, bidirectional.  thus, you could
>> document a function in file.el using a subtree in main.org and bounce
>> between the function and the documentation because there is a link for
>> each.
>>
>> non-org [e.g. file.el] can be an original file [i.e. no babel
>> anywhere] or the result of tangling from babel.
>>
>> i find that org-link-minor-mode is /highly/ useful for the non-org
>> part of this, but it doesn't support all of the above functionality
>> automatically.
>>
>> i'd want a general package that is like org-link-minor-mode, but takes
>> care of supporting the user by creating good ids and links as needed.
>>
>> --
>> The Kafka Pandemic: 
>>
>> The disease DOES progress. MANY people have died from it. And ANYBODY
>> can get it at any time.
>>
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] Proposal: references from code to text.

[John Kitchin]

You might want to check out linkd: https://www.emacswiki.org/emacs/linkd.el

It does a lot of what you describe independently of org-mode.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Wed, May 16, 2018 at 12:37 PM, Samuel Wales  wrote:

> i'm not sure if i understand the goal.  is it babel-only?
>
> this email might be off-topic.
>
> what i want is links, using something like org-id,
>
>   - from non-org [for example, a link in file.el in a comment]
>   - to non-org [for example, a named or id'ed location in the same file]
>   - or to org [e.g. an org-id'ed org entry, or a named or id'ed
> location in a babel block]
>
> that can be, if needed, effectively, bidirectional.  thus, you could
> document a function in file.el using a subtree in main.org and bounce
> between the function and the documentation because there is a link for
> each.
>
> non-org [e.g. file.el] can be an original file [i.e. no babel
> anywhere] or the result of tangling from babel.
>
> i find that org-link-minor-mode is /highly/ useful for the non-org
> part of this, but it doesn't support all of the above functionality
> automatically.
>
> i'd want a general package that is like org-link-minor-mode, but takes
> care of supporting the user by creating good ids and links as needed.
>
> --
> The Kafka Pandemic: 
>
> The disease DOES progress. MANY people have died from it. And ANYBODY
> can get it at any time.
>

Re: [O] Manual: "ellipsis, special symbol", but no "ellipsis"

[Alain . Cochard]

Nicolas Goaziou writes on Wed 16 May 2018 21:04:

 >   "and =...= becomes a compact set of dots" refers to ellipsis.

Ah... Sorry, I was not aware of the typographical meaning of the word.
Thanks for the clarification.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106] | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France| Fax:   +33 (0)3 68 85 01 25 

[O] Bug: Spell checking language not set correctly when exporting to ODT [9.1.13 (9.1.13-elpa @ /home/christoph/.emacs.d/elpa/org-20180514/)]

[Christoph Michelbach]

When exporting an org document to ODT, the language used for spell checking is
always set to British English. The TOC's name is actually translated to the
language specified in the org document but the spell checking language is not
set correctly. It is particularly weird that it is set to British English
instead of American English because American English is the default pretty much
anywhere.

-- 
Christoph Michelbach 

Re: [O] Parsing of todo state log lines

[Michael Brand]

Hi Nicolas

On Wed, May 16, 2018 at 10:42 PM, Nicolas Goaziou
 wrote:

> I didn't test logging, but `org-skip-over-state-notes' definitely goes
> past the three items, so I guess `org-log-beginning' should put point at
> the end of the three items, too.

Indeed, it works all as expected. Thank you! (Sorry, my fault was that
the invalid example line with "" was not removed yet.)

Michael

Re: [O] Parsing of todo state log lines

[Nicolas Goaziou]

Michael Brand  writes:

> I still get the new log in the middle line with
> release_9.1.13-757-g463664b after restarting Emacs. Did you get the
> new log after the last line?

I didn't test logging, but `org-skip-over-state-notes' definitely goes
past the three items, so I guess `org-log-beginning' should put point at
the end of the three items, too.

Re: [O] Parsing of todo state log lines

[Michael Brand]

Hi

On Wed, May 16, 2018 at 10:08 PM, Nicolas Goaziou
 wrote:

> You are right. It should be empty, not "". I think I fixed it in maint.

I still get the new log in the middle line with
release_9.1.13-757-g463664b after restarting Emacs. Did you get the
new log after the last line?

Michael

Re: [O] Should org-complete-tags-always-offer-all-agenda-tags be documented in the manual? [was: Tag completion does not work well with ...]

[Nicolas Goaziou]

Hello,

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

> In general, though, I still feel it would make sense to document it,
> especially considering that other ways than the default are already
> documented.  Consider this excerpt from section "6.2 Setting tags":
>
>   Org supports tag insertion based on a _list of tags_.  By
>default this list is constructed dynamically, containing all tags
>currently used in the buffer.  You may also globally specify a hard
>list of tags with the variable ‘org-tag-alist’.  Finally you can
>set the default tags for a given file [...]
>
> One could have a footnote after "currently used in the buffer" which
> could be something like:
>
>One can have this list contain all tags used in all agenda files
>(see [[link to section "6.4 Tag searches"]]) by customizing
>variable org-complete-tags-always-offer-all-agenda-tags.

I have no objection to this, but why is the link to section "Tag
searches" on topic here?

Regards,

-- 
Nicolas Goaziou

Re: [O] Parsing of todo state log lines

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> I don't see this happen: When starting with this (the % and the
> ordering of the lines have been edited manually)
>
> - State "DONE"   from "TODO"   [2018-05-15 Tue 10:00]
> - State "DONE"   from "%"  [2018-05-15 Tue 10:00]
> - State "DONE"   from ""   [2018-05-15 Tue 10:00]
> - State "DONE"   from  [2018-05-15 Tue 10:00]
>
> and without todo keyword in the heading the logs change to
>
> - State "DONE"   from "TODO"   [2018-05-15 Tue 10:00]
> - State "DONE"   from "%"  [2018-05-15 Tue 10:00]
> - State "DONE"   from  [2018-05-16 Wed 21:45]
> - State "DONE"   from ""   [2018-05-15 Tue 10:00]
> - State "DONE"   from  [2018-05-15 Tue 10:00]
>
> So also "" is not recognized. And the new middle line is produced
> without "".

You are right. It should be empty, not "". I think I fixed it in maint.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [bug] in capture

[Nicolas Goaziou]

Hello,

Thomas Holst  writes:

> I have among other the following template:
>
> #+begin_src emacs-lisp
>   ("hr" "Rechnung erfassen" table-line
>    (file+function "~/git/org-priv/Univ_Beih.org" 
> th:capure-find-open-vers-regn)
>    "| # | %^u | %^{Arzt/Apotheke} | %^{fr wen|Lida|Oleg|Victor|Simon} 
> | %^{Betrag} | %^u | | [[file:%c][link Beleg]] |"
>    :table-line-pos "III-1" :immediate-finish t)
> #+end_src
>
> With org-mode from git I get an error when using this template:
>
> : condition-case: Capture template ‘hr’: integer-or-marker-p

I have too little information to reproduce the problem.

Could you provide a minimal example, i.e., no custom function like
`th:capure-find-open-vers-regn' and a minimal document where this table
line is going to be inserted.

Also, I would need the backtrace.

Thank you.

> Was there a change in the syntax I missed?

No, there wasn't.

Regards,

-- 
Nicolas Goaziou

Re: [O] Parsing of todo state log lines

[Michael Brand]

Hi Nicolas

On Wed, May 16, 2018 at 9:07 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Michael Brand  writes:
>
>> There seems to be an inconsistency in parsing. When
>> org-log-states-order-reversed is nil (which I am new to) and a TODO
>> with the manually written state log lines
>>
>> - State "DONE"   from "TODO"   [2018-05-12 Sat]
>> - State "DONE"   from  [2018-05-13 Sun]
>
> I think it should be
>
>   - State "DONE"   from ""   [whatever]
>
> according to `org-log-note-headings'.

I don't see this happen: When starting with this (the % and the
ordering of the lines have been edited manually)

- State "DONE"   from "TODO"   [2018-05-15 Tue 10:00]
- State "DONE"   from "%"  [2018-05-15 Tue 10:00]
- State "DONE"   from ""   [2018-05-15 Tue 10:00]
- State "DONE"   from  [2018-05-15 Tue 10:00]

and without todo keyword in the heading the logs change to

- State "DONE"   from "TODO"   [2018-05-15 Tue 10:00]
- State "DONE"   from "%"  [2018-05-15 Tue 10:00]
- State "DONE"   from  [2018-05-16 Wed 21:45]
- State "DONE"   from ""   [2018-05-15 Tue 10:00]
- State "DONE"   from  [2018-05-15 Tue 10:00]

So also "" is not recognized. And the new middle line is produced without "".

Michael

Re: [O] Parsing of todo state log lines

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> There seems to be an inconsistency in parsing. When
> org-log-states-order-reversed is nil (which I am new to) and a TODO
> with the manually written state log lines
>
> - State "DONE"   from "TODO"   [2018-05-12 Sat]
> - State "DONE"   from  [2018-05-13 Sun]

I think it should be

  - State "DONE"   from ""   [whatever]

according to `org-log-note-headings'.
  
Regards,

-- 
Nicolas Goaziou

Re: [O] Proposal: references from code to text.

[Samuel Wales]

i'm not sure if i understand the goal.  is it babel-only?

this email might be off-topic.

what i want is links, using something like org-id,

  - from non-org [for example, a link in file.el in a comment]
  - to non-org [for example, a named or id'ed location in the same file]
  - or to org [e.g. an org-id'ed org entry, or a named or id'ed
location in a babel block]

that can be, if needed, effectively, bidirectional.  thus, you could
document a function in file.el using a subtree in main.org and bounce
between the function and the documentation because there is a link for
each.

non-org [e.g. file.el] can be an original file [i.e. no babel
anywhere] or the result of tangling from babel.

i find that org-link-minor-mode is /highly/ useful for the non-org
part of this, but it doesn't support all of the above functionality
automatically.

i'd want a general package that is like org-link-minor-mode, but takes
care of supporting the user by creating good ids and links as needed.

-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

Re: [O] Manual: "ellipsis, special symbol", but no "ellipsis"

[Nicolas Goaziou]

Hello,

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

> Hello.  In the "Concept index", I see item "ellipsis, special
> symbol:", but, going there, I see no mention of "ellipsis", which I
> find strange.

#+cindex: shy hyphen, special symbol
#+cindex: dash, special symbol
#+cindex: ellipsis, special symbol
In addition to regular entities defined above, Org exports in
a special way[fn:110] the following commonly used character
combinations: =\-= is treated as a shy hyphen, =--= and =---= are
converted into dashes, and =...= becomes a compact set of dots.

There,

  "and =...= becomes a compact set of dots" refers to ellipsis.

Regards,

-- 
Nicolas Goaziou

Re: [O] Footnotes in the manual (hidden option?)

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> I would think that's so because canonically Org mode using [fn:1] style. It
> looks like you are manually typing the footnote refs and definitions.
>
> Try using C-c C-x f binding.. you will see that Org inserts the footnotes
> in the documented style.
>
> I would say that the "fn"-style footnotes remove any kind of
> ambiguity..

Moreover, [1]-like footnotes have been removed in 9.0. It's a bug if Org
thinks [1] is a footnote.

Regards,

-- 
Nicolas Goaziou

Re: [O] Footnotes in the manual (hidden option?)

[Kaushal Modi]

Hello,

On Wed, May 16, 2018 at 2:27 PM ST  wrote:

> Hello,
>
> in the manual
>
> https://orgmode.org/manual/Footnotes.html#Footnotes
>
> it says that footnotes[fn:1]
>
> [fn:1] look like this
>
>
> but actually[1]
>
> [1] works as well and looks even better.
>
> So why this option is not documented?
>

I would think that's so because canonically Org mode using [fn:1] style. It
looks like you are manually typing the footnote refs and definitions.

Try using C-c C-x f binding.. you will see that Org inserts the footnotes
in the documented style.

I would say that the "fn"-style footnotes remove any kind of ambiguity..
-- 

Kaushal Modi

[O] Footnotes in the manual (hidden option?)

[ST]

Hello,

in the manual

https://orgmode.org/manual/Footnotes.html#Footnotes

it says that footnotes[fn:1]

[fn:1] look like this


but actually[1] 

[1] works as well and looks even better.

So why this option is not documented?

Thank you!

[O] Manual: "ellipsis, special symbol", but no "ellipsis"

[Alain . Cochard]

Hello.  In the "Concept index", I see item "ellipsis, special
symbol:", but, going there, I see no mention of "ellipsis", which I
find strange.

Regards

-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106] | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France| Fax:   +33 (0)3 68 85 01 25 

Re: [O] Proposal: references from code to text.

[John Kitchin]

* Main document

See [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
support two args]] (text to text) for notes about this function. The
addition is done in line [[(add)]] (text to code).

Here we put names on different kinds of elements so we can put them into a
tangled file later.

#+NAME: DOC-OF-ADD
We use the function add to calculate the sum of two numbers.

#+NAME: add-options
- one
- two
- three
- and of course "optional things"


We use a block like this to get the contents of an org-element by name as a
string, and possibly transform it some how, e.g. in this case I escape
quotes. I guess you could also use an exporter to convert it to what ever
form you want. You might bury this block at the end in an appendix so it
isn't in the middle of your document like this.

#+name: get-string
#+BEGIN_SRC emacs-lisp :var name="add-options"
(let ((el (org-element-map (org-element-parse-buffer)
org-element-all-elements
(lambda (el)
  (when (string= (org-element-property :name el) name)
el))
nil t)))
  (let ((s (buffer-substring (org-element-property :contents-begin el)
 (org-element-property :contents-end el
(replace-regexp-in-string "\\\"" "\"" s)))
#+END_SRC


Now, we can use those elements in a src-block like this.

#+NAME: ADD
#+BEGIN_SRC emacs-lisp -n -r :noweb yes :tangle test.el
(defun add (x y)
  "One line description of adding X and Y.
  <> ;; code to code
  <>"
  ;; [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
support two args]] code to text
  (+ x y) (ref:add)
  ;; it appears the coderef needs to be on it's own line, otherwise you get
a org-link-search: No match for coderef: add when you click on the link.
  )
#+END_SRC

#+RESULTS: ADD
: add

The above block tangles to this for me:

#+BEGIN_SRC emacs-lisp
(defun add (x y)
  "One line description of adding X and Y.
  We use the function add to calculate the sum of two numbers.
   ;; code to code
  - one
  - two
  - three
  - and of course \"optional things\"
  "
  ;; [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
support two args]] code to text
  (+ x y)
  ;; it appears the coderef needs to be on it's own line, otherwise you get
a org-link-search: No match for coderef: add when you click on the link.
  )

#+END_SRC


** Notes

*** There is a reason we only support two args
:PROPERTIES:
:ID:   BAD97113-3561-4A4A-BA07-0CD5BF6BA35F
:END:


John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Wed, May 16, 2018 at 12:04 AM, ZHUO QL (KDr2)  wrote:

> Oh, that makes sense.
>
> So in this way, we must put the text into quotes, and then into a txt code
> block. And also we don't have a chance to do any transformation of the
> text(e.g. org-mode list to javadoc format).
>
> I think the direct reference from code to text is better. I will try to
> implement it, but I'm not very familiar with the code base and don't have
> much time, so I can't give any commitment. But once I have anything to
> show, I'll be back here  :)
>
> Greetings.
>
> ZHUO QL (KDr2, http://kdr2.com)
>
>
>
> On Tuesday, May 15, 2018, 6:05:31 PM GMT+8, Eric S Fraga <
> esfli...@gmail.com> wrote:
>
>
> On Tuesday, 15 May 2018 at 04:49, ZHUO QL (KDr2) wrote:
>
> > 2. The bug Eric just found while putting a <> link within
> > quotes, although, it may be easy to fix.
>
>
> I realised afterwards that it is not a bug but is a feature: org assumes
> that anything before the << start of the link should be repeated on each
> line of the incorporated src block.  This allows for easy incorporation
> of code into a comment block, e.g. for C or sh etc.
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b
>

[O] Should org-complete-tags-always-offer-all-agenda-tags be documented in the manual? [was: Tag completion does not work well with ...]

[Alain . Cochard]

Nicolas Goaziou writes on Fri  4 May 2018 23:44:

 > > Incidentally, shouldn't this variable be documented in the
 > > manual?  (Section "6.2 Setting tags" would seem a natural place
 > > for that.)  I had to resort to internet search...

 > I don't know specifically about this one, but not all variables can
 > be documented in the manual, there are too many of them.

Yes, I understand that. 

 > An alternate way to find about a variable is to explore Org
 > variables with
 > 
 >   M-x customize-group  org

Thanks for the reminder.  In my case, it would have been useful.

In general, though, I still feel it would make sense to document it,
especially considering that other ways than the default are already
documented.  Consider this excerpt from section "6.2 Setting tags":

  Org supports tag insertion based on a _list of tags_.  By
   default this list is constructed dynamically, containing all tags
   currently used in the buffer.  You may also globally specify a hard
   list of tags with the variable ‘org-tag-alist’.  Finally you can
   set the default tags for a given file [...]

One could have a footnote after "currently used in the buffer" which
could be something like:

   One can have this list contain all tags used in all agenda files
   (see [[link to section "6.4 Tag searches"]]) by customizing
   variable org-complete-tags-always-offer-all-agenda-tags.

Regards

-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106] | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France| Fax:   +33 (0)3 68 85 01 25 

[O] bug#31468: 24.5; org mode do not export current heading

[Robert Pluim]

Michel Damiens  writes:

[please keep the bug address in CC ]

> Hello
> my og-mode version is 9.1.13
> I'm not able to upgrade to emacs-26 for the moment : I'm not working on my
> own system.
> How do you think that sort of problem would depend on emacs version ?

Features and bugs can be very different between different emacs
versions. However, Iʼve just tried 9.1.13 on emacs-24, and I donʼt see
an issue, which suggests itʼs due to some local configuration Is it
possible for you to come up with a reproduction recipe starting from
'emacs -Q'?

Regards

Robert

Re: [O] Proposal: references from code to text.

[ZHUO QL (KDr2)]

Oh, that makes sense.
So in this way, we must put the text into quotes, and then into a txt code 
block. And also we don't have a chance to do any transformation of the 
text(e.g. org-mode list to javadoc format).  
I think the direct reference from code to text is better. I will try to 
implement it, but I'm not very familiar with the code base and don't have much 
time, so I can't give any commitment. But once I have anything to show, I'll be 
back here  :)
 Greetings.

ZHUO QL (KDr2, http://kdr2.com)

 

   On Tuesday, May 15, 2018, 6:05:31 PM GMT+8, Eric S Fraga 
 wrote: 
 
 On Tuesday, 15 May 2018 at 04:49, ZHUO QL (KDr2) wrote:
> 2. The bug Eric just found while putting a <> link within
> quotes, although, it may be easy to fix. 

I realised afterwards that it is not a bug but is a feature: org assumes
that anything before the << start of the link should be repeated on each
line of the incorporated src block.  This allows for easy incorporation
of code into a comment block, e.g. for C or sh etc.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b