[O] Editing Org-mode syntax in a web-browser (textarea)?

[Thorsten Jolitz]

Hi List, 

this question is explicitly *not* about popping up an emacsclient
instance from firefox or chrome to edit an html textarea in Emacs. And
its *not* about emacs-w3m or eww. 

I'm rather interested if there is something like Ymacs
(http://www.ymacs.org/) 

,
| Ymacs is an Emacs-like editor that works in your browser. Currently
| (starting with tag v0.4 in the code repository) it works in recent
| versions of Firefox (and other Gecko-based browsers), Google Chrome
| and Apple Safari.
`

that supports Org syntax too? 

I saw Org-mode mentioned in the context of Codemirror, but its not in
its language list (http://codemirror.net/mode/index.html). 

Both of these browser editors are of course extensible, and since they
support markdown, maybe creating an extension for org-mode would not be
so hard, but I would like to know if there already exist some useful browser
editing tools for Org syntax out there?

-- 
cheers,
Thorsten

Re: [O] PATCH: org-mac-link.el: Don't fail on machines without Growl installed

[Alan Schmitt]

On 2014-09-24 20:59, Steve Purcell  writes:

> On 24 Sep 2014, at 20:13, Alan Schmitt  wrote:
>
>> tell application "System Events"
>>  set growlHelpers to the name of every process whose creator type 
>> contains "GRRR"
>>  if (count of growlHelpers) > 0 then
>>  set growlHelperApp to item 1 of growlHelpers
>>  else
>>  set growlHelperApp to ""
>>  end if
>> end tell
>> 
>> I get an empty string as returned value. Is is the same for you?
>
>
> Yes, that part works fine on its own even on my machine. But when the
> code passed to AppleScript includes 'tell application
> “GrowlHelperApp”’, then the code will not execute unless the app is
> present — there’s a precompilation step where, presumably, AppleScript
> determines that the target application supports the listed commands.

I see. I agree this should be removed.

Org maintainers: can I apply this patch?

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] PATCH: Fix malformed "message" links produced by org-mac-link.el

[Alan Schmitt]

On 2014-09-24 20:56, Steve Purcell  writes:

> On 24 Sep 2014, at 20:01, Alan Schmitt  wrote:
>
>> This was the case here: the string returned by the AppleScript had
>> quotes (and it still does).
>> 
>> For instance, with the message you mention, the call to
>> org-as-get-selected-mail returns this (doing a debug):
>> 
>> Result: "\"message://2.b2af716655bbac583727@NY-WEB01::split::Private beta 
>> invitation for Emacs Q&A site - Area 51 - Stack Exchange\””
>
>
> I definitely don’t get quotes in the result of org-as-get-selected-mail.

…

> Not sure how to proceed, then…

It seems that the difference is with getting quotes or not. How about
changing org-as-get-selected-mail to make sure there is no quote? We
could for instance test whether the first and last characters are
quotes, and remove them if they are.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] Struggling with new exporter

[Phillip Lord]

Nicolas Goaziou  writes:

>> Okay, I've done it this way. Took a bit of fiddling since I need the
>> project-alist to work in different configurations (i.e. interactively,
>> in batch and in batch on a CI machine). Also, the timestamp stuff
>> confused me -- org was skipping publication, even though the output file
>> had been deleted.
>
> You can force re-pulication.

Yes, I did. I was confused by the skipping though -- I was expecting
make like behaviour -- where the output was checked. Still, it's fixed
now.

>> #+BIND: org-latex-custom-lang-environments ((clojure "tawny"))
>> #+BIND: org-latex-listings t
>>
>> isn't working at the moment. Source listings are coming out in verbatim.
>> Can I set this in the project-alist. From looking at org-latex-src-block
>> it would appear not.
>
> On the development branch, you can add ":latex-listings t" property in
> your project definition. In maint branch, you may dynamically bind
> `org-latex-listings' around project publishing function call.

Okay.

Currently, it appears to be that the org-latex-publish-to-pdf isn't
respecting :publishing-directory in the project-alist, so I am
publishing to latex and compiling by hand from there. I had to do this
anyway, because in batch, emacs swallows the latex output which makes
errors very hard to detect.

Thanks for the help.

Phil

Re: [O] Exporter dispatcher bug?

[Charles Berry]

Brady Trainor  uw.edu> writes:

> 
> 
> Charles Millar  verizon.net> writes:
> 
> > Brady Trainor wrote:
> >> Charles Millar  verizon.net> writes:
> >>
> >>> Today, using C-c C-e, the dispatcher shows only the LaTeX and
> >>> Publisher options.
> >>>
> >> What is the result C-h v org-export-backends?
> >>
> > -- snip --
> > Its value is (ascii html icalendar latex)
> > -- snip --
> >
> > Charlie
> 
> Looks normal! Wild guess, had to try :)
>

I think you want to check

