Re: [O] [bug] org 9 hangs on link search

2016-12-17 Thread Samuel Wales
On 12/17/16, Nicolas Goaziou  wrote:
> Currently Org has no satisfactory way to handle square brackets within
> links' path or description. Percent-escaping (e.g., "%5B")is not one.

hmm.  seems links are not, or at least not yet, a complete syntactic solution.

> I suggest to use a custom ID for the time being.

i do but i don't want to clutter org with properties drawers.  i
already have a lot of ids and when org needs to search them it can
take some time.

basically i use non-id links for ephemeral tasks or to point to
ephemeral tasks.  i know i won't change the headers, but i want the
links there.

>> ("n" "note" entry (file+headline ,todo "xyzzy-remember")
>>  ;; unrelated issue is if i do spc bef and after ? then
>>  ;; double space; else ret will follow link.  i make
>>  ;; capture not follow.
>>  "* %?%a\n%i")
>
> If you think there is another bug, please start another thread and
> provide as much information as you can.

nah, making capture not follow is sufficient.  i don't know the
optimal solution.



Re: [O] allow live execution of code snippets in html export

2016-12-17 Thread Yehonathan Sharvit
Done

On Thu, 15 Dec 2016 at 22:55 Yehonathan Sharvit  wrote:

> On Thu, Dec 15, 2016 at 5:50 PM, Matt Price  wrote:
>
>
>
> On Thu, Dec 15, 2016 at 5:07 AM, Bastien  wrote:
>
> Hi Matt,
>
> Matt Price  writes:
>
> > Would we need a switch to permit the old syntax for people with
> > complex setups who don't want to change?
>
> Yes.  We need to be more careful on being backward compatible.
>
> The new patch in that other thread does this.
>
>
> > - make src-clojure in  customizable
> > ?
> >
> > Is this likely to break anything in derived exporters? It would
> > certianly be convenient e.g for using highlight.js in wordpress in
> > similar environments.
>
> Yes.
>
>
>
> > This seems like a good idea and pretty easy.
>
> I will think more about this.
>
> > I odn't really quite understand the problem and solution parameters.
> > Since Yehonathan is here on this thread and enthusiastic about
> > helping out: is there something he could do to make this feasible for
> > us?  Or by "more general mechanism" do you mean some third way
> > between bundling and linking to?
>
> One way to solve this on Yehonathan's side is to update klipse.js and
> follow the instruction on librejs on how to make librejs accept the js
> code as "safe":
>
> https://www.gnu.org/software/librejs/free-your-javascript.html
>
> I don't know how much work is involved in this, though.
>
>
> I think you just have to add two lines to non-minified scripts, and one
> more to minified scripts:
>
> https://www.gnu.org/software/librejs/free-your-javascript.html#magnet-link-license
>
> Yehonathan, would you bewilling to do this?
>
> ​Sure. Will do it tomorrow.​
>
>
>
>
>
> --
>  Bastien
>
>
>
>


[O] Android org app with sync?

2016-12-17 Thread Alasdair McAndrew
I'm sure this has been asked and answered many times before, but 
I've hunted about - both on the web and on Google Play - to find 
some app which can sync with my org files.  The closest I've come 
is orgzly:


https://play.google.com/store/apps/details?id=com.orgzly

which however only syncs with Dropbox, which I don't use (I use a 
self-hosted ownCloud instead).


Are there any other apps which will allow me to update and edit 
org files on my android device, and have them sync automatically?


I guess I can probably use orgzly with a local file, and have a 
third party app sync with my ownCloud files.  Seems like extra 
fuss, though!


Thanks,
Alasdair



[O] Remove Org from Emacs repository?

2016-12-17 Thread Reuben Thomas
Now that Emacs has had package.el for some years, and Org is installable
directly from GNU ELPA, would it be a good idea to remove Org from Emacs's
source repository?

The current situation is left over from before Emacs had package.el, and I
see no compelling reason to keep it. Org is too big and distinct to be
swallowed by Emacs; it doesn't make much sense to keep its current half-in,
half-out state; so logically it seems sensible to take it out.

I am asking this question from an Org point of view; I will ask the Emacs
maintainers separately for their perspective.

I think it would benefit Emacs too, as there would be less code to maintain
(even though Org is quasi-external at present, it still has to build
successfully as part of an Emacs build), and the Emacs distribution would
be slimmer for non-Org users.

Of course, Emacs "distributions" would still be able to include Org
out-of-the box if they wished.

-- 
http://rrt.sc3d.org


[O] RFC: ob-sql-mode.el: Use sql-mode with Org Babel

2016-12-17 Thread Nik Clayton
Hoi,

I'd like to solicit feedback on ob-sql-mode.el,
https://github.com/nikclayton/org-mode/commit/106b22e9ef4835e15efc47d63aaeee675a1ebb69
.

This introduces a new Org Babel language, "sql-mode". Unlike the current
"sql" language, this one uses sql-mode to manage the interaction with the
SQL interpreters, so it supports all the backends that sql-mode supports.

It also supports sessions, so you can have different src blocks connected
to different databases or configurations in that database.

If you have, for example, "sqlite" installed on your system, you can put
the following (rather trivial) query in an Org file and evaluate it in the
usual way

