Re: [O] Typo org-switchb org-iswitchb

[Bastien]

"Th. Rikl"  writes:

> Newest ... The manual and the guide talk about "org-iswitchb", the
> code contains only "org-switchb".

Fix, thanks!

-- 
 Bastien

[O] Patch for documentation standards

[Thomas S. Dye]

Aloha all,

A lightly edited and augmented version of the Org documentation 
standards is attached.


All the best,
Tom

>From 010294deec9d35217bdc991bec55a80ab0f40853 Mon Sep 17 00:00:00 2001
From: "Thomas S. Dye" 
Date: Sat, 3 Mar 2018 16:06:27 -1000
Subject: [PATCH] Update documentation standards

---
 doc/Documentation_Standards.org | 57 ++---
 1 file changed, 37 insertions(+), 20 deletions(-)

diff --git a/doc/Documentation_Standards.org b/doc/Documentation_Standards.org
index 357520b9f..f1495d2e8 100644
--- a/doc/Documentation_Standards.org
+++ b/doc/Documentation_Standards.org
@@ -34,7 +34,7 @@ used in the patches I am submitting and, which I hope, may be adopted by
 others when making their own contributions.
 
 * Org - Referencing systems, packages, modes and much else
- 
+
 Originally Org was a single mode and there was no ambiguity about what
 Org mode could refer to.  Things have changed rapidly though and it
 seems that Carsten now thinks of Org as the system encompassing the
@@ -49,7 +49,7 @@ perfect, merely a start):
applicable to Org as a whole.
 
  - Be more specific and write, for example, "the Orgtbl minor mode" when
-   referring to something unique to that feature.  It maybe, for example,
+   referring to something unique to that feature.  It may be, for example,
a command is only available when you are actually editing a file using
just that mode, add-on package or plug-in.
 
@@ -67,7 +67,7 @@ perfect, merely a start):
 
 * Other Org specific conventions
 
-Unless there is a good reason to do otherwise then try and adopt the
+Unless there is a good reason to do otherwise, then try and adopt the
 following conventions.  (I think all can be justified by reference to
 Carsten or precedent in other significant Emacs documentation...unless I
 have made them up of course).
@@ -89,36 +89,53 @@ have made them up of course).
lowercase.
 
  - Built-in properties (eg PRIORITY) are written in uppercase.  User defined
-   properties (eg Release) are written in lowercase.
+   properties (e.g. Release) are written in lowercase.
 
- - [[info:org:Top][The Org Manual]] uses the @chapter, @section and @subsection Texinfo
-   commands for sectioning.  I have tried to capitalize significant words
-   in @chapter headings.  In @section and @subsection headings, just the
+ - [[info:org:Top][The Org Manual]] capitalizes significant words
+   in first level headings.  In second and third level headings, just the
first word is capitalized and all other words are lowercase (with
exceptions of course...).  Thus, use:
 
-   @chapter Properties and Columns
+   * Properties and Columns
 
-   @section Visibility cycling
+   ** Visibility cycling
 
*but*
 
-   @section Fast access to TODO states
+   ** Fast access to TODO states
 
 * Miscellaneous
 
- - Only two of the standard Texinfo indexes are used; those for concepts
-   and keys.  This has some implications:
+ - Five of the standard Texinfo indexes are used in the Org manual:
+
+   + #+cindex: :: concept index, for general concepts
+
+   + #+findex:  :: function index, for function and function-like names
+
+   + #+kindex: :: keystroke index, for keyboard commands
+
+   + #+pindex: :: program index, for names of programs
+
+   + #+vindex: :: variable index, for variable names
+
+ - Entries in the concept index are normally all lower case unless
+   some other rule dictates otherwise
+
+ - use fixed-width area for one-line examples
+
+ - use example blocks for Org syntax instead of "begin_src org"
+
+ - internal links to headlines always start with a star
+
+ - tags, node properties, are not shown with the surrounding colons
+
+ - when to use =...= or ~...~ markup:
+
+   - files or extensions use =...=,
 
-   + The preference is to document commands by key rather than by name
+   - anything that is meant to be written in the Org buffer uses =...=,
 
-   + Texinfo commands such as @var and @defoption are not used.  The
- preference for this type of thing is that the user browses the
- customize groups.  If you want or need to refer to, say, a variable
- then document it as "the variable @code{org-startup-folded}"
- 
-   + Entries in the concept index are normally all lower case unless
- some other rule dictates otherwise.
+   - any meaningful token in a programming language uses ~...~.
 
  - Org documentation is written in American English, which is somewhat
foreign as far as I am concerned, but live with it anyway.
-- 
2.14.1



--
Thomas S. Dye
http://www.tsdye.com

[O] Bug: Mode line face is not updated when clock overruns [9.1.7 (release_9.1.7-466-ga16590.dirty @ /home/luke/elisp/org-mode/lisp/)]

[Luke]

The face of the clocked time does not seem to change when the clock 
overruns (typically it changes to a red background).


I'm no lisp expert, but after digging around in the code it looks like 
the problem is in org-clock-get-clock-string():