(mapcar 'org-export-backend-name org-export--registered-backends)

to see what backends are actually available to the export dispatcher.

and  (mapcar 'org-export-backend-menu org-export--registered-backends)

to see what menu options should be there.

HTH,

Chuck

Re: [O] wrapping text around figure

[Nick Dokos]

marvin doyley  writes:

> Dear All,
>
> I am writing a grant proposal using Org-mode and I am trying to figure
> out how to wrap text around a figure. I have done this in the past
> (latex) using the wrapfig function, but it would be nice to do this
> using #Attr:
>

I haven't tried it (at least not recently), but the documentation says:

,
|If you have specified a caption as described in *note Images and
| tables::, the picture will be wrapped into a ‘figure’ environment and
| thus become a floating element.  You can also ask Org to export an image
| as a float without specifying caption by setting the ‘:float’ attribute.
| You may also set it to:
|− ‘t’: if you want to use the standard ‘figure’ environment.  It is
|  used by default if you provide a caption to the image.
|− ‘multicolumn’: if you wish to include an image which spans multiple
|  columns in a page.  This will export the image wrapped in a
|  ‘figure*’ environment.
|− ‘wrap’: if you would like to let text flow around the image.  It
|  will make the figure occupy the left half of the page.
|− ‘sideways’: if you would like the image to appear alone on a
|  separate page rotated ninety degrees using the ‘sidewaysfigure’
|  environment.  Setting this ‘:float’ option will ignore the
|  ‘:placement’ setting.
|− ‘nil’: if you need to avoid any floating environment, even when a
|  caption is provided.
| To modify the placement option of any floating environment, set the
| ‘placement’ attribute.
| 
|  #+ATTR_LATEX: :float wrap :width 0.38\textwidth :placement 
{r}{0.4\textwidth}
|  [[./img/hst.png]]
`

See

(info "(org) LaTeX specific attributes")

Nick

Re: [O] Exporter dispatcher bug?

[Brady Trainor]

Charles Millar  writes:

> Brady Trainor wrote:
>> Charles Millar  writes:
>>
>>> Today, using C-c C-e, the dispatcher shows only the LaTeX and
>>> Publisher options.
>>>
>> What is the result C-h v org-export-backends?
>>
> -- snip --
> Its value is (ascii html icalendar latex)
> -- snip --
>
> Charlie

Looks normal! Wild guess, had to try :)


Brady

Re: [O] Capturing outgoing gnus e-mail

[Ted Zlatanov]

On Sat, 14 Jun 2014 10:32:49 +0200 Ivan Kanis  wrote: 

IK> I would like to capture outgoing e-mail in my org file.

IK> I use the gcc mechanism in gnus with a nnml backend.

IK> I think I have read on the org mailing list that someone has implemented
IK> that feature. I did a search but could not find the article.

IK> I tried implementing it myself. I had a look at the function
IK> gnus-inews-do-gcc. It has the group and the article number. However org
IK> link expect the Message-ID header. How do I get it?

Well, I use the following to maintain a diary file. It's probably
equally easy to use a Org file:

(defun message-to-diary ()
  (make-diary-entry (concat
 (format-time-string "%B %d, %Y %H:%M" (gnus-date-get-time 
(message-fetch-field "date")))
 (if (message-fetch-field "newsgroups")
 (concat " Sent news To: " (message-fetch-field 
"newsgroups"))
   (concat " Sent mail To: " (message-fetch-field "to")))
 " Subject: \"" (message-fetch-field "subject") "\""
 " Message-ID: " (message-fetch-field "message-id")))
  (save-buffer "diary"))

(add-hook 'message-sent-hook 'message-to-diary)

HTH
Ted

Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists

[Aaron Ecay]

Hi Nicolas,

Thanks for the discussion.

2014ko irailak 24an, Nicolas Goaziou-ek idatzi zuen:
> 
> You cannot do that. This is not about backwards compatibility.
> 
> `org-list-parse-list' generates an easy to produce and work on internal
> representation for lists (similar to what `org-table-to-lisp' does for
> tables). 

Isn’t the org-element format also easy to work on?  It requires a bit
more than just car and cdr, but it’s well documented and used in many
places across the code base (= cognitive burden to use is lower).  It’s
also easy to produce in the sense that org-element.el already exists for
independent reasons; we just have to use it.

> `org-list-to-generic' is used for radio lists (similar to
> `org-table-to-generic'): it is expected to consume a
> `org-list-parse-list'-like return value.

Radio lists is a feature, org-list-to-generic is an implementation.  We
can change the implementation without changing the user-visible aspects
of the feature.  IOW, nothing about the user-facing functionality of
org-list-to-generic requires it to accept a particular type of argument
(as long as that arg is some representation or other of a list).

> 
> IOW both functions are important and are not meant to be replaced by
> Elements (however, at some point `org-list-to-generic' should use
> "ox.el", but that's for another day).

...doesn’t using ox.el entail using elements?

> 
> Note that since `org-list-parse-list' is meant for extraneous buffer, it
> cannot rely on Elements. It shouldn't even use `org-list-struct' because
> I plan to make this function use Elements, too.

One approach would be to detect when it’s called from a non-org-mode
buffer, and copy the text into a temporary org-mode buffer for parsing.
Then org-element would be available.

> 
>> The babel feature is compelling to me (and I guess Chuck) on its
>> own.  It’s familiar (e.g. in the case of tables) that babel gets to
>> have its own data format for org elements.
> 
> It's the same for lists. Internal representation for lists should come
> from "org-list.el", not from Babel. Internal representation for tables
> comes from "org-table.el", too.

Hmm.  I had missed that, you are correct.

> 
>> I’m happy to undertake the above-described demolition job on
>> org-list-parse-list in order to offset the added complexity from the
>> babel change (we can call it a cap-and-trade system). But given that
>> org-list-parse-list is a marginal part of the code base and perhaps
>> moribund in the era of org-element
> 
> I don't consider radio lists moribund. Are they?

IDK.  You’re probably in a better position to know that than I am.  There’s
only one message even mentioning them (very tangentially) in my 2-ish years
of messages from the list: .
I’m not advocating their removal or deprecation, but they certainly seem
like the tail and not the dog when considering what parts of org ought to
wag what others.

(I’d hope their usefulness would eventually naturally wane as org
becomes compelling enough that people commit to it wholesale, rather
than relying just on the list editing features while living in another
document composition regime.  Whether it’s worth keeping them around
as a sort of training wheels I don’t really have an opinion on.)

> 
>> I don’t really think it’s worth it (to me) to try and engineer an
>> improvement to it in order to enable the babel feature.
> 
> It is not (or should not be) a Babel feature.
> 
> Anyway, it's not about rewriting `org-list-parse-list', but if Babel
> understands a new representation for plain lists, this function should
> be able to generate it and `org-list-to-generic' should be able to
> interpret it.

Why?  Babel’s representation is for babel.
org-list-parse-list/-to-generic’s is for radio lists (although as I’ve
said this connection seems accidental rather than essential).  Babel
calls org-list-parse-list, but I don’t see why it should be forbidden
from doing more processing on the result before passing it along
(indeed, it already does some processing to remove the list type
indicators, remove nested structure, etc.).

> 
> Could you detail the exact specifications of the suggested internal
> plain list representation?

I dunno if I’d call my proposal an “internal plain list representation,”
but rather “babel’s interpretation of plain lists.”

Ordered and unordered lists are lists of strings (exactly as now).
Description lists are lists of 2-element lists, each of the form
(“TERM” “DESCRIPTION”) (unlike now, when they are lists of strings of
the form “TERM :: DESCRIPTION”).

It might be nice to handle nested lists somehow, if a sensible design
can be created, but it looks like babel just discards them currently.
So I propose to leave this unchanged, for the present at least:

#+name: data
- foo
- bar
  - baz
  - quux
- abc

#+begin_src emacs-lisp :var data=data
(pp-to-string data)
#+end_src

#+RESULTS:
: ("foo" "bar" "abc")

-- 
Aaron Ecay

[O] wrapping text around figure

[marvin doyley]

Dear All,

I am writing a grant proposal using Org-mode and I am trying to figure out how 
to wrap text around a figure. I have done this  in the past (latex) using the 
wrapfig function, but it would be nice to do this using #Attr:

Thanks,

Best Wishes,
M 

Re: [O] [patch, ox] #+INCLUDE resolves links

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Okay, I hope I got a better patch here.

Thank you. Some comments follow.

> Nicolas Goaziou  writes:
>> This should be ":only-contents t" or ":only-contents nil".
>> ":only-contents" alone can be tolerated as a shortcut for
>> ":only-contents nil", but that's all.
>
> Okay, I hope I got it now.  It's a rather forgiving regexp in terms of
> mistakes.  Is that OK?

Please no ":only-contents yes", ":only-contents true", ":only-contents
of_course!" in the regexp. If :only-contents is followed by anything but
nil or another keyword, its value is non-nil. See below.

> It doesn't make sense to apply this to source files, right?

Right.

> +elements.}.  If the keyword @code{:only-contents} is used, only the contents
> +of the included element.

The sentence is not complete. Also, it should be something like "If you
set @code{:only-contents} property to a non-nil value, only...".

> For headlines, drawers and properties
> +immediately following the headline will not be included when using
> +@code{:only-contents}.

This is not true anymore about the drawers. This should be merged with
the previous phrase to avoid duplicating "@code{:only-contents}" (e.g.,
only the contents of the matched element are inserted, without any
planning line or property drawer).

>  Some examples:
> +
> +@example
> +#+INCLUDE: "./paper.org::#theory" :only-contents

  #+INCLUDE: "./paper.org::#theory" :only-contents t

> +@smallexample
> +#+INCLUDE: "./otherfile.org::#my_custom_id" :no-contents
> +@end smallexample

  #+INCLUDE: "./otherfile.org::#my_custom_id" :only-contents t

> + (let ((matched (save-match-data
> +  (org-split-string
> +   (org-remove-double-quotes 
> (match-string 1 value)) "::"

There's no reason to use `org-split-string' here since you only want to
match the last "::". You can use the same regexp used by
"org-element.el", i.e.

  (when (string-match "::\\(.*\\)\\'" value)
(setq location (match-string 1 value)
  value (replace-match "" nil nil value)))

> +  (only-contents
> +   (and (string-match
> + 
> ":only-?contents?[[:space:]]*\"?\\(t\\|true\\|yes\\)?\"?"
> + value)
> +(prog1 (and (match-string 1 value) t)
> +  (setq value (replace-match "" nil nil value)

  (only-contents
   (and (string-match ":only-contents +\\([^: \r\t\n]\\S-*\\)" value)
(org-not-nil (match-string 1 value

> +(let ((org-inhibit-startup t)
> +  (lines (org-export--inclusion-absolute-lines
> +  file  location only-contents lines)))

Lines are local to the element only if LOCATION is provided, right?

  (lines (if location
 (org-export--inclusion-absolute-lines ...)
   lines))

> +  (with-temp-buffer
> +(insert-file-contents file)
> +(when location

This check is useless since we know location is defined (otherwise,
this function wouldn't be called).

> +  ;; locations are only defined for org files so
> +  ;; OK to start org-mode.

You can remove this.

> +  (condition-case err
> +   ;; enforce consistency in search.

"Enforce"

> +   (let ((org-link-search-must-match-exact-headline t))
> + (org-link-search location))
> + ;; helpful error messages

You can remove this.

> + (error
> +  (error (format "%s for %s::%s" (error-message-string err) file 
> location
> +  (org-mode)

Shouldn't (org-mode) be moved before calling `org-link-search'? At some
point, `org-link-search' may use Elements.

> +  (narrow-to-region
> +   (org-element-property
> + (if only-contents :contents-begin :begin) (org-element-at-point))
> +   (org-element-property (if only-contents :contents-end :end) 
> (org-element-at-point

  (let ((element (org-element-at-point)))
(let ((contents-beg
   (and only-contents
(org-element-property :contents-begin element
  (narrow-to-region
   (or contents-beg (org-element-property :begin element))
   (org-element-property (if contents-beg :contents-end :end) element

> +(when only-contents
> +  ;; skip drawers and property-drawers
> +  ;; these are removed as needed in `org-export--prepare-file-contents'
> +  ;; TODO: How to actually do this?  Only line numbers are send to
> +  ;; `org-export--prepare-file-contents'.  split in two?
> +  (goto-char (point-min))
> +  (org-skip-whitespace)
> +  (beginning-of-line)
> +  (let ((element (org-element-at-point)))
> + (while (memq (org-element-type element) '(drawer property-drawer))
> +   (goto-char (org-element-property :end element))
> +   (setq element (org-element-at-point)

Regular drawers are not expected to be skipped. Also, the following
should be better

  (when (and 

Re: [O] error exporting with reference to table in another file

[John Kitchin]

Thanks for checking. It turns out to be a silly problem that is my
fault. I extracted attachments out of two different PDF files into the
same directory, and both PDF files had an attachment called
supporting-information.org. So the first one is what had the TiO2-data
table, and it got overwritten by the second file.

So, of course, it was missing ;)

Sorry for the noise.

Aaron Ecay  writes:

> Hi John,
>
> 2014ko irailak 20an, John Kitchin-ek idatzi zuen:
>> 
>> Hi all,
>> 
>> I have this ina n org-file:
>> 
>> 
>> #+NAME: anatase-tio2-elisp
>> #+BEGIN_SRC emacs-lisp :var data=supporting-information.org:TiO2-data
>> (remove-if-not (lambda (x) (string= "anatase" (nth 1 x))) data)
>> #+END_SRC
>> 
>> #+RESULTS: anatase-tio2-elisp
>> | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 |  187.4 |
>> | TiO$_2$ | anatase | AM05   | -2741.12 | 34.33 | 178.26 |
>> | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 |
>> | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 |
>> 
>> The code works fine, but when I try to export to a pdf or html I get errors
>> like:
>> 
>> org-babel-exp processing... [2 times]
>> org-babel-ref-resolve: Reference 'TiO2-data' not found in this buffer
>> 
>> Here is my org-version:
>> 
>> Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpa @
>> /Users/jkitchin/Dropbox/kitchingroup/jmax/elpa/org-20140811/)
>
> FWIW I cannot reproduce this in emacs -Q, even with the same commit checked
> out.  I’m attaching to this message the test files I used, in case anyone
> else wants to try.  I did (setq org-confirm-babel-evaluate nil) before
> doing the export.
>
> #+NAME: anatase-tio2-elisp
> #+BEGIN_SRC emacs-lisp :var data=supporting-information.org:TiO2-data 
> :exports both
>
> data
> #+END_SRC
>
> #+RESULTS: anatase-tio2-elisp
> | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 |  187.4 |
>
> | TiO$_2$ | anatase | AM05   | -2741.12 | 34.33 | 178.26 |
> | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 |
> | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 |
>
> #+name: TiO2-data
> | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 |  187.4 |
>
> | TiO$_2$ | anatase | AM05   | -2741.12 | 34.33 | 178.26 |
> | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 |
> | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 |

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

Re: [O] Exporter dispatcher bug?

[Charles Millar]

Brady Trainor wrote:

Charles Millar  writes:


Today, using C-c C-e, the dispatcher shows only the LaTeX and
Publisher options.


What is the result C-h v org-export-backends?


-- snip --
Its value is (ascii html icalendar latex)
-- snip --

Charlie

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

Re: [O] PATCH: org-mac-link.el: Don't fail on machines without Growl installed

[Steve Purcell]

On 24 Sep 2014, at 20:13, Alan Schmitt  wrote:

> tell application "System Events"
>   set growlHelpers to the name of every process whose creator type 
> contains "GRRR"
>   if (count of growlHelpers) > 0 then
>   set growlHelperApp to item 1 of growlHelpers
>   else
>   set growlHelperApp to ""
>   end if
> end tell
> 
> I get an empty string as returned value. Is is the same for you?


Yes, that part works fine on its own even on my machine. But when the code 
passed to AppleScript includes 'tell application “GrowlHelperApp”’, then the 
code will not execute unless the app is present — there’s a precompilation step 
where, presumably, AppleScript determines that the target application supports 
the listed commands.

-Steve

Re: [O] PATCH: Fix malformed "message" links produced by org-mac-link.el

[Steve Purcell]

On 24 Sep 2014, at 20:01, Alan Schmitt  wrote:

> This was the case here: the string returned by the AppleScript had
> quotes (and it still does).
> 
> For instance, with the message you mention, the call to
> org-as-get-selected-mail returns this (doing a debug):
> 
> Result: "\"message://2.b2af716655bbac583727@NY-WEB01::split::Private beta 
> invitation for Emacs Q&A site - Area 51 - Stack Exchange\””


I definitely don’t get quotes in the result of org-as-get-selected-mail.


> It works well for grabbing a single message, but it breaks when grabbing
> several. Here is one such broken result:
> 
> [[message://9670a832-d0b3-46a8-96bf-05c30d850...@gmail.com][Re: De passage ˆ 
> San Jose"]]
> [["message://4b980c40-db9a-47a7-95a7-17bb8cf81...@gmail.com][Re: De passage ˆ 
> San Jose]]
> 
> The string returned by the AppleScript was this:
> 
> Result: 
> "\"message://4b980c40-db9a-47a7-95a7-17bb8cf81...@gmail.com::split::Re: De 
> passage \210 San 
> Jose\nmessage://9670a832-d0b3-46a8-96bf-05c30d850...@gmail.com::split::Re: De 
> passage \210 San Jose\""
> 
> Does it work on your machine with several messages selected?


Yes, it works correctly, as in the following links to this mail thread:


[[message://m2h9zwzvuz@polytechnique.org][Re: {O} PATCH: Fix malformed 
"message" links produced by org-mac-link.el]]
[[message://m28ul9vxnr@top.irisa.fr][Re: {O} PATCH: Fix malformed "message" 
links produced by org-mac-link.el]]


Not sure how to proceed, then…

-Steve

Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> I think I can remove these three functions (-parse-list, -to-subtree,
> and -to-generic), and rewrite their callers to use org-element.  Thus,
> the org-list-parse-list format would be eradicated from the code base
> incl. contrib (AFAICT).  Can I do that, or do I need to care about
> preserving backwards compatibility with external callers of these
> functions?  If backwards compatibility must be preserved, may I mark
> these functions as deprecated and what is the minimum period (measured
> in calendar time and/or org versions) that should pass before their
> removal?

You cannot do that. This is not about backwards compatibility.

`org-list-parse-list' generates an easy to produce and work on internal
representation for lists (similar to what `org-table-to-lisp' does for
tables). `org-list-to-generic' is used for radio lists (similar to
`org-table-to-generic'): it is expected to consume
a `org-list-parse-list'-like return value.

IOW both functions are important and are not meant to be replaced by
Elements (however, at some point `org-list-to-generic' should use
"ox.el", but that's for another day).

Note that since `org-list-parse-list' is meant for extraneous buffer, it
cannot rely on Elements. It shouldn't even use `org-list-struct' because
I plan to make this function use Elements, too.

> The babel feature is compelling to me (and I guess Chuck) on its
> own.  It’s familiar (e.g. in the case of tables) that babel gets to
> have its own data format for org elements.

It's the same for lists. Internal representation for lists should come
from "org-list.el", not from Babel. Internal representation for tables
comes from "org-table.el", too.

> I’m happy to undertake the above-described demolition job on
> org-list-parse-list in order to offset the added complexity from the
> babel change (we can call it a cap-and-trade system). But given that
> org-list-parse-list is a marginal part of the code base and perhaps
> moribund in the era of org-element

I don't consider radio lists moribund. Are they?

> I don’t really think it’s worth it (to me) to try and engineer an
> improvement to it in order to enable the babel feature.

It is not (or should not be) a Babel feature.

Anyway, it's not about rewriting `org-list-parse-list', but if Babel
understands a new representation for plain lists, this function should
be able to generate it and `org-list-to-generic' should be able to
interpret it.

Could you detail the exact specifications of the suggested internal
plain list representation?


Regards,

-- 
Nicolas Goaziou

Re: [O] PATCH: org-mac-link.el: Don't fail on machines without Growl installed

[Alan Schmitt]

On 2014-09-24 16:35, Steve Purcell  writes:

> Alan Schmitt  writes:
>
>> On 2014-09-24 12:12, Steve Purcell  writes:
>> I'm surprised: I don't have Growl installed and it still works. I agree
>> there is not much point in testing for Growl, though.
>
> I get the system popup asking me to locate the "growlHelperApp"
> program.

Indeed. Digging a little, I found out that I actually have Growl still
installed. I removed it, killed its process, and made sure through the
following AppleScript that it's not found:

tell application "System Events"
set growlHelpers to the name of every process whose creator type 
contains "GRRR"
if (count of growlHelpers) > 0 then
set growlHelperApp to item 1 of growlHelpers
else
set growlHelperApp to ""
end if
end tell

I get an empty string as returned value. Is is the same for you?

But as I said before, I'm fine with removing Growl support, unless
someone objects.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] Exporter dispatcher bug?

[Brady Trainor]

Charles Millar  writes:

>
> Today, using C-c C-e, the dispatcher shows only the LaTeX and
> Publisher options.
>

What is the result C-h v org-export-backends? 


Brady

Re: [O] PATCH: Fix malformed "message" links produced by org-mac-link.el

[Alan Schmitt]

On 2014-09-24 16:42, Steve Purcell  writes:

> Alan Schmitt  writes:
>> I just tested it with the current version and I'm not seeing this
>> problem. Is there something special about that email that breaks, or are
>> you seeing problems with every email?
>
> I see it with every mail. I'm on OS X 10.9.5, but the problem was also
> present on 10.9.4.

I'm also on 10.9.5. I was probably on 10.9.4 when I tweaked that code.

> The "substring" part of the removed code led to the trimming of the
> characters at each end, so it's not clear to me how it could ever have
> worked, unless the output is routinely wrapped in quotes on others'
> machines.

This was the case here: the string returned by the AppleScript had
quotes (and it still does).

For instance, with the message you mention, the call to
org-as-get-selected-mail returns this (doing a debug):

Result: "\"message://2.b2af716655bbac583727@NY-WEB01::split::Private beta 
invitation for Emacs Q&A site - Area 51 - Stack Exchange\""

> Mysterious indeed.
>
> In any case, there were a few blocks of identical-looking code dotted
> around the file: the block appears to have been wisely extracted into
> org-mac-paste-applescript-links, but the duplicate code hasn't been
> replaced with a call to that function. So this patch does so for the
> Mail case, and the same fix should also probably be made in
> org-mac-outlook-message-get-links.

It works well for grabbing a single message, but it breaks when grabbing
several. Here is one such broken result:

[[message://9670a832-d0b3-46a8-96bf-05c30d850...@gmail.com][Re: De passage ˆ 
San Jose"]]
[["message://4b980c40-db9a-47a7-95a7-17bb8cf81...@gmail.com][Re: De passage ˆ 
San Jose]]

The string returned by the AppleScript was this:

Result: "\"message://4b980c40-db9a-47a7-95a7-17bb8cf81...@gmail.com::split::Re: 
De passage \210 San 
Jose\nmessage://9670a832-d0b3-46a8-96bf-05c30d850...@gmail.com::split::Re: De 
passage \210 San Jose\""

Does it work on your machine with several messages selected?

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

[O] Exporter dispatcher bug?

[Charles Millar]

Have I missed an announcement?

Today, using C-c C-e, the dispatcher shows only the LaTeX and Publisher 
options.


I tried M-x org-export-dispatch and HTML was also included.

i have exited emacs and restarted - same results.

Org-mode version 8.3beta (release_8.3beta-400-g200eeb @ 
c:/cygwin/home/Charlie01/.elisp/org-mode/lisp/)


GNU Emacs 24.3.1 (i386-mingw-nt6.0.6002) of 2013-03-17 on MARVIN

Windows Vista SP2

Charlie Millar

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

Re: [O] Fold entirely done subtrees on startup?

[Subhan Michael Tindall]

It's not exactly what you want, but you can add a properties block to the 
subtree:

:PROPERTIES:
:VISIBILITY: folded
:END:
to control its display.  

A little programming could probably automatically insert it on subtrees when 
status moves to DONE
This leaves only no-status entries to deal with



> -Original Message-
> From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org
> [mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On
> Behalf Of Bernd Haug
> Sent: Wednesday, September 24, 2014 3:06 AM
> To: emacs-orgmode
> Subject: [O] Fold entirely done subtrees on startup?
> 
> +STARTUP can show top level headers, all headers, all content or everything.
> 
> I'd like a way to have all subtrees that are DONE or have no todo-status
> folded, but have everything TODO* displayed at startup.
> 
> Is there a way to do that with per-file settings?
> 
> Cheers, Bernd
> 
> * “…or with TODO children”, but I can emulate that well enough with giving
> every path in the trees a status and have org inhibit setting Headers with
> TODO or unchecked children DONE.


This message is intended for the sole use of the individual and entity to which 
it is addressed and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If you are not the intended 
addressee, nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone the 
message or any information contained in the message. If you have received this 
message in error, please immediately advise the sender by reply email and 
delete the message.  Thank you.

Re: [O] Cooperating with oneself using the cloud?

[Monroe, Will]

Phil, et al.

Does anyone have a recommendation for a write up that describes how to 
set up this kind of private syncing with bitbucket or even github?  I've 
seen a worg article on this but some of the technologies described 
(e.g., bzr) are new to me and might not be strictly necessary to achieve 
the syncing that Martin seems to want.


Putting Your org Files Under Version Control
http://orgmode.org/worg/org-tutorials/org-vcs.html

Will

On 9/15/14, 6:06 AM, Phil Mason wrote:

Hi Martin,




That should work if I can find a free Git repository allowing me to keep files 
secret.




I use the free private repos from https://bitbucket.org/ to do something very 
similar to what you require.



All the best



Phil

Re: [O] PATCH: Fix malformed "message" links produced by org-mac-link.el

[Steve Purcell]

Alan Schmitt  writes:
> I just tested it with the current version and I'm not seeing this
> problem. Is there something special about that email that breaks, or are
> you seeing problems with every email?

I see it with every mail. I'm on OS X 10.9.5, but the problem was also
present on 10.9.4.

The "substring" part of the removed code led to the trimming of the
characters at each end, so it's not clear to me how it could ever have
worked, unless the output is routinely wrapped in quotes on others'
machines.

Mysterious indeed.

In any case, there were a few blocks of identical-looking code dotted
around the file: the block appears to have been wisely extracted into
org-mac-paste-applescript-links, but the duplicate code hasn't been
replaced with a call to that function. So this patch does so for the
Mail case, and the same fix should also probably be made in
org-mac-outlook-message-get-links.

-Steve

Re: [O] PATCH: org-mac-link.el: Don't fail on machines without Growl installed

[Steve Purcell]

Alan Schmitt  writes:

> On 2014-09-24 12:12, Steve Purcell  writes:
> I'm surprised: I don't have Growl installed and it still works. I agree
> there is not much point in testing for Growl, though.

I get the system popup asking me to locate the "growlHelperApp"
program.

-Steve

Re: [O] PATCH: org-mac-link.el: Don't fail on machines without Growl installed

[Alan Schmitt]

On 2014-09-24 12:12, Steve Purcell  writes:

> The existing Applescript for grabbing flagged mail messages can only
> work on machines which have Growl installed. This is increasingly
> rarely the case as Growl has been obsoleted by OS X’s own notification
> system.

I'm surprised: I don't have Growl installed and it still works. I agree
there is not much point in testing for Growl, though.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] PATCH: Fix malformed "message" links produced by org-mac-link.el

[Alan Schmitt]

On 2014-09-24 11:39, Steve Purcell  writes:

> Links which should look like:
>
> [[message://2.11f23692084eb783e40c@NY-WEB01][Private beta invitation for 
> Emacs Q&A site - Area 51 - Stack Exchange]]
>
> are currently mangled into:
>
> [[essage://2.11f23692084eb783e40c@NY-WEB01][Private beta invitation for Emacs 
> Q&A site - Area 51 - Stack Exchang]]
>
> This tiny patch fixes this issue.

I just tested it with the current version and I'm not seeing this
problem. Is there something special about that email that breaks, or are
you seeing problems with every email?

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] Cooperating with oneself using the cloud?

[Tim O'Callaghan]

Hi,

I collaborate with myself via dropbox and encfs. encfs does the
encryption, (via  an encrypted fuse filesystem) and dropbox syncs the
encrypted files.

I use it for linux, but it should also work for mac and windows. If i
need to, i can access the files on android using the encfs plugin (who's
name i cannot remember).

I have written a script that i run in my bashrc that auto-mounts the
encrypted dropbox folder for me. It also auto-detects dropbox
conflicts and helps resolve those with encfs.
https://github.com/timoc/encfsbox

I have been using this solution for a few years without it giving too
much trouble :)

Tim.

On 22 September 2014 10:05, Christoph Groth  wrote:
> If at least one of your computers can be reached from all the others via
> ssh, or you can reach all the other computers from one (i.e. there’s a
> star topology), you could use unison to synchronize all kinds of files.
> This works very reliably and handles modifications in both directions.
>
> I use git for my programming projects, but I find that version control
> is not really ideal for simple file synchronization.  This is why I
> think that DVCs (and specifically git) are not a good solution for sync
> (In case that someone is interested in a discussion of these things):
>
> Keeping everything in a single repo is not handy, and solutions (like
> “myrepos”) are kludges.  Another serious problem with using git for
> synchronization is that it’s not able to synchronize git repositories,
> as AFAIK it’s not possible/reasonable to keep git repositories under git
> themselves.  Just imagine the case where you are in the middle of some
> work with a git repo (an interactive rebase, for example), and you’d
> like to sync and continue on another machine.
>
> With unison this works like a charm, you there’s no automatic resolution
> of conflicts.  This is not a problem if you run unison at the beginning
> and at the end of each session.
>
>

Re: [O] resize multiple image within a row or paragraph

[Christian Moe]

Nicolas Goaziou writes:
> Hello,
>
> Christian Moe  writes:
>
>> Here's a simple CSS workaround that might or might not work well for
>> you, and won't work for non-HTML backends, but at least requires minimal
>> hacking: 
>
> [...]
>
> Good to know.
>
> Anyhow, does my proposal make sense?
>
>
> Regards,

Hi,

Sorry, catching up on mail. Also, I misunderstood your proposal when you
wrote it -- I thought it was a suggestion for what the user could
do. But now I realize it's a proposed change to the HTML backend
itself. You wrote:

> `html' back-end can redefine what
> a paragraph is, instead of following Org's own definition. More
> explicitly, an HTML paragraph can be defined as a cluster of elements
> not separated by any blank line and containing at least an Org
> paragraph. Hence:

>   #+attr_html: :width 10%
>   [[./img1.png]]
>   Paragraph
>   #+attr_html: :width 10%
>   [[./img2.png]]

> consists of two paragraphs in Org, but would be seen as a single
> paragraph by HTML, and exported as such.

> Implementation is simple using pseudo-elements. `latex' back-ends does
> it already for tables and math snippets. However, I'm no HTML
> specialist, so there may be drawbacks I cannot foresee.

I'm no expert either. But FWIW, it does make sense to me, and seems
intuitive from an HTML-centric view, since IMG elements
in HTML are basically inline. I think users would expect to have to put
blank lines around an image if they want it wrapped in a paragraph, and
should expect to get in trouble if they did not put blank lines around a
captioned figure.

Yours,
Christian

[O] Follow mode: return to initial buffer after quitting

[Fletcher Charest]

Dear Org community,

When I am editing a buffer, let's called it buffer A, if I want to take a
look at my agenda, this creates a buffer B (*Org Agenda*) in a split
window, next to buffer A:

A | B

I like to activate 'follow mode' when going through the *Org Agenda*
buffer. If I do so, this creates a buffer C (my org file), which is going
to replace buffer A in the view:

C | B

That's fine, so far. However, when I quit my *Org Agenda* buffer by
pressing 'q', I'm watching at buffer C. I would like to look at buffer A
(buffer C should be killed if it wasn't already opened).

Is there any way to accomplish this, just like using :kill-buffer t in
org-capture? I am aware of org-agenda-follow-indirect but this is not what
I want. Sorry if the question was already answered somewhere.

Regards,

FC

Re: [O] [Bug?] Results of code block printed in wrong place

[Tobias Getzner]

On Di, 2014-09-23 at 14:32 -0400, Aaron Ecay wrote: 
> I can reproduce this.
> Babel uses yes-or-no-p to confirm evaluation of the code block on export.
> yes-or-no-p is implemented in C whereas y-or-n-p is in elisp, so it must
> be the case that the lisp code allows some hook to run, which follow-mode
> uses to futz with which buffer/window is current, confusing org-mode.
> The C implementation I guess doesn’t run the same hook.

Thanks for investigating this. That «yes-or-no-p» vs. «y-or-n-p» should
make such a difference is quite bewildering.

> Sounds like the best advice for the moment is “don’t use follow-mode
> with org”.  Maybe it’s worth adding to the section on package conflicts
> in the manual?

Aw, that’s a pity. Given the vertically sparse nature of the tree
outline, follow-mode was quite naturally suited to complement org-mode,
in particular on a wide-screen monitor.

Considering you analysis above, should this be considered a bug in
follow-mode or Emacs core? If so, I could then pass this on to the
appropriate bug tracker.

Though I wonder how «(TeX-source-correlate-mode)» figures into this
(cf. my cross-link in this thread; hooking that mode into AucTeX will
break exporting horribly when both follow-mode and org-mode are active.
I thumbed through tex.el, and while it’s mostly Greek to me, I noticed
that some correlate-related functions also seem to be using y-or-n-p
directly. Follow-mode and plain LaTeX-mode appear to work in
conjunction, though.

Best,
T.

[O] PATCH: org-mac-link.el: Don't fail on machines without Growl installed

[Steve Purcell]

The existing Applescript for grabbing flagged mail messages can only work on 
machines which have Growl installed. This is increasingly rarely the case as 
Growl has been obsoleted by OS X’s own notification system.

-Steve



0001-org-mac-link.el-Don-t-fail-on-machines-without-Growl.patch
Description: Binary data

[O] PATCH: org-mac-link.el: Fix multi-line file description

[Steve Purcell]

The file description line was broken across multiple lines, and therefore 
malformed.

-Steve




0001-org-mac-link.el-Fix-multi-line-file-description.patch
Description: Binary data

[O] PATCH: Fix malformed "message" links produced by org-mac-link.el

[Steve Purcell]

Links which should look like:

[[message://2.11f23692084eb783e40c@NY-WEB01][Private beta invitation for Emacs 
Q&A site - Area 51 - Stack Exchange]]

are currently mangled into:

[[essage://2.11f23692084eb783e40c@NY-WEB01][Private beta invitation for Emacs 
Q&A site - Area 51 - Stack Exchang]]

This tiny patch fixes this issue.

Tested on OS X 10.9.

-Steve



0001-org-mac-link.el-Fix-malformed-message-links.patch
Description: Binary data

[O] Fold entirely done subtrees on startup?

[Bernd Haug]

+STARTUP can show top level headers, all headers, all content or everything.

I'd like a way to have all subtrees that are DONE or have no
todo-status folded, but have everything TODO* displayed at startup.

Is there a way to do that with per-file settings?

Cheers, Bernd

* “…or with TODO children”, but I can emulate that well enough with
giving every path in the trees a status and have org inhibit setting
Headers with TODO or unchecked children DONE.

Re: [O] [patchattached] Store link to url of eww

[Marco Wahl]

Aaron Ecay  writes:

> 2014ko irailak 23an, Rasmus-ek idatzi zuen:
>> I think he did:
>> 
>> Patch:
>>> From: Marco Wahl 
>> 
>> Worg:
>>> 14. Marco Wahl
>
> ...that’s in the section for tinychange contributors without papers on
> file though.

I just initiated the assignment process according to your hint.  AFAICS
it's time for some patience now.  I will tell you when it's done.


Thanks,  Marco
-- 
http://www.wahlzone.de
PGP: 0x0A3AE6F2

Re: [O] ob-R, about :results value verbatim drawer

[Rainer M Krug]

Aaron Ecay  writes:

> Hi Feng,
>
> 2014ko irailak 23an, Feng Shu-ek idatzi zuen:
>> but when I add a #+PROPERTY, it show error like below, how to deal with
>> it ?  thanks ...
>> 
>>   #+PROPERTY: header-args:R :colnames yes :rownames no :exports both
>>   #+BEGIN_SRC R :results value verbatim drawer
>>   data <- 
>> list(a="[[./test1.org]]",b="[[./test2.org]]",c="[[./test3.org]]")
>>   c(data$a,data$b,data$c)
>>   #+END_SRC
>> 
>> 
>>   executing R code block...
>>   Wrote /tmp/babel-1984743i/ob-input-198472lB
>>   org-babel-R-evaluate-external-process: Wrong type argument: listp, "x
>>   [[./test1.org]]
>>   [[./test2.org]]
>>   [[./test3.org]]
>>   "
>
> The simple answer is don’t add the #+property line.  In particular, the
> :colnames yes setting doesn’t play well with your code block.  If you
> must have the #+property line for other reasons, override the global
> setting of :colnames yes with :colnames no on the source block.

And another problem with different ways of setting header arguments.

Is this only a problem of R, or is this general (it does not seem to be
only me...) in org?

The more I think, a proper outline and description is needed how header
arguments for source blocks (probably in general, but I use org mainy
for literate programming and data analysis therefore always including
source code blocks) can be set and how these interact (inheritance, the
+, different ways of setting header arguments as above, ...). These
header arguments are a *very* powerful tool and you can do many things -
but you can also break things very easily.

In many cases, I resort to trial and error: This is working, now I want
to have that behaviour for this code block, normally I would do it like
this, not working, let's try out what is working. But this is far from
ideal and leads to spaghetti-code type property setting which is quite
fragile.

Again: is it only me? I don't think (hope?) so.

So what could be done to remedy this?  I think a few aspects should be
tackeled:

1) a lot of information is in the manual - but spread out in many
   different locations / sections. The first would be to bring these
   sections together and to consolidate them into one section.
2) We need a set of simple and easily to understand examples which
   build on each other. So starting with simple examples and expand
   these to complex examples.
3) These examples should be uaed as tests (maybe there are tests for
   this, but I am not at all familiar with the test framework of org).
4) based on these, the org code should be checked for
   - bugs (obviously)
   - inconsistencies in the approach used for header argument setting
 and inheritance and
   - possibly deprecate certain aspects to simplify it (but keep the
 flexibility which is there at the moment!
5) the property inheritance and hierarchy of different ways of setting
   these should be documented in a structured way. 

So is there anything in this direction? I guess this would be quite a
big task - would there be interest in pursuing this?

Rainer

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


pgpsC8z0z2wpk.pgp
Description: PGP signature

Re: [O] [BUG] Mark-up handling chokes on Unicode white-space

[Tobias Getzner]

Hi Aaron,

On Di, 2014-09-23 at 14:15 -0400, Aaron Ecay wrote:
> org-emphasis-regexp-components is known to be a wart.  You can search
> for posts on the mailing list.  Some people are trying to figure out how
> to get rid of it.  (You can search in particular for Nicolas Goaziou’s
> posts...)  Here’s one thread where you can see the lay of the land:
> .

Thank you for the background info!

> All that to say, the longer-term solution is to figure out some radically
> different approach.  In the meantime though, if you can provide a list of
> characters (by unicode name and/or code point) that you think should be
> added to that variable, someone might be able to add them. 

I guess the straightforward way of defining white-space would be just
using the set of characters with the Unicode property WSpace=Y, and
this would be what «[:space:]», «\s«, etc., should be expected to match
on Unicode-based locales. I’m supplying a list of code-points below,
for convenience.

I agree though that defining what counts as «white space» within the
confines of org-mode is putting the cart before the horse. I’ll try to
ascertain whether the Emacs implementation of «[:space:]» really only
does 8-bit spaces, and if so I’ll see whether I can poke someone on the
Emacs bug tracker about this.

Best regards,
T.


──
List of Unicode white-space

Below is the list of characters with the property White_Space set,
taken from the Unicode 7.0.0 character database. This includes
line-breaking white-space such as «line feed». If these are not
relevant, one can use the subset of space separators (Zs; these do not
include control characters such as Tab) and control chars (Cc).

0009..000D; White_Space # Cc   [5] ..
0020  ; White_Space # Zs   SPACE
0085  ; White_Space # Cc   
00A0  ; White_Space # Zs   NO-BREAK SPACE
1680  ; White_Space # Zs   OGHAM SPACE MARK
2000..200A; White_Space # Zs  [11] EN QUAD..HAIR SPACE
2028  ; White_Space # Zl   LINE SEPARATOR
2029  ; White_Space # Zp   PARAGRAPH SEPARATOR
202F  ; White_Space # Zs   NARROW NO-BREAK SPACE
205F  ; White_Space # Zs   MEDIUM MATHEMATICAL SPACE
3000  ; White_Space # Zs   IDEOGRAPHIC SPACE
──