#+BEGIN_SRC sql-mode :product sqlite
SELECT 1, 2, 3;
#+END_SRC

The evaluation result will look like

#+RESULTS:
: 1|2|3


Org property headers and drawers are also supported, so you could omit the
:product argument if you had

#+PROPERTY: header-args:sql-mode :product sqlite

or a property drawer that looked like

:PROPERTIES:
:header-args: :product sqlite
:END:

in scope.

​I'm about to go on vacation for a few weeks, so won't have the chance to
respond to feedback until early January, but I wanted to get this out
there. I'm releasing this in my capacity as a Google employee, and Google
has a copyright assignment on file with the FSF.​

Best, ​N
-- 
Google Switzerland GmbH, Identifikationsnummer: CH-020.4.028.116-1


Re: [O] [bug] org 9 hangs on link search

2016-12-17 Thread Nicolas Goaziou
Hello,

Samuel Wales  writes:

> * bug
> *** 
> [[file:$dorg/executive--a.org::*%5B%5Bfile:$dorg/executive--a.org::*test%5D%5Btest%5D%5D][test]]
> link to next header
> captured
> says no match for fuzzy expression
> *** [[file:$dorg/executive--a.org::*test][test]]
> works
> *** test
> *** template

Currently Org has no satisfactory way to handle square brackets within
links' path or description. Percent-escaping (e.g., "%5B")is not one.

I suggest to use a custom ID for the time being.

> i substituted $dorg but would prefer it to
> literally put "$dorg".
>
> ("n" "note" entry (file+headline ,todo "xyzzy-remember")
>  ;; unrelated issue is if i do spc bef and after ? then
>  ;; double space; else ret will follow link.  i make
>  ;; capture not follow.
>  "* %?%a\n%i")

If you think there is another bug, please start another thread and
provide as much information as you can.

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: Incorrect result of exporting info link [9.0.1 (release_9.0.1-143-g469103 @ /home/xcy/src/org-mode/lisp/)]

2016-12-17 Thread Nicolas Goaziou
Hello,

徐春阳  writes:

> At (info "(emacs) Echo Area"), 'M-x org-store-link' stores the link as:
>
> [[info:emacs#Echo%20Area][info:emacs#Echo Area]]
>
> however org doesn't export it correctly, for example, the result of html
> export is:
>
>  href="http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Echo-Area;>  
> href="http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Echo;>emacs#Echo
>  Area
>
> the correct result should be:
>
>  href="http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Echo-Area;>emacs#Echo
>  Area
> and the result of ASCII export is:
>
> [[info:emacs#Echo] Area]
> [[info:emacs#Echo] Area] info:emacs#Echo%20Area
>
> the correct result should be:
>
> [info:emacs#Echo Area]
> [info:emacs#Echo Area] info:emacs#Echo%20Area
>
> I tried to debug this by inserting
>
> (message "-> org-info-export: path: [%s] desc: [%s]" path desc)
>
> at the beginning of org-info-export, then export, it shows
>
> -> org-info-export: path: [emacs#Echo] desc: [nil]
> -> org-info-export: path: [emacs#Echo Area] desc: [[info:emacs#Echo] Area] [2 
> times]
>
> It looks like one info link is exported three times.

It's not really a bug in the exporter, but rather a poor parser design
decision. Basically "info:emacs#Echo" is a valid link in Org, even as
a description of another link.

I removed nested links in parser. Instead I added a tool in "ox.el",
namely `org-export-insert-image-links' to add them whenever a back-end
can make use of them.

I made that change in master. So, the issue should be fixed there.

Thank you.

Regards,

-- 
Nicolas Goaziou



[O] RFC: ob-sql-mode.el: Use sql-mode with Org Babel

2016-12-17 Thread Nik Clayton
Hoi,

I'd like to solicit feedback on ob-sql-mode.el, https://github
.com/nikclayton/org-mode/commit/106b22e9ef4835e15efc47d63aaeee675a1ebb69.

This introduces a new Org Babel language, "sql-mode". Unlike the current
"sql" language, this one uses sql-mode to manage the interaction with the
SQL interpreters, so it supports all the backends that sql-mode supports.

It also supports sessions, so you can have different src blocks connected
to different databases or configurations in that database.

If you have, for example, "sqlite" installed on your system, you can put
the following (rather trivial) query in an Org file and evaluate it in the
usual way

#+BEGIN_SRC sql-mode :product sqlite
SELECT 1, 2, 3;
#+END_SRC

The evaluation result will look like

#+RESULTS:
: 1|2|3


Org property headers and drawers are also supported, so you could omit the
:product argument if you had

#+PROPERTY: header-args:sql-mode :product sqlite

or a property drawer that looked like

:PROPERTIES:
:header-args: :product sqlite
:END:

in scope.

​I'm about to go on vacation for a few weeks, so won't have the chance to
respond to feedback in detail until early January, but I wanted to get this
out there. I'm releasing this in my capacity as a Google employee, and
Google has a copyright assignment on file with the FSF.​

Best, ​N
-- 
Google Switzerland GmbH, Identifikationsnummer: CH-020.4.028.116-1