662 (defun org-clock-get-clock-string ()
663   "Form a clock-string, that will be shown in the mode line.
664 If an effort estimate was defined for the current item, use
665 01:30/01:50 format (clocked/estimated).
666 If not, show simply the clocked time like 01:50."
667   (let ((clocked-time (org-clock-get-clocked-time)))
668 (propertize
669  (if org-clock-effort

...

683  'face 'org-mode-line-clock)))

It seems like the call to propertize (on line #668) is overwriting the 
face ('org-mode-line-clock-overrun) of the resulting string with 
'org-mode-line-clock. I think this change was introduced in commit 
6655429b8d.



Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-21 on lcy01-07, modified by Debian
Package: Org mode version 9.1.7 (release_9.1.7-466-ga16590.dirty @ 
/home/luke/elisp/org-mode/lisp/)

Re: [O] Bug: org-capture inserts empty line before title

[Luke]

Hi,


On 04/03/18 06:40, Nicolas Goaziou wrote:

Hello,

Luke  writes:


org-capture seems to be inserting an extra line before the task
heading. So the narrowed buffer for editing the task looks something
like this:

 Top of window ---

** TODO My new task
[2018-03-02 Fri]
[[file:~/.notes]]
 End of buffer ---

I would expect the task heading to be the first line in the buffer.
After pressing 'C-c C-c' the resulting file looks like this:

--
* Tasks

** TODO My new task
[2018-03-02 Fri]
[[file:~/.notes]]
--

Is this a bug? If not, how do I stop the blank line from being
inserted before the heading. As far as I can tell, this is not related
to org-blank-before-new-entry.

Could you show the capture template you used? I do not notice anything
like that with my templates.

Regards,


I've set up a minimal-org.el file with the following contents:

    ;; Minimal setup to load latest 'org-mode'

    ;; activate debugging
    (setq debug-on-error t
          debug-on-signal nil
      debug-on-quit t)

    ;; add latest org-mode to load path
    (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
    (add-to-list 'load-path (expand-file-name 
"~/elisp/org-mode/contrib/lisp" t))


Then I've run emacs with `emacs -Q -l minimal-org.el`. So I'm just 
running the with org-mode default capture template, which (taken from 
org-capture.el) would be:


    ("t" "Task" entry (file+headline "" "Tasks")
 "* TODO %?\n  %u\n  %a")

Re: [O] Automatic tangling/detangling

[Diego Zamboni]

Interesting! I didn’t know about org-babel-detangle. I’d be very interested in 
what you come up with. I’ll try to do some exploration on my own as well.

Best,
—Diego

> On 3 Mar 2018, at 22:50, Matthew Bauer  wrote:
> 
> Yes, detangling works okay for me. I just setup properties like this:
> 
> * Emacs Init file
> :PROPERTIES:
> :header-args: :tangle yes :comments link
> :END:
> 
> ...etc.
> 
> And you can open the generated file and run "org-babel-detangle" when
> you are done editing it.
> 
> I guess I'm interesting in finding some "smarter" ways to do this.
> Using 'append' might work better than what I have. I'm also looking in
> to doing some sort of "async" usage (using some checks so multiple
> tangles don't run at once).
> 
> I wonder if there's an easy way to setup "locks" in Emacs so you can
> only edit one file at a time (kind of like how auto revert works).
> Still researching all of this.
> 
> On Sat, Mar 3, 2018 at 10:47 AM, Diego Zamboni  wrote:
>> Hi Matthew,
>> 
>> How do you do the untangling? I have been using an after-hook call to
>> org-babel-tangle, which works quite well. It is a bit slow for large files
>> with many code segments (like my Emacs init file at
>> https://github.com/zzamboni/dot-emacs/blob/master/init.org), and it requires
>> a bit of discipline for editing only the org file and not the output file,
>> but works well otherwise. I have never tried to de-tangle, that would
>> require some markers in the output file I guess?
>> 
>> Here’s the code I use at the moment I am super happy with it, as it prevents
>> my output files to get out of sync from the org file:
>> 
>> (add-hook 'org-mode-hook
>>  (lambda () (add-hook 'after-save-hook 'org-babel-tangle
>>   'run-at-end 'only-in-org-mode)))
>> 
>> 
>> Best,
>> —Diego
>> 
>> On 3 Mar 2018, at 04:38, Matthew Bauer  wrote:
>> 
>> Is there any good way to automatically tangle Org files and detangle tangled
>> files? I frequently use this workflow but they often get out of sync. I have
>> tried adding an after-save-hook but it’s too slow to be useful. Something
>> like auto revert mode might work better...
>> 
>> Anyone have solutions for this?
>> 
>> -Matthew Bauer
>> 
>> 

Re: [O] Bug: org-capture inserts empty line before title

[Nicolas Goaziou]

Hello,

Luke  writes:

> org-capture seems to be inserting an extra line before the task
> heading. So the narrowed buffer for editing the task looks something
> like this:
>
>  Top of window ---
>
> ** TODO My new task
>[2018-03-02 Fri]
>[[file:~/.notes]]
>  End of buffer ---
>
> I would expect the task heading to be the first line in the buffer.
> After pressing 'C-c C-c' the resulting file looks like this:
>
> --
> * Tasks
>
> ** TODO My new task
>[2018-03-02 Fri]
>[[file:~/.notes]]
> --
>
> Is this a bug? If not, how do I stop the blank line from being
> inserted before the heading. As far as I can tell, this is not related
> to org-blank-before-new-entry.

Could you show the capture template you used? I do not notice anything
like that with my templates.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: org-gnus-store-link wrong if used from article buffer when point moved in summary [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.3/lisp/org/)]

[Nicolas Goaziou]

Hello,

Kevin Brubeck Unhammer  writes:

> If you open an article in Gnus, then move the point away from the
> summary line of that article in the Summary buffer, then go back to the
> Article buffer and M-x org-store-link, it will link to the article
> you're pointing at in the Summary, not the article in the Article
> buffer.
>
> The issue is at line 145 in
> https://code.orgmode.org/bzg/org-mode/raw/master/lisp/org-gnus.el
> which does
>
>   (header (with-current-buffer gnus-summary-buffer
> (gnus-summary-article-header)))
>
> (I'm running 8.2.10 normally, but I've tried the most recent org-gnus.el
> and it's the same, and the code makes it clear why.)
>
> In my own code I use the following workaround:
>
>   (if (eq major-mode 'gnus-article-mode)
>   (save-window-excursion (gnus-article-show-summary)
>  (org-store-link nil))
> (org-store-link nil))
>
> although someone with knowledge of gnus internals might be able to avoid
> the call to (gnus-configure-windows 'article) that changes the window
> configuration. (Or maybe org-mode should simply use the above workaround
> since that assumes less about gnus internals, which might change more
> than its public API.)

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Automatic tangling/detangling

[Matthew Bauer]

Yes, detangling works okay for me. I just setup properties like this:

* Emacs Init file
:PROPERTIES:
:header-args: :tangle yes :comments link
:END:

...etc.

And you can open the generated file and run "org-babel-detangle" when
you are done editing it.

I guess I'm interesting in finding some "smarter" ways to do this.
Using 'append' might work better than what I have. I'm also looking in
to doing some sort of "async" usage (using some checks so multiple
tangles don't run at once).

I wonder if there's an easy way to setup "locks" in Emacs so you can
only edit one file at a time (kind of like how auto revert works).
Still researching all of this.

On Sat, Mar 3, 2018 at 10:47 AM, Diego Zamboni  wrote:
> Hi Matthew,
>
> How do you do the untangling? I have been using an after-hook call to
> org-babel-tangle, which works quite well. It is a bit slow for large files
> with many code segments (like my Emacs init file at
> https://github.com/zzamboni/dot-emacs/blob/master/init.org), and it requires
> a bit of discipline for editing only the org file and not the output file,
> but works well otherwise. I have never tried to de-tangle, that would
> require some markers in the output file I guess?
>
> Here’s the code I use at the moment I am super happy with it, as it prevents
> my output files to get out of sync from the org file:
>
> (add-hook 'org-mode-hook
>   (lambda () (add-hook 'after-save-hook 'org-babel-tangle
>'run-at-end 'only-in-org-mode)))
>
>
> Best,
> —Diego
>
> On 3 Mar 2018, at 04:38, Matthew Bauer  wrote:
>
> Is there any good way to automatically tangle Org files and detangle tangled
> files? I frequently use this workflow but they often get out of sync. I have
> tried adding an after-save-hook but it’s too slow to be useful. Something
> like auto revert mode might work better...
>
> Anyone have solutions for this?
>
> -Matthew Bauer
>
>

Re: [O] Feature suggestion and code review request: org-babel-cycle-src-block-header

[Thorsten Jolitz]

Thorsten Jolitz  writes:

PS
One more to show that one can not only easily modify a certain
org element, but that its just as easy to convert it to another type of
org element.

Use this (call M-x tj/obch)

#+BEGIN_SRC emacs-lisp  
(defun tj/obch () 
  "docstring"
  (interactive)
  (org-dp-rewire 'example-block t t ;cont ins
 '(:caption (("val2" "key2") ("val2" "key2"))
:attr_xyz ("val1" "val2")) ;aff 
 nil ;elem 
 :language "common-lisp"
 :switches '(lambda (old elem) old )
 :parameters 'tj/toggle-params
 :value '(lambda (old elem)
   (let ((old1 
  (string-remove-suffix "\n" old)))
 (concat "(+ 3 " old1 " 17)\n")))
 :preserve-indent '(lambda (old elem) old ) ) )
#+END_SRC

with point on this source block header 

,
| * test
| 
| #+NAME: test1
| #+BEGIN_SRC emacs-lisp :tangle yes :results none
|   (+ 1 1)
| #+END_SRC
`

to get this

,
| #+NAME: test1
| #+CAPTION[key2]: val2
| #+CAPTION[key2]: val2
| #+ATTR_XYZ: val2
| #+ATTR_XYZ: val1
| #+BEGIN_EXAMPLE
| (+ 3 (+ 1 1) 17)
| #+END_EXAMPLE
`




> John Kitchin  writes:
>
> Hallo,
>
>> This is a neat idea. 
>
> This is quite a nice use/show case for org-dp too.
>
> I did not really try to solve the users feature request, just wanted to
> demonstrate how different a possible solution looks using declarative
> programming, leaving all the low-level parsing and interpreting work to
> the org-element framework.
>
> 1. Example org-mode buffer
>
> ,
> | * test
> | 
> | #+NAME: test1
> | #+BEGIN_SRC emacs-lisp :tangle yes :results none
> |   (+ 1 1)
> | #+END_SRC
> | 
> | #+NAME: test2
> | #+BEGIN_SRC picolisp :tangle no :results raw
> |   (+ 2 2)
> | #+END_SRC
> `
>
> 2. Elisp to toggle the parameter values
>
> The org-dp part is this. 
>
> Call the mapping cmd (M-x tj/obch-map) in the buffer (act on all
> src-blocks), or put point on a src-block header and call M-x tj/obch to
> just act on that scr-block.
>
> ,
> | (defun tj/obch () 
> |   "docstring"
> |   (interactive)
> |   (org-dp-rewire 'src-block t t ;cont ins
> |  t ;aff 
> |  nil ;elem 
> |  :language '(lambda (old elem) old )
> |  :switches '(lambda (old elem) old )
> |  :parameters 'tj/toggle-params
> |  :value '(lambda (old elem) old )
> |  :preserve-indent '(lambda (old elem) old ) ) )
> | 
> | 
> | (defun tj/obch-map ()
> |   "docstring"
> |   (interactive)
> |   (org-dp-map '(tj/obch) "#\\+BEGIN_SRC"))
> ` 
>
> You can play around with the other args to org-dp-rewire (apart from
> :parameters) to find out how easy you can change (or remove/add) other
> parts of the src-block without any work on the textual representation.
>
> E.g. try this:
>
> #+BEGIN_SRC emacs-lisp  
> (defun tj/obch () 
>   "docstring"
>   (interactive)
>   (org-dp-rewire 'src-block t t ;cont ins
>nil ;aff 
>nil ;elem 
>:language "common-lisp"
>:switches '(lambda (old elem) old )
>:parameters 'tj/toggle-params
>:value '(lambda (old elem)
>  (let ((old1 
> (string-remove-suffix "\n" old)))
>  (concat "(+ 3 " old1 " 17)\n")))
>:preserve-indent '(lambda (old elem) old ) ) )
> #+END_SRC
>
>
> to see this result in the example buffer after calling M-x tj/obch-map:
>
> ,
> | * test
> | 
> | #+BEGIN_SRC common-lisp :tangle no :results raw
> |   (+ 3 (+ 1 1) 17)
> | #+END_SRC
> | 
> | #+BEGIN_SRC common-lisp :tangle yes :results none
> |   (+ 3 (+ 2 2) 17)
> | #+END_SRC
> `
>
> PS
> Here is the whole code.
> The logic in 'tj/toggle-params is not really of interest here. The
> important thing is, that all of these options are possible:
>
> - simply assign a value
> - implement a lambda function in place (with two args)
> - implement a named function (with two args) and use its name
>
> ,
> | :parameters ":tangle no"
> | :parameters '(lambda (old elem) (concat old " :results none") )
> | :parameters 'tj/toggle-params
> `
>
> #+BEGIN_SRC emacs-lisp  
> (defvar tj/change-p)
>
> ;; org-dp in action
> ;; wrap org-dp-rewire in utility cmd for readability
> (defun tj/obch () 
>   "docstring"
>   (interactive)
>   (org-dp-rewire 'src-block t t ;cont ins
>t ;aff 
>nil ;elem 
>:language '(lambda (old elem) old )
>:switches '(lambda (old elem) old )
>:parameters 'tj/toggle-params
>:value '(lambda (old elem) old )
>:preserve-indent '(lambda (old elem) old ) ) )
>
>
> (defun tj/obch-map ()
>   "docstring"
>   (interactive)
>   (org-dp-map '(tj/obch) 

Re: [O] Feature suggestion and code review request: org-babel-cycle-src-block-header

[Thorsten Jolitz]

John Kitchin  writes:

Hallo,

> This is a neat idea. 

This is quite a nice use/show case for org-dp too.

I did not really try to solve the users feature request, just wanted to
demonstrate how different a possible solution looks using declarative
programming, leaving all the low-level parsing and interpreting work to
the org-element framework.

1. Example org-mode buffer

,
| * test
| 
| #+NAME: test1
| #+BEGIN_SRC emacs-lisp :tangle yes :results none
|   (+ 1 1)
| #+END_SRC
| 
| #+NAME: test2
| #+BEGIN_SRC picolisp :tangle no :results raw
|   (+ 2 2)
| #+END_SRC
`

2. Elisp to toggle the parameter values

The org-dp part is this. 

Call the mapping cmd (M-x tj/obch-map) in the buffer (act on all
src-blocks), or put point on a src-block header and call M-x tj/obch to
just act on that scr-block.

,
| (defun tj/obch () 
|   "docstring"
|   (interactive)
|   (org-dp-rewire 'src-block t t ;cont ins
|t ;aff 
|nil ;elem 
|:language '(lambda (old elem) old )
|:switches '(lambda (old elem) old )
|:parameters 'tj/toggle-params
|:value '(lambda (old elem) old )
|:preserve-indent '(lambda (old elem) old ) ) )
| 
| 
| (defun tj/obch-map ()
|   "docstring"
|   (interactive)
|   (org-dp-map '(tj/obch) "#\\+BEGIN_SRC"))
` 

You can play around with the other args to org-dp-rewire (apart from
:parameters) to find out how easy you can change (or remove/add) other
parts of the src-block without any work on the textual representation.

E.g. try this:

#+BEGIN_SRC emacs-lisp  
(defun tj/obch () 
  "docstring"
  (interactive)
  (org-dp-rewire 'src-block t t ;cont ins
 nil ;aff 
 nil ;elem 
 :language "common-lisp"
 :switches '(lambda (old elem) old )
 :parameters 'tj/toggle-params
 :value '(lambda (old elem)
   (let ((old1 
  (string-remove-suffix "\n" old)))
   (concat "(+ 3 " old1 " 17)\n")))
 :preserve-indent '(lambda (old elem) old ) ) )
#+END_SRC

to see this result in the example buffer after calling M-x tj/obch-map:

,
| * test
| 
| #+BEGIN_SRC common-lisp :tangle no :results raw
|   (+ 3 (+ 1 1) 17)
| #+END_SRC
| 
| #+BEGIN_SRC common-lisp :tangle yes :results none
|   (+ 3 (+ 2 2) 17)
| #+END_SRC
`

PS
Here is the whole code.
The logic in 'tj/toggle-params is not really of interest here. The
important thing is, that all of these options are possible:

- simply assign a value
- implement a lambda function in place (with two args)
- implement a named function (with two args) and use its name

,
| :parameters ":tangle no"
| :parameters '(lambda (old elem) (concat old " :results none") )
| :parameters 'tj/toggle-params
`


#+BEGIN_SRC emacs-lisp  
(defvar tj/change-p)

;; org-dp in action
;; wrap org-dp-rewire in utility cmd for readability
(defun tj/obch () 
  "docstring"
  (interactive)
  (org-dp-rewire 'src-block t t ;cont ins
 t ;aff 
 nil ;elem 
 :language '(lambda (old elem) old )
 :switches '(lambda (old elem) old )
 :parameters 'tj/toggle-params
 :value '(lambda (old elem) old )
 :preserve-indent '(lambda (old elem) old ) ) )


(defun tj/obch-map ()
  "docstring"
  (interactive)
  (org-dp-map '(tj/obch) "#\\+BEGIN_SRC"))

;; helper functions for this use case, not really of interest
;; toggle src-block parameter values
(defun tj/toggle-params (old elem)
  "docstring"
  (let* ((params-lst (split-string old)))
(setq tj/change-p nil)
(mapconcat 'tj/replace-vals params-lst " ")) )

;; helper functon to actually replace old with new values
(defun tj/replace-vals (strg)
  "docstring"
  (let (res)
(if tj/change-p
(progn
  (cond 
   ((string-equal strg "yes")
(setq res "no"))
   ((string-equal strg "no")
(setq res "yes"))
   ((string-equal strg "none")
(setq res "raw"))
   ((string-equal strg "raw")
(setq res "none")) )
  (setq tj/change-p nil)
  res)
  (cond
   ((string-equal strg ":tangle")
(setq tj/change-p t))
   ((string-equal strg ":results")
(setq tj/change-p t)))
  strg)))
#+END_SRC


> I sometimes want to switch to silent, or between
> value and results. I don't know if you would consider the code below an
> improvement, but it seems to do what you want, and is shorter. It has
> less checking of things, and is more of a replace the header kind of
> approach.
>
> Personally, I think strings are the way to go here.
>
> #+BEGIN_SRC emacs-lisp :tangle yes :results none
> (require 's)
> (require 'dash)
>
> (defvar header-sequences '((emacs-lisp . (":tangle no :results none" ;;
> type 2 above
> 

Re: [O] [RFC] Moving "manual.org" into core

[Glenn Morris]

I'm sure this is an impressive technical achievement, but can I urge you
to raise this on emacs-devel first, because I think it's potentially
problematic.

I'm not entirely sure what you are proposing here. If the .org version
will become the "preferred form" for modification, it would eg need to
be in the Emacs repository (when the time comes), with suitable Makefile
rules for generating the final products from it, and distributed
correctly in releases. Emacs has got into trouble before in this area.

Bastien Guerry wrote:

> One of my worries was that moving toward editing a manual in .org
> does not match GNU developers good practices and habits, which are
> to edit .texi files.  But as long as the .texi file exists I guess
> we can shake the habits by allowing to edit .org files, which are
> more convenient to read and write.

Speaking for myself, I don't want to learn yet another markup syntax for
one single Emacs manual. I find it unlikely that GNU projects will start
requiring Emacs to build their documentation. Although the GNU coding
standards do say:

https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals

Nowadays some other formats such as Docbook and Sgmltexi can be
converted automatically into Texinfo. It is ok to produce the Texinfo
documentation by conversion this way, as long as it gives good results. 

so there's no problem from that aspect.

> But still: RMS recently raised the question on emacs-devel of
> whether using .rst for the GNU documentation would be better,
> so using .org for this purpose is not entirely hypothetical.

On the subject of rst, I can only find a topic two years ago that went
nowhere, and note in particular this:

http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00667.html

   "We don't want to replace Texinfo as the source language"


Maybe I'm worried about nothing, but I do suggest asking on emacs-devel.

Re: [O] is there a macro to have backend-specific behavior?

[Adonay Felipe Nogueira]

> Is there a way to define a macro that has different behaviors depending
> on export backend? I have macros that use the @@latex:foo@@ syntax, but
> in that case I "foo" is supposed to be literal latex.

Perhaps this might do something similar  to what you expect:

--8<---cut here---start->8---
#+macro: make-hyperlink-to-custom-id (eval (cond ((org-export-derived-backend-p 
org-export-current-backend 'html) (concat "[[file:" (buffer-file-name) 
":$1]]")) ((org-export-derived-backend-p org-export-current-backend 'latex) 
"[[$1]]") (t "[[$1]]")))
--8<---cut here---end--->8---

It could have been shorter, some other people might be able to help out.

There is a flaw though, since the branch from the 'html conditional
returns an absolute path, and I don't know if this is what you want, and
it of course refers to the Org mode original document as you asked ---
that is: it won't link to the object in the HTML that actually has that
custom identity.

I hope this helps.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: [O] Automatic tangling/detangling

[Diego Zamboni]

Hi Matthew,

How do you do the untangling? I have been using an after-hook call to 
org-babel-tangle, which works quite well. It is a bit slow for large files with 
many code segments (like my Emacs init file at 
https://github.com/zzamboni/dot-emacs/blob/master/init.org 
), and it requires 
a bit of discipline for editing only the org file and not the output file, but 
works well otherwise. I have never tried to de-tangle, that would require some 
markers in the output file I guess?

Here’s the code I use at the moment I am super happy with it, as it prevents my 
output files to get out of sync from the org file:

(add-hook 'org-mode-hook
  (lambda () (add-hook 'after-save-hook 'org-babel-tangle
   'run-at-end 'only-in-org-mode)))

Best,
—Diego

> On 3 Mar 2018, at 04:38, Matthew Bauer  wrote:
> 
> Is there any good way to automatically tangle Org files and detangle tangled 
> files? I frequently use this workflow but they often get out of sync. I have 
> tried adding an after-save-hook but it’s too slow to be useful. Something 
> like auto revert mode might work better...
> 
> Anyone have solutions for this?
> 
> -Matthew Bauer

Re: [O] emacs laggs with saving clipboard to X clipboard manager

[Grégoire Jadi]

Joseph Vidal-Rosset  writes:

> Hello everybody,
>
> I apologize,  I know  that this  topic is org-mode  specific, but  it is
> related to emacs.
>
> My problem is exactly the same that is explained here :
> [[https://github.com/syl20bnr/spacemacs/issues/9691]]
> and my OS  is the same (Gnu Linux  Debian 9).  I do not  succeed to find
> the solution,  knowing that I need  to copy and paste  in emacs elements
> that are outside emacs.
>
> Your help is welcome. 

FWIW, this is a known issue.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29170

I use the same workaround a S. Fraga:
: (setq x-selection-timeout 10)

Best,



signature.asc
Description: PGP signature

Re: [O] [RFC] Moving "manual.org" into core

[Joseph Vidal-Rosset]

Le sam. 03 mars 2018 à  04:57:33 , Bastien Guerry  a envoyé
ce message:
> The rationale for using org.org (which, I agree, sounds a bit
> childish) is that this is the current convention for naming GNU
> manual is [package-name].[extension].
>
> See emacs.texi, gnus.texi, calc.texi, etc.
>
> If using Org becomes popular, it makes sense to have emacs.org,
> gnus.org, calc.org but I find emacs-manual.org, gnus-manual.org
> calc-manual.org to be cumbersome.
>
> Ok, we're not there yet, I know :)
>
> But still: RMS recently raised the question on emacs-devel of
> whether using .rst for the GNU documentation would be better,
> so using .org for this purpose is not entirely hypothetical.
>
> What people think?  Let's just collect votes on this.
>
> +1 for org.org

I agree. An  expression that is both justified by  a convention and that
sounds silly  or childish, is  like a slogan  that everybody has  fun to
repeat: "org.org" is terrific !

+1 for org.org

Jo. 

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> I don't understand this part. Currently, "manual.org" is exported as
> "org.texi" per
>
>   #+export_file_name: org.texi
>
> So we are getting the best of both worlds. Am I missing something?

No, I was missing the "#+export_file_name: org.texi" part.

>> Or org-manual.org, which seems more readable.
>
> I think "manual.org" is simpler, but I do not mind renaming it to
> "org-manual.org". However, I find "org.org" silly.
>
> In any case, I let you decide the name before moving forward.

I don't have a strong opinion on this.

The rationale for using org.org (which, I agree, sounds a bit
childish) is that this is the current convention for naming GNU
manual is [package-name].[extension].

See emacs.texi, gnus.texi, calc.texi, etc.

If using Org becomes popular, it makes sense to have emacs.org,
gnus.org, calc.org but I find emacs-manual.org, gnus-manual.org
calc-manual.org to be cumbersome.

Ok, we're not there yet, I know :)

But still: RMS recently raised the question on emacs-devel of
whether using .rst for the GNU documentation would be better,
so using .org for this purpose is not entirely hypothetical.

What people think?  Let's just collect votes on this.

+1 for org.org

-- 
 Bastien

Re: [O] question on org-element-interpret-data and when it works

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Thorsten Jolitz  writes:
>
>> You used the word 'discrepancy',
>
> True. I inferred it from
>
>   (funny enough, some org elements have 'value' as their content, others
>   'content').
>
> which, IMO, sounds like it is a surprising fact.
>
>> I simply needed to know for each org
>> element what is interpreted and what not. And some have a content,
>> others a :value.
>
> As in every AST, some nodes are terminal (no contents), and some are not
> (contents).
>
> This distinction is made in `org-element-greater-elements', i.e.,
> non-terminal elements. See also `org-element-recursive-objects' for
> non-terminal objects.
>
>> So if I pass 'Hello World' as content to an example
>> block, nothing happens, if I pass it via :value, it appears as the
>> blocks ... well, content.
>
> Contents imply Org syntax. This would defeat the purpose of an example
> block.

Ok, so its just a matter of wording.  

On the computer science side of things, content seems to be org elements
or objects contained in other org elements (like table rows in a table),
and on the laymans side of things the text inside of an example block
looks very much like the blocks content too (while its technically named
'value' in this case).

-- 
cheers,
Thorsten

Re: [O] Exploring picolisp

[Thorsten Jolitz]

Lawrence Bottorff  writes:


Hi Lawrence,

> I'm looking at picolisp -- and wondering how it works, or better, why it
> doesn't really work work with babel. First problem, I couldn't get any
> form of picolisp to work in Emacs -- until I stopped starting Emacs with
> [...]
> I don't mean to complain or sound negative, but picolisp as is can't
> really be included as a babel language, can it? Maybe it worked once,
> but doesn't now?

sometimes the bug actually sits in front of the computer, as we all know
;-)

Apparently you are not aware of the 'session' concept of org source
blocks (please refer to the org manual). 
This is nothing specific to ob-picolisp, but holds for all ob languages
that do allow for sessions:

,
| * Picolisp scr-block test
| 
| #+BEGIN_SRC picolisp  :session pil1
|  (setq X1 (+ 3 4))
| #+END_SRC
| 
| #+results:
| : 7
| 
| 
| #+BEGIN_SRC picolisp  :session pil1
| (setq X2 (+ X1 1))
| #+END_SRC
| 
| #+results:
| : 8
| 
| 
| #+BEGIN_SRC picolisp  :session pil1
| (de foo1 (X) (+ X 2))
| #+END_SRC
| 
| #+results:
| : foo1
| 
| #+BEGIN_SRC picolisp  :session pil1 :results raw
| (setq X3 (foo1 8))
| #+END_SRC
| 
| #+results:
| 10
`

And, with a session, you do have a related interactive repl buffer in
Emacs called "pil1", thats reflects all evaluations of the code blocks
in the org file, and allows for user input just like the PicoLisp repl:

,
| (setq X1 (+ 3 4))
| 'org-babel-picolisp-eoe
| : -> 7
| : -> org-babel-picolisp-eoe
| : (setq X2 (+ X1 1))
| 'org-babel-picolisp-eoe
| -> 8
| : -> org-babel-picolisp-eoe
| : (de foo1 (X) (+ X 2))
| 'org-babel-picolisp-eoe
| -> foo1
| : -> org-babel-picolisp-eoe
| : (setq X3 (foo1 8))
| 'org-babel-picolisp-eoe
| -> 10
| : -> org-babel-picolisp-eoe
| : 
`

Hope that helps

-- 
cheers,
Thorsten

Re: [O] Feature suggestion and code review request: org-babel-cycle-src-block-header

[Akater]

Thank you, I'll make use of 's. Not well versed in Elisp
libraries. save-excursion is certainly an improvement, too.


signature.asc
Description: PGP signature

Re: [O] question on org-element-interpret-data and when it works

[Nicolas Goaziou]

Thorsten Jolitz  writes:

> You used the word 'discrepancy',

True. I inferred it from

  (funny enough, some org elements have 'value' as their content, others
  'content').

which, IMO, sounds like it is a surprising fact.

> I simply needed to know for each org
> element what is interpreted and what not. And some have a content,
> others a :value.

As in every AST, some nodes are terminal (no contents), and some are not
(contents).

This distinction is made in `org-element-greater-elements', i.e.,
non-terminal elements. See also `org-element-recursive-objects' for
non-terminal objects.

> So if I pass 'Hello World' as content to an example
> block, nothing happens, if I pass it via :value, it appears as the
> blocks ... well, content.

Contents imply Org syntax. This would defeat the purpose of an example
block.

Re: [O] question on org-element-interpret-data and when it works

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Thorsten Jolitz  writes:
>
>> I have defined these two constants in org-dp.el to work around this
>> discrepancy (and to know which elements do not have interpreted content
>> at all):
>>
>> ,
>> | (defconst org-dp-no-content-elems
>> |   (list 'babel-call 'clock 'comment 'comment-block 'diary-sexp
>> |'example-block 'fixed-width 'horizontal-rule 'keyword
>> |'latex-environment 'node-property 'planning 'src-block)
>> |   "List of Org elements without interpreted .")
>> | 
>> | (defconst org-dp-value-blocks
>> |   (list 'comment-block 'example-block 'src-block)
>> |   "List of Org block that have a :value instead of contents.")
>> `
>
> I don't understand where you think there is a discrepancy here.

You used the word 'discrepancy', I simply needed to know for each org
element what is interpreted and what not. And some have a content,
others a :value. So if I pass 'Hello World' as content to an example
block, nothing happens, if I pass it via :value, it appears as the
blocks ... well, content.

This is no critique, and no problem, and please don't change it (since
it would be a breaking change in this context). 

With the org-dp tempo-templates, its no problem for org-dp users either,
since these are smart: they offer you a content arg (cont) to fill, if
it makes sense, they hide it, if not. And for some block types they
offer the :value parameter, since it is interpreted.

So I don't see any problem, just something an org-dp user probably
should be aware of.

-- 
cheers,
Thorsten

Re: [O] emacs laggs with saving clipboard to X clipboard manager

[Eric S Fraga]

I have found that this setting can help:

(setq x-selection-timeout 10)

Not always, mind you, and sometimes you will have to ask to paste the
selection more than once.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-191-g90607d


signature.asc
Description: PGP signature

Re: [O] question on org-element-interpret-data and when it works

[Nicolas Goaziou]

Thorsten Jolitz  writes:

> I have defined these two constants in org-dp.el to work around this
> discrepancy (and to know which elements do not have interpreted content
> at all):
>
> ,
> | (defconst org-dp-no-content-elems
> |   (list 'babel-call 'clock 'comment 'comment-block 'diary-sexp
> | 'example-block 'fixed-width 'horizontal-rule 'keyword
> | 'latex-environment 'node-property 'planning 'src-block)
> |   "List of Org elements without interpreted .")
> | 
> | (defconst org-dp-value-blocks
> |   (list 'comment-block 'example-block 'src-block)
> |   "List of Org block that have a :value instead of contents.")
> `

I don't understand where you think there is a discrepancy here.

Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?

[Daniel P Gomez]

Hi,


> `org-export--prepare-file-contents' is called from the including
> document, so you can get its path with (buffer-file-name
> (buffer-base-buffer)).
>
> However, we need to handle the case where the including buffer is not
> associated to a file, i.e., the Sexp above returns nil.
>

I noticed that (buffer-file-name (buffer-base-buffer)) will always
return nil because `org-export--prepare-file-contents` is called in
`org-export-include-keyword` after a call to `with-temp-buffer`. Two
possible solutions to this issue would be either 1. passing the
includer-file as an extra parameter to
`org-export--prepare-file-contents` and then using
`file-relative-name` to generate a relative path, or alternatively 2 .
passing the matched string that points to the file to be included.
Example:

#+INCLUDE: "directory/file.org"

Here, if file.org contains a link [[other/image.png]], then all one
has to do is append the (file-name-directory matched) to the old-path.
In this example this would result in directory/other/image.png.

This second solution does not require a call to (buffer-file-name
(buffer-base-buffer)), but seems hackish in the sense that we would
pass 2 redundant arguments to `org-export-prepare-file-contents`: both
the expanded and the non-expanded include-file filename.
Perhaps I'm missing a simpler 3rd solution?


> It would be nice to add a comment explaining what we are going to do.
>
Of course.

;; Adapt all file links within the included document that
;; contain relative paths in order to make these paths
;; relative to the base document, or absolute

> I suggest the following inner part:
>
> (when (string= "file" (org-element-property :type link))
>   (let* ((old-path (org-element-property :path link))
>  (new-path (expand-file-name old-path (file-name-directory 
> file

I noticed that the call to delete here will break
`org-element-adopt-elements` later on since the real buffer positions
will be changed and we are still querying for old, invalid positions
stored in link.
> ;; (delete-region (org-element-property :begin link)
> ;;   (org-element-property :end link))
> (insert (let ((new (org-element-copy link)))

If we opt for solution 1 then new-path could be made relative here
>  ;; (org-element-put-property new :path new-path)

(org-element-put-property
   new :path
   (if includer-file
   (file-relative-name
new-path (file-name-directory includer-file))
 new-path))

>   (when (org-element-property :contents-begin link)
> (org-element-adopt-elements new
>   (buffer-substring (org-element-property :contents-begin 
> link)
> (org-element-property :contents-end 
> link

Deleting immediately before the insertion works.
(delete-region (org-element-property :begin link)
   (org-element-property :end link))

>   (org-element-interpret-data new)
>
> Also, would you mind adding a test in "text-ox.el", within
> `test-org-export/expand-include'?

I will attempt to write them once the implementation is completed.

Thanks for the support.

Regards,

Daniel

> Regards,
>
> --
> Nicolas Goaziou

Re: [O] question on org-element-interpret-data and when it works

[Thorsten Jolitz]

Nicolas Goaziou  writes:

Hello,

> Thorsten Jolitz  writes:
>
>> (funny enough, some org elements have 'value' as their content, others
>> 'content').
>
> Could you point out where there is such discrepancy in "org-element.el"?

I have defined these two constants in org-dp.el to work around this
discrepancy (and to know which elements do not have interpreted content
at all):

,
| (defconst org-dp-no-content-elems
|   (list 'babel-call 'clock 'comment 'comment-block 'diary-sexp
|   'example-block 'fixed-width 'horizontal-rule 'keyword
|   'latex-environment 'node-property 'planning 'src-block)
|   "List of Org elements without interpreted .")
| 
| (defconst org-dp-value-blocks
|   (list 'comment-block 'example-block 'src-block)
|   "List of Org block that have a :value instead of contents.")
`

PS 
should probably read "... without interpreted content" in the first
defconst

-- 
cheers,
Thorsten

[O] emacs laggs with saving clipboard to X clipboard manager

[Joseph Vidal-Rosset]

Hello everybody,

I apologize,  I know  that this  topic is org-mode  specific, but  it is
related to emacs.

My problem is exactly the same that is explained here :
[[https://github.com/syl20bnr/spacemacs/issues/9691]]
and my OS  is the same (Gnu Linux  Debian 9).  I do not  succeed to find
the solution,  knowing that I need  to copy and paste  in emacs elements
that are outside emacs.

Your help is welcome. 

-- 
Joseph 

Re: [O] question on org-element-interpret-data and when it works

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  writes:

> (funny enough, some org elements have 'value' as their content, others
> 'content').

Could you point out where there is such discrepancy in "org-element.el"?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Typo in the compact Org Mode Guide

[Nicolas Goaziou]

Hello,

sira...@disroot.org writes:

> I have encountered a typo. It's on page 10 of the PDF of the latest
> release (9.1.7). The sentence in question is:
>
>> Org mode providing methods to give you an overview of all the things that 
>> you have to do, collected
>> from many files.
>
> The corrected version should appear as follows:
>
>> Org mode *provides* methods to give...
>
> Please let me know if it's an legitimate grammatical error.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] how do you compose mails in Gnus with org-mode

[Thorsten Jolitz]

Joseph Vidal-Rosset  writes:

Hallo

> I know that the subject of my email exists already.
> [[https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html]]

This works perfectly for your subject:

,[ C-h f outorg-edit-as-org RET ]
| outorg-edit-as-org is an interactive Lisp function in ‘outorg.el’.
| 
| It is bound to M-# #,   .
| 
| (outorg-edit-as-org  ARG)
| 
| Convert and copy to temporary Org buffer
| 
| With ARG, act conditional on the raw value of ARG:
| 
| | prefix | raw | action 1  | action 2   |
| |+-+---+|
| | C-u| (4) | edit-whole-buffer | ---|
| | C-1|   1 | edit-whole-buffer | insert default export-template |
| | C-2|   2 | edit-whole-buffer | prompt user for template-file  |
| | C-3|   3 | edit-whole-buffer | insert & keep default template |
| | C-4|   4 | edit-whole-buffer | insert & keep template-file|
| | C-5|   5 | propagate changes | ---|
| 
| [back]
`

It has already been described several time how to configure
outshine/outorg that it works with message-mode too.

Its actually quite easy. Configure outshine like described in the
README, and add outline-minor-mode to message-mode-hook in your .emacs.

,
| (add-hook 'emacs-lisp-mode-hook 'outline-minor-mode)
| (add-hook 'message-mode-hook 'outline-minor-mode))
`

Then with M-# # your email (open in message-mode, gnus) will be opened
in an org-mode buffer for editing in org-mode.

Looks very similar to opening a source-block in org-mode to edit the
sources in the programming language mode.

,
| [ *unsent followup to Joseph Vidal-Rosset on gmane.emacs.orgmode* ] 
| Exit with M-# (Meta-Key and #)
| * --text follows this line--
| Joseph Vidal-Rosset  writes:
| 
| Hallo
| 
| > I know that the subject of my email exists already.
| > https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg00855.html
| 
| This works perfectly for your subject:  [...]
`

and tells you how to exit again: M-#

-- 
cheers,
Thorsten

Re: [O] question on org-element-interpret-data and when it works

[Thorsten Jolitz]

John Kitchin  writes:

Hello John,

> I am trying to find some ways to programatically modify org-elements
> that use fewer regexps and motion commands. It seems like org-dp
> (https://github.com/tj64/org-dp) was intended to do that

thats right, that's it's exact use case

> but it is not clear enough how you might use it, and it also doesn't
> seem to support plain-lists yet.

it's actually split into core and lib functionality, org-dp.el being the
core and org-dp-lib.el being the lib.

AFAIK it org-dp does work, and in its core it's based on just two
commands, one for CREATE and one for REWIRE (=modify) org elements
(locally, not replacing Nicolas org element framework, but rather making
it easy to use locally without the need for a whole parse tree).

The basic idea:
 - internally, all org elements look alike (plists)
 - org elements have many properties, but we are interested only in
   those used by the org element interpreter (that creates org syntax
   out of Emacs Lisp plists). These are surprisingly few.
 - luckily, plists ignore all elements that are not accessed, making
   transformation between different plists for different org elements
   much easier

You should be able to do anything you want with org elements with just
these two functions, org-dp-create and org-dp-rewire.

There is a generic prompt function two. Never write interactive specs
again, just use this one prompt functions for all org element related
prompts (or utility commands based on the prompt workhorse).

And then there is this fast and simple mapping function for org-dp:

,[ C-h f org-dp-map RET ]
| org-dp-map is a Lisp function in ‘org-dp.el’.
| 
| (org-dp-map FUN-WITH-ARGS RGXP  MATCH-POS BACKWARD-SEARCH-P
| BEG END SILENT-P)
| 
| Apply quoted FUN-WITH-ARGS at every RGXP match.
| 
| [...] 
| In contrast to other mapping functions in Org-mode, this mapping
| function does not collect any information about mapped elements,
| it simply moves point quickly to all positions in a buffer(range)
| that are matched by a (forward) regexp-search and applies one of
| ‘org-dp’’s or ‘org-dp-lib’’s functions locally at that
| point (i.e. without any context information other than that about
| the parsed element-at-point).
| 
| When calling FUN ‘org-dp-create’, or ‘org-dp-rewire’ with
| argument ELEMENT given, no parsing at all takes places, but newly
| created of modified elements can be inserted at point.
| 
| This mapping function wraps its body in ‘save-excursion’ and
| ‘save-match-data’ calls, so point position and global match-data
| are preserved. It does not widen the buffer before executing its
| body, so buffer restrictions are respected. 
`

> What I imagined happening is that I would get the element to modify as a
> data structure, modify the data structure, and replace the old element
> with an interpreted version of the modified data structure.

Thats exactly what this central org-dp workhorse function does:

,[ C-h f org-dp-rewire RET ]
| org-dp-rewire is a Lisp function in ‘org-dp.el’.
| 
| (org-dp-rewire ELEM-TYPE  CONTENTS REPLACE AFFILIATED ELEMENT
|  ARGS)
| 
| Rewire element-at-point or ELEMENT (if given).
| 
| [...] 
| ELEM-TYPE is one of the types in ‘org-element-all-elements’. If
| it is nil, the element type of the original element is used. ARGS
| is a plist consisting of key-val pairs of all other keyword
| arguments given, defining the (rewired) element’s properties.
| 
| The former value of an element property can be reused in the
| creation of a new value by giving a ‘lambda’ expession or
| function taking two arguments (instead of just a value) to a
| key. The first argument will then be replaced by the property’s
| former value when applying the function. The second argument
| should be the parsed element itself, enabling access to its type
| and all its properties inside of the lambda expression.
`

But, as Nicolas said in his answer, plain lists, tables, properties
etc are nested org elements, what is most obvious with tables:
a table is just a container for table rows that hold the actual data
(with some meta data in the container).

Thats why org-dp-lib.el has several related functions:

,
| org-dp-lib.el
| 40:(defun org-dp-wrap-in-block ( lines user-info  prompt-spec)
| 204:(defun org-dp-toggle-headers ( action)
| 290:(defun org-dp-org-props ()
| 307:(defun org-dp-filter-node-props (filter  negate-p verbose-p)
| 366:(defun org-dp-create-table (row-lst  tblfm table-el-p insert-p)
| 416:(defun org-dp-create-plain-list (item-lst  insert-p)
| 452:(defun org-dp-create-property-drawer (node-prop-lst  insert-p)
`

They should hopefully be pretty well documented, since I use to do that.

To get started with org-dp, you really need these 3 (or 4)
functions. They spare you typing, and more important, they tell which
properties of an org element matter for its interpretation.

CREATE:

,[ C-h f tempo-template-org-dp-create RET ]
| tempo-template-org-dp-create 

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

Hello,

Bastien Guerry  writes:

> Nothing, please move ahead.

Great.

> I suggest to rename the file org.org, which will produce org.texi.

I don't understand this part. Currently, "manual.org" is exported as
"org.texi" per

  #+export_file_name: org.texi

So we are getting the best of both worlds. Am I missing something?

> Or org-manual.org, which seems more readable.

I think "manual.org" is simpler, but I do not mind renaming it to
"org-manual.org". However, I find "org.org" silly.

In any case, I let you decide the name before moving forward.

> It would be great to have org-guide.org too, but I guess that's a
> lot of work.

It's a joke compared to manual.org. However, we first need to agree on
a style guide for "manual.org".

Regards,

-- 
Nicolas Goaziou

Re: [O] what settings would make original export to pdf as good as pandoc conversion?

[Eric S Fraga]

On Friday,  2 Mar 2018 at 11:53, Samuel Wales wrote:
> On 3/2/18, Eric S Fraga  wrote:
>> Why can you not use any LaTeX settings?  Org has very extensive support
>> for allowing tweaking of the formatting.
>
> delighted to learn of settings.

So, I am not sure what it is you want to do but maybe a line along the
lines of

#+latex_header: \setlength{\parindent}{0pt}\setlength{\parskip}{6pt}

might give you "unbunched" "unindented" paragraphs.

A table of contents will probably only be generated if you have not
turned of heading numbering.  You can turn this on explicitly by

#+options: toc:t num:t

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-191-g90607d


signature.asc
Description: PGP signature

Re: [O] Bug: [ob-clojure] Surprising evaluation result [9.1.6 (release_9.1.6-491-g70b029 @ /Users/xcy/src/org-mode/lisp/)]

[Xu Chunyang]

"numbch...@gmail.com"  writes:

> No, it's not expected result. It should be caused by my commit here
> https://code.orgmode.org/bzg/org-mode/pulls/5

I don't think so, your pull request is about ob-clojure-literate, while
I am talking about ob-clojure. I want to know what authors of ob-clojure
think about the behavior, is it a Bug?

> Don't know how to workaround this.

As for workaround, I have the following in my init.el

(define-advice org-babel-expand-body:clojure (:filter-return (body) do)
  (format "(do %s)" body))

[...]

Re: [O] [RFC] Moving "manual.org" into core

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> I'm bumping the thread. What is still needed for that to move
> forward?

Nothing, please move ahead.

I suggest to rename the file org.org, which will produce org.texi.

Or org-manual.org, which seems more readable.

It would be great to have org-guide.org too, but I guess that's a
lot of work.

> Again, the first step could be to move manual.org to core and have
> it generate a new org.texi, overwriting the previous one.

Yes, let's do that manually for now.

> I would also be nice to think about what can be done to automatically
> generate org.texi upon releases, and remove it from the repository. But
> that can come later.

Indeed.

Sorry it took me long to give the green light on this, I was trying
to anticipate all possible outcomes.

One of my worries was that moving toward editing a manual in .org
does not match GNU developers good practices and habits, which are
to edit .texi files.  But as long as the .texi file exists I guess
we can shake the habits by allowing to edit .org files, which are
more convenient to read and write.

Hopefully this step forward will help create a useful precedent
amont GNU developers.

Thanks to you and to anyone who has been involved in making this
possible!

-- 
 Bastien

Re: [O] [RFC] Moving "manual.org" into core

[Nicolas Goaziou]

Hello,

Bastien Guerry  writes:

> To be continued,

I'm bumping the thread. What is still needed for that to move forward?
Again, the first step could be to move manual.org to core and have it
generate a new org.texi, overwriting the previous one.

I would also be nice to think about what can be done to automatically
generate org.texi upon releases, and remove it from the repository. But
that can come later.


Regards,

-- 
Nicolas Goaziou

[O] bibliographystyle in scimax

[Joseph Vidal-Rosset]

Dear John,

I  am  happy   to  tell  you  that your  scimax
[[https://github.com/jkitchin/scimax ]] is a wonderful tool for emacs, for
org-mode and for exporting in LaTeX with references. I advice strongly
its use. 

I am  using Gnus and not  mu4e to write  emails and it works  well now
thanks of the help of Eric Fraga. 

This email  is just about  a detail. I guess  it would be  possible in
theory to get the  bibliography style that I want in  email as well as
in any other  exported document, but it  is not the case  for the html
export  and therefore  not for  html  email in  Gnus. It  is too  bad,
because  apalike for  example is  a good  option that  avoids Jan  von
Plato's reproach [[#vonplato2017][vonplato2017]]: 

#+BEGIN_QUOTE
A great disservice is being done to scholarship by the reference system
prevalent today that has running numbers, usually in square brackets,
for the items in the references. The defects of this system are twofold.
First, it is enormously disturbing for the reader to be constantly
checking the list of references to see what article or book is being
referred to. The reader’s memory is burdened with information that
has no meaning elsewhere. Second, the awareness of who did what
and when is eroded little by little. If we read Gödel (1931) or Gentzen
(1936), we know what that is, contrary to a plain [104] and [90], say,
and similarly with hundreds of other works. Such couplings of names
and years give us a timeline that is indispensable for an awareness of
the development of logic or any other part of science. The thoughtless
“bibtex” square bracket numbering system of references is destroying
such awareness and should therefore be universally abandoned. It has
just one, totally inessential advantage: that it saves some space. In a
standard article, that may be a few lines, and in a book, a page or two.
#+END_QUOTE

So, do you  think that it is possible to  adopt the apalike bibliography
style in html document also? 

Best wishes, 

Jo. 

* Bibliography
** Jan von Plato - {The Great Formal Machinery Works: Theories of Deduction and 
Computation at the Origins of the Digital Age}
  :PROPERTIES:
 :CUSTOM_ID: vonplato2017
   :=TYPE=: book
   :=KEY=: vonplato2017
   :TITLE: {{The Great Formal Machinery Works: Theories of Deduction and 
Computation at the Origins of the Digital Age}}
   :AUTHOR: {Jan von Plato}
   :PUBLISHER: {Princeton University Press}
   :ISBN: {0691174172,9780691174174}
   :YEAR: {2017}
   :ADDRESS: {Princeton}
   :SERIES: {}
   :EDITION: {}
   :VOLUME: {}
   :URL: 
{http://gen.lib.rus.ec/book/index.php?md5=78f2ef1addf9a3993f5601b9b4d6b5ba}
  :END: