Re: [O] Paragraph consisting only of number and full stop disappears in export

[Eric S Fraga]

On Sunday,  4 Mar 2018 at 14:07, Eric Abrahamsen wrote:
> Hi,
>
> I just discovered that a paragraph disappeared from a subtree I was
> exporting, I guess because the paragraph consists of just a number
> followed by a full stop, and was interpreted as a list item. I'm
> translating subtitles, and the dialogue went:

You don't say what export target you are using.  If LaTeX, you could do:

#+begin_src org
There are no taxis, but I've got a car.

How much to Dongying?

@@latex:@@300.

We can be there 10am tomorrow.
#+end_src

And probably similarly for HTML etc.

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


signature.asc
Description: PGP signature

Re: [O] Adding an item to the agenda from the agenda view

[Eric S Fraga]

On Sunday,  4 Mar 2018 at 23:22, Shérab wrote:
> I would like to add an item with the
> corresponding date to my agenda file. What would be the most direct /
> straightforward / idiomatic way to achieve this, please?

try "i d".  "i" should be bound to org-agenda-diary-entry.  This is the
route I use for adding entries to my agenda all the time.

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


signature.asc
Description: PGP signature

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

[John Kitchin]

I guess this is a feature of deleting a region with the point in it. This
code, for example, does not preserve point.

#+BEGIN_SRC emacs-lisp
"<>"
(save-excursion
  (let* ((p1 (point))
(p2 (re-search-backward (concat "<" ">")))
(content (buffer-substring-no-properties p1 p2)))
(delete-region p1 p2)
(insert content)))
#+END_SRC


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 Sun, Mar 4, 2018 at 4:21 PM, Thorsten Jolitz  wrote:

> John Kitchin  writes:
>
> > Thanks for the examples.
> >
> > There is an interesting issue, the following does not save-excursion!
> >
> > (save-excursion
> > (org-dp-rewire 'src-block t t ;cont ins
> > t ;aff
> > nil ;elem
> > :parameters ":results output"))
> >
> > The point gets moved. Do you know why that happens?
>
> Hmm ... org-dp-rewire is mostly fidling around with lists, but in the
> end it acts conditionally on the 'replace' parameter:
>
> ,
> | (if (and (marker-position beg)
> |(marker-position end))
> |   (cl-case replace
> | (append (save-excursion (goto-char end) (insert strg)))
> | (prepend (goto-char beg) (insert strg))
> | (t (if (not replace)
> |strg
> |  (delete-region beg end)
> |  (goto-char end)
> |  (set-marker beg nil)
> |  (set-marker paff nil)
> |  (set-marker end nil)
> |  (save-excursion (insert strg)
> |   (if replace (insert strg) strg
> `
>
> append or prepend result, return it as string, or replace the rewired
> element.
> I guess the is a save-excursion missing here ...
>
> > 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 Sat, Mar 3, 2018 at 12:26 PM, Thorsten Jolitz 
> > wrote:
> >
> >  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 

Re: [O] Paragraph consisting only of number and full stop disappears in export

[Samuel Wales]

i thought that was example that monospaced it.

Re: [O] Paragraph consisting only of number and full stop disappears in export

[Eric Abrahamsen]

Samuel Wales  writes:

> verse block?

Maybe, except that puts it into monospaced font, and I'd have to wrap
the whole document in a verse block...

> On 3/4/18, Eric Abrahamsen  wrote:
>> Hi,
>>
>> I just discovered that a paragraph disappeared from a subtree I was
>> exporting, I guess because the paragraph consists of just a number
>> followed by a full stop, and was interpreted as a list item. I'm
>> translating subtitles, and the dialogue went:
>>
>> #+begin_src org
>> There are no taxis, but I've got a car.
>>
>> How much to Dongying?
>>
>> 300.
>>
>> We can be there 10am tomorrow.
>> #+end_src
>>
>> I'm not surprised that "300." got interpreted as a list item, but I
>> wonder if there's a way to protect against it being removed altogether.
>> I suppose it might be nice if a single list item with no content would
>> be interpreted as a paragraph, but that probably opens the door to all
>> kinds of weird edge cases. If there were just a way to escape it...
>>
>> Thanks,
>> Eric
>>
>>
>>

Re: [O] Paragraph consisting only of number and full stop disappears in export

[Samuel Wales]

verse block?

On 3/4/18, Eric Abrahamsen  wrote:
> Hi,
>
> I just discovered that a paragraph disappeared from a subtree I was
> exporting, I guess because the paragraph consists of just a number
> followed by a full stop, and was interpreted as a list item. I'm
> translating subtitles, and the dialogue went:
>
> #+begin_src org
> There are no taxis, but I've got a car.
>
> How much to Dongying?
>
> 300.
>
> We can be there 10am tomorrow.
> #+end_src
>
> I'm not surprised that "300." got interpreted as a list item, but I
> wonder if there's a way to protect against it being removed altogether.
> I suppose it might be nice if a single list item with no content would
> be interpreted as a paragraph, but that probably opens the door to all
> kinds of weird edge cases. If there were just a way to escape it...
>
> Thanks,
> Eric
>
>
>


-- 
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] Patch for documentation standards

[Thomas S. Dye]

Aloha Bastien,

Bastien Guerry writes:


Hi Thomas,

Feel free to cmmit when appropriate.  IMO, the comment period 
for
Nicolas' manual project has been sufficiently long and I do not 
want

to work with you to prolong it.


Mhh... "working with me" would shorten it for sure!

Anyway, I committed this:

https://code.orgmode.org/bzg/org-mode/commit/dd99ed74430a8b6a48f6b63fac71a0bede3e772f

Let me know what you think.


I hope you find it useful.

All the best,
Tom

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

[O] Paragraph consisting only of number and full stop disappears in export

[Eric Abrahamsen]

Hi,

I just discovered that a paragraph disappeared from a subtree I was
exporting, I guess because the paragraph consists of just a number
followed by a full stop, and was interpreted as a list item. I'm
translating subtitles, and the dialogue went:

#+begin_src org
There are no taxis, but I've got a car.

How much to Dongying?

300.

We can be there 10am tomorrow.
#+end_src

I'm not surprised that "300." got interpreted as a list item, but I
wonder if there's a way to protect against it being removed altogether.
I suppose it might be nice if a single list item with no content would
be interpreted as a paragraph, but that probably opens the door to all
kinds of weird edge cases. If there were just a way to escape it...

Thanks,
Eric

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

[Thorsten Jolitz]

John Kitchin  writes:

> Thanks for the examples.
>
> There is an interesting issue, the following does not save-excursion!
>
> (save-excursion
> (org-dp-rewire 'src-block t t ;cont ins
> t ;aff
> nil ;elem
> :parameters ":results output"))
>
> The point gets moved. Do you know why that happens?

Hmm ... org-dp-rewire is mostly fidling around with lists, but in the
end it acts conditionally on the 'replace' parameter:

,
| (if (and (marker-position beg)
|(marker-position end))
|   (cl-case replace
| (append (save-excursion (goto-char end) (insert strg)))
| (prepend (goto-char beg) (insert strg))
| (t (if (not replace)
|strg
|  (delete-region beg end)
|  (goto-char end)
|  (set-marker beg nil)
|  (set-marker paff nil)
|  (set-marker end nil)
|  (save-excursion (insert strg)
|   (if replace (insert strg) strg
`

append or prepend result, return it as string, or replace the rewired
element.
I guess the is a save-excursion missing here ...

> 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 Sat, Mar 3, 2018 at 12:26 PM, Thorsten Jolitz 
> wrote:
>
>  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
>  

Re: [O] [FYI] Programming with org-dp (by example)

[Thorsten Jolitz]

Thorsten Jolitz  writes:

PS
Ups ... a few little bugs in the code, here is version 2

#+BEGIN_SRC emacs-lisp  
(defconst tj/radio-rgxp "^#\\+attr_org:[[:space:]]+:radio")
(defconst tj/radio-temp "temp")
(defconst tj/radio-wind "wind")

(defvar tj/radio-rw '("temp" "wind")) ;read/write
(defvar tj/radio-r '("take-a-walk")) ;read only

(defvar tj/radio-temp-red '("freezing" "tropical"))
(defvar tj/radio-temp-yellow '("cold" "hot"))
(defvar tj/radio-temp-green '("normal" "warm"))

(defvar tj/radio-wind-red '("hurricane"))
(defvar tj/radio-wind-yellow '("storm"))
(defvar tj/radio-wind-green '("breeze"))

;; rewire function
(defun tj/radio-switch ()
  "docstring"
  (interactive)
  (let ((stmp (time-stamp-string)))
(forward-line)
(org-dp-rewire 'plain-list
   'tj/radio-cont ;cont
   t ;ins 
   `(:attr_last_changed (,stmp)) ;aff 
   nil ;elem 
   )))

;; mapping function
(defun tj/radio-map ()
  "docstring"
  (interactive)
  (let (temp wind)
  (org-dp-map '(tj/radio-switch) tj/radio-rgxp)))



;; HELPER FUNCTIONS
;; helper function to actually modify the content
(defun tj/radio-cont (cont elem)
  "docstring"
  (let ((name (org-element-property :name elem))
(prompt-options (tj/radio-get-itm-labels cont))
(new-cont)
(users-choice)
(box-checked-p))
(cond
 ((member name tj/radio-rw) ;prompt user for value
  (progn
(setq users-choice (ido-completing-read name prompt-options))
(set (intern name) users-choice)
(setq new-cont (mapcar 'tj/radio-itm-rw cont
 ((member name tj/radio-r) ;set value
  (setq new-cont
(mapcar 'tj/radio-itm-r cont)))
 (t)) ;do nothing
(or new-cont cont)))


(defun tj/radio-get-itm-labels (cont)
  "docstring"
  (mapcar #'(lambda (itm)
  (string-remove-suffix
   "\n"
   (org-dp-contents itm t t)))
   cont))

(defun tj/radio-itm-rw (itm)
  "docstring"
  (let ((label (string-remove-suffix
"\n" (org-dp-contents itm t t
(if (string-equal label users-choice)
(org-element-put-property itm :checkbox 'on)
(org-element-put-property itm :checkbox 'off))
itm))

(defun tj/radio-itm-r (itm)
  "docstring"
  (let ((label (string-remove-suffix
"\n" (org-dp-contents itm t t

(org-element-put-property itm :checkbox 'off)

(cond
 ((and (string-equal label "red")
   (not box-checked-p)
   (or (member temp tj/radio-temp-red)
   (member wind tj/radio-wind-red)))
  (org-element-put-property itm :checkbox 'on)
  (setq box-checked-p t))

 ((and (string-equal label "yellow")
   (not box-checked-p)
   (or (member temp tj/radio-temp-yellow)
   (member wind tj/radio-wind-yellow)))
  (org-element-put-property itm :checkbox 'on)
  (setq box-checked-p t))

 ((and (string-equal label "green")
   (not box-checked-p)
   (or (member temp tj/radio-temp-green)
   (member wind tj/radio-wind-green)))
  (org-element-put-property itm :checkbox 'on)
  (setq box-checked-p t)))
itm))
#+END_SRC


> Hello List,
> due to some interest in org-dp recently on this list, I actually took
> the challenge of implementing a feature request by John Kitchin (without
> actually sticking close to the specification, this is just a showcase
> for org-dp).
>
> Task: implement a radio-list with org checkboxes 
> Extra feature: a read only radio-list that changes its values
> conditional on the values of read/write radio-lists (when mapping the
> buffer)

-- 
cheers,
Thorsten

[O] [FYI] Programming with org-dp (by example)

[Thorsten Jolitz]

Hello List,
due to some interest in org-dp recently on this list, I actually took
the challenge of implementing a feature request by John Kitchin (without
actually sticking close to the specification, this is just a showcase
for org-dp).

Task: implement a radio-list with org checkboxes 
Extra feature: a read only radio-list that changes its values
conditional on the values of read/write radio-lists (when mapping the
buffer)

Example org buffer 

,
| * org-mode radio-list test
| 
| #+NAME: temp
| #+ATTR_ORG: :radio
| - [ ] freezing
| - [ ] cold
| - [ ] normal
| - [X] warm
| - [ ] hot
| - [ ] tropical
| 
| #+NAME: wind
| #+ATTR_ORG: :radio
| - [X] breeze
| - [ ] storm
| - [ ] hurricane
| 
| #+LABEL: read-only
| #+NAME: take-a-walk
| #+ATTR_ORG: :radio
| - [ ] red
| - [ ] yellow
| - [X] green
`

This is the main program.
The nice thing about this kind of declarative programming:
- parsing and interpretation is left to the org-element framework
- its very clear what we want/need to do: implement tj/radio-cont 

,
| ;; rewire function
| (defun tj/radio-switch ()
|   "docstring"
|   (interactive)
|   (let ((stmp (time-stamp-string)))
| (forward-line)
| (org-dp-rewire 'plain-list 
|  'tj/radio-cont ;cont
|  t ;ins 
|  `(:attr_last_changed (,stmp)) ;aff 
|  nil ;elem 
|  )))
| 
| ;; mapping function
| (defun tj/radio-map ()
|   "docstring"
|   (interactive)
|   (let (temp wind)
|   (org-dp-map '(tj/radio-switch) tj/radio-rgxp)))
`

tj/radio-switch () is the 'rewire' function to modify the plain
(checkbox) list at point.
It does two things:

1. call function 'tj/radio-cont to modifiy the content (= items) of the
plain list

2. add a new affiliated keyword with a current timestamp
`(:attr_last_changed (,stmp))

tj/radio-map () is the mapping function 

Here is the result of switching to more extreme weather conditions by
calling tj/radio-map and answering the user prompts two times:

,
| #+NAME: temp
| #+ATTR_ORG: :radio
| #+ATTR_LAST_CHANGED: 2018-03-05 00:12:02 tj
| - [ ] freezing
| - [ ] cold
| - [ ] normal
| - [ ] warm
| - [ ] hot
| - [X] tropical
| 
| #+NAME: wind
| #+ATTR_ORG: :radio
| #+ATTR_LAST_CHANGED: 2018-03-05 00:12:05 tj
| - [ ] breeze
| - [ ] storm
| - [X] hurricane
| 
| #+NAME: take-a-walk
| #+ATTR_ORG: :radio
| #+ATTR_LAST_CHANGED: 2018-03-05 00:12:10 tj
| - [X] red
| - [ ] yellow
| - [ ] green
`

Emacs Lisp is very good for working with text, but with regards to org
elements, whats needed for parsing and interpreting has already be
written by Nicolas, why not reuse it and work on a higher level.

So org-dp might be a light-weight alternative when acting locally on org
elements (no need for a full parse tree). It produces pretty clean code,
since working on text is replaced by working with lists.

PS 1

There was a bug in org-dp.el, I fixed it locally but cannot push to
origin due to github authentication problems (sight..), so if you want to
try the code here, you need to change this too:

,
| (cont (let ((orig-elem-cont (org-dp-contents elem)))
|  (cond
|   ;; ((and (consp contents) (functionp contents))
|   ((and contents (functionp contents)) ...
`

magit diff of same change:

,
| 1 file changed, 2 insertions(+), 1 deletion(-)
| org-dp.el | 3 ++-
| 
| modified   org-dp.el
| @@ -709,7 +709,8 @@ (cl-defun org-dp-rewire (elem-type  contents 
replace affiliated element
|  (make-marker) (org-element-property :end elem)))
|(cont (let ((orig-elem-cont (org-dp-contents elem)))
|(cond
| -   ((and (consp contents) (functionp contents))
| +   ;; ((and (consp contents) (functionp contents))
| +   ((and contents (functionp contents))
|  (apply contents (list orig-elem-cont elem)))
| ((and contents (booleanp contents))
|  orig-elem-cont)
`

PS 2 

here is the complete code:

#+BEGIN_SRC emacs-lisp  
(defconst tj/radio-rgxp "^#\\+attr_org:[[:space:]]+:radio")
(defconst tj/radio-temp "temp")
(defconst tj/radio-wind "wind")

(defvar tj/radio-rw '("temp" "wind")) ;read/write
(defvar tj/radio-r '("take-a-walk")) ;read only

(defvar tj/radio-temp-red '("freezing" "tropical"))
(defvar tj/radio-temp-yellow '("cold" "hot"))
(defvar tj/radio-temp-green '("normal" "warm"))

(defvar tj/radio-wind-red '("breeze"))
(defvar tj/radio-wind-yellow '("storm"))
(defvar tj/radio-wind-green '("hurricane"))

;; rewire function
(defun tj/radio-switch ()
  "docstring"
  (interactive)
  (let ((stmp (time-stamp-string)))
(forward-line)
(org-dp-rewire 'plain-list
   'tj/radio-cont ;cont
   t ;ins 
   `(:attr_last_changed (,stmp)) ;aff 
   nil ;elem 
   )))

;; mapping function
(defun tj/radio-map ()
  "docstring"
  (interactive)
  (let (temp wind)
  (org-dp-map '(tj/radio-switch) tj/radio-rgxp)))



;; 

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

[John Kitchin]

Thanks for the examples.

There is an interesting issue, the following does not save-excursion!

(save-excursion
  (org-dp-rewire 'src-block t t ;cont ins
 t ;aff
 nil ;elem
 :parameters ":results output"))

The point gets moved. Do you know why that happens?

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 Sat, Mar 3, 2018 at 12:26 PM, Thorsten Jolitz  wrote:

> 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)
> > - 

[O] Adding an item to the agenda from the agenda view

[Shérab]

Dear org-mode friends,

I use currently only one agenda file. Sometimes, when I need to plan for
something, I check the agenda
views to find a day when I am available to do that thing. Once I have
found this day in the view, I would like to add an item with the
corresponding date to my agenda file. What would be the most direct /
straightforward / idiomatic way to achieve this, please?

I read section 10.5 in the manual and the closest thing I could find was
k to capture, but I think even this is not doing exactly what I am
looking for.

Many thanks in advance for your help!

Shérab.

Re: [O] Patch for documentation standards

[Thomas S. Dye]

Aloha Bastien,

> Can you make separate patches, one fixing errors and another one
> for the move to editing the manual with .org?

> I don't want to commit anything premature.

Feel free to cmmit when appropriate.  IMO, the comment period for 
Nicolas' manual project has been sufficiently long and I do not want to 
work with you to prolong it.


All the best,
Tom

Re: [O] Patch for documentation standards

[Bastien Guerry]

Hi Thomas,

> Feel free to cmmit when appropriate.  IMO, the comment period for
> Nicolas' manual project has been sufficiently long and I do not want
> to work with you to prolong it.

Mhh... "working with me" would shorten it for sure!

Anyway, I committed this:

https://code.orgmode.org/bzg/org-mode/commit/dd99ed74430a8b6a48f6b63fac71a0bede3e772f

Let me know what you think.

Thanks,

-- 
 Bastien

Re: [O] [BUG] org-clock-update-mode-line leaves link markup in mode-line

[Bastien]

Hi Matt,

Matt Lundin  writes:

> Is this change intentional? It is, of course, possible to strip the link
> markup with a custom org-clock-heading-function. But it seems to me that
> removing link markup from the mode-line display should remain the
> default behavior.

Thanks for reporting this -- it clearly does not make sense to
display links in the mode-line, so I pushed a fix to restore the
previous behavior by default.

Having org-clock-heading-function around is nice though.

Best,

-- 
 Bastien

[O] [BUG] org-clock-update-mode-line leaves link markup in mode-line

[Matt Lundin]

Commit 6655429b8d7ee686a8300b61af587599cd656a22 removed code that
stripped link markup from the string displayed in the mode line.

In the past, a heading like the following...

* TODO [[https://en.wikipedia.org/wiki/Org-mode][Org-mode]]

...would be simplified for display in the mode line as...

"[0:04] (Org-Mode)"

Now it displays as...

"[0:04] ([[https://en.wikipedia.org/wiki/Org-mode][Org-mode]])"

Is this change intentional? It is, of course, possible to strip the link
markup with a custom org-clock-heading-function. But it seems to me that
removing link markup from the mode-line display should remain the
default behavior.

Thanks,
Matt

[O] org-babel-execute-src-block does not insert inline image with `master` branch source code Org

[numbch...@gmail.com]

With following example:
```
#+begin_src gnuplot :session :results graphics :file "data/images/sin.png"
:cache no
set term png
set grid
plot sin(x), cos(x)
#+end_src
```
If I use Org-mode ELPA version. then it works fine.
But when I use `master` branch version, then it does not have any result.
Tried to check out git log of recently commits, and `ob-core.el` file
recent git log commits, and `ob-gnuplot.el`'s. But does not found any
suspicious commits yet.

Environment info:
- Arch Linux
- Emacs version: GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
Version 3.22.26) of 2018-02-10
- Org-mode version: Org mode version 9.1.7 (9.1.7-elpaplus @ mixed
installation! /home/stardiviner/.emacs.d/elpa/org-plus-contrib-20180226/
and /home/stardiviner/Code/Emacs/org-mode/lisp/)

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

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

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

>> Is the current contrib/orgmanual.org in sync with doc/org.texi in both
>> master and maint?
>
> Not at all. It is in sync (and a bit above) in master only.

Okay.

>> How difficult is it to keep it in sync in both branches?
>
> "manual.org" relies on improvements made to the Texinfo exporter in
> master branch only, and probably to some smaller parts of the export
> framework. I wouldn't try to sync the manual in maint branch.

So when we make the move, we publish 9.2 by merging master in maint
and edit orgmanual.org from both maint and master.  Correct?

> I find it much easier to handle and edit than its Texinfo counterpart,
> even though I have a good command of the Texinfo syntax. This allowed me
> to do a large number of improvements to it (structure, index,
> typography, overall consistency...), still not integrated in our
> official manual.

For the record: I have no doubt on this and this is also one of the
reasons I'm willing to make the switch.

> I would be surprised, to say the least, if anyone browsing in parallel
> "org.texi" and "manual.org" told me in good faith the former is clearer.

I find orgmanual.org to be clearer.  And I think we can make even more
aesthetics progress on this.

> That being said, we can hold as many number of weeks as you see fit.

It is not about setting a time window: we just need to be careful with
this move and discuss it.  One week seems fine.

I know I have been missing in action very often, and asking for more
time may not sound reassuring... but I'll push this forward, no worry.

Thanks,

-- 
 Bastien

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> For the record, and as a first feedback, I totally disagree with the
> FUD (".org flexibility will bring us new problems", seriously)
> spread about the Org manual.

Maybe I used the wrong word: let's call them "challenges", not
"problems".

But I'm sure there will be some.

And that's fine.  In any case, I did not want to spread FUD and I
don't have strong opinions on this issue.

> I spent months on the Org file. If it was a pain to do
> so ("Let's test org capabilities against a giant .org file."), I think
> I would have noticed.

When I said "Let's test org capabilities against a giant .org file."
I was not just thinking about editing it, but also e.g. exporting.

Testing the .texi exporter (and maybe .html and .pdf) against this big
file will be interesting.

Testing the process of running "make pdf" while emacs will in charge
of producing a PDF file (.org => .texi => .pdf) will be interesting,
and potentially more error-prone than the current .texi=>.pdf process.

But again, that's fine.

> The difficult part was to define editing
> conventions and stick to them. This is now done, and unrelated to the
> problem at hand.

I have not read the conventions yet, and other contributors may not
have read them, so this those conventions are just a proposal for now.
Core contributors need to formally discuss them and explicitely agree.

Again, the question is: what problem are we trying to solve?

Do you agree with the one I suggested?  Do you see others?

-- 
 Bastien

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

[Nicolas Goaziou]

Hello,

Bastien Guerry  writes:

> Is the current contrib/orgmanual.org in sync with doc/org.texi in both
> master and maint?

Not at all. It is in sync (and a bit above) in master only.

> How difficult is it to keep it in sync in both branches?

"manual.org" relies on improvements made to the Texinfo exporter in
master branch only, and probably to some smaller parts of the export
framework. I wouldn't try to sync the manual in maint branch.

> Would it be okay to hold on for one week before we make the switch,
> just to collect more feedback on this?

For the record, and as a first feedback, I totally disagree with the FUD
(".org flexibility will bring us new problems", seriously) spread about
the Org manual. I spent months on the Org file. If it was a pain to do
so ("Let's test org capabilities against a giant .org file."), I think
I would have noticed. The difficult part was to define editing
conventions and stick to them. This is now done, and unrelated to the
problem at hand.

I find it much easier to handle and edit than its Texinfo counterpart,
even though I have a good command of the Texinfo syntax. This allowed me
to do a large number of improvements to it (structure, index,
typography, overall consistency...), still not integrated in our
official manual.

I would be surprised, to say the least, if anyone browsing in parallel
"org.texi" and "manual.org" told me in good faith the former is clearer.

That being said, we can hold as many number of weeks as you see fit.

Regards,

-- 
Nicolas Goaziou0x80A93738

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

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou  writes:

> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.

Is the current contrib/orgmanual.org in sync with doc/org.texi in both
master and maint?

How difficult is it to keep it in sync in both branches?

Would it be okay to hold on for one week before we make the switch,
just to collect more feedback on this?

Thanks,

-- 
 Bastien

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

[Bastien Guerry]

Hi Glenn,

Glenn Morris  writes:

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

Thanks for your feedback.

You are definitely not worried about nothing.  I share some of your
worries.

To speak the truth, I first thought migrating to org as the preferred
format for editing the manual was just a bad idea.

More precisely: we went from "Oh, it would be nice to have the Org
manual in org" from "Hey, we have it now, why not make the switch?"

But in the process, we didn't define what were the problems we were
tryig to solve.  At least ones that core contributors agreed on.  Or
maybe I missed this discussion.  But no contributor complained about
.texi being such an horrible format for documentation.  I, for one,
feel like it's a very good format, with its apparent rigidity making
for careful contributions, while .org flexibility will bring us new
problems.

That said, why do I accept now?

It is *not* to honor people's work - although that kind of move is
very tempting, because I'm impressed by this achievement and don't
want to waste people's time.

I would define the problem we are trying to solve like this:

  We don't have enough manual contributors.  Many Org users report
  problems in the manual without proposing a patch, probably they
  afraid of making mistakes against a .texi file, so let's make it
  easier for them.

So I do accept to make the switch as a 1-year experiment.

During this year, the process of updating org.texi in Emacs branch
will not change: we will produce org.texi in org-mode/doc/ and then
sync it with Emacs as we do now.

There are very few direct edits of org.texi within Emacs, so we can
handle those changes by hand for now.

The switch will help us move forward like this:

- Let's stabilize editing standards around the org.org file.

- Let's test org capabilities against a giant .org file.

- Let's make `C-x 4 a' do something useful in an .org section.

- Let's write more non-emacs parsers and exporters.

- Let's see if we have more contributions to the manual and if
  we really solved a problem here.

If, in one year, we don't have more contributors and don't feel
the switch made us progress on anything above, and instead is a
blocker to get Org code directly edited from within Emacs, then
we can simply go back to editing org.texi directly.

So thanks for suggesting to bring this to emacs-devel: I will
do it later today, and we won't make the switch before getting
more feedback.  But let's not get blocked by false alarms!

Best,

-- 
 Bastien

Re: [O] Broken worg link

[Bastien]

Hi Alex,

Alex Branham  writes:

> https://orgmode.org/worg/org-tutorials/org-google-sync.html
>
> the link ical2org.awk 404s for me.

It should work now, thanks for reporting this.

-- 
 Bastien

Re: [O] Broken Worg link

[Bastien]

Hi Thomas,

"Thomas S. Dye"  writes:

> https://orgmode.org/worg/org-contrib/babel/languages.html 404s here.

thanks a lot for reporting this -- it took me a while, but it was a
problem in the nginx configuration.

Also, if anyone notices pages with wrong CSS-styling, it probably
comes comes from pages using #+head_html instead of #+head_html_extra.

See for example:

https://code.orgmode.org/bzg/worg/commit/932cc5d0d7d99ea4da4f3d8a8607d7293d60e44e

Best,

-- 
 Bastien

Re: [O] Patch for documentation standards

[Bastien]

Hi Thomas,

"Thomas S. Dye"  writes:

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

thanks a lot -- if I understand correctly, the patch fixes current
errors and also relies on the idea that the manual is written in org
(which is not yet the case).

Can you make separate patches, one fixing errors and another one
for the move to editing the manual with .org?

I don't want to commit anything premature.

Also, if you can push commits yourself, please go ahead!

Thanks,

-- 
 Bastien