Re: [O] "#+begin_src R :results output drawer" doesn't work.

[Aaron Ecay]

Hi Feng,

2014ko abuztuak 9an, Feng Shu-ek idatzi zuen:
> 
> #+begin_src R :results output drawer
> "1"
> "2"
> #+end_src
> 
> #+RESULTS:
> : 2
>

Like Eric, I cannot reproduce this behavior.  Can you send us the output
of the following code block, to check the exact version of org that is
giving you this unexpected result?

#+BEGIN_SRC emacs-lisp
  (org-version nil t)
#+END_SRC

Thanks,

-- 
Aaron Ecay

Re: [O] Feature request: copy cell contents into kill ring

[Aaron Ecay]

Hi Andrea,

2014ko abuztuak 11an, Andrea Rossetti-ek idatzi zuen:
> 
> Hello everone,
> 
>   copying a table cell (C-c C-x M-w) uses a private clipboard, as stated
> by the `org-table-copy-region' docstring. Sometimes it's handy to paste
> a cell's text into something that isn't an org-table (my use case was:
> record a macro to perform some silly updates in bbdb, once per table row).
> 
>   My quick-and-dirty solution was the following:
> 
> 
>   but I believe a "copy cell to kill ring" would be a nice Org feature
> to add (maybe bound to C-u C-c C-x M-w). Before digging any further,
> may I please ask for opinions and advice: would it make sense for you
> too? not worth it? or is this already possible with some different
> keystroke?

Another option might be to create (or adapt) a keybinding to mark the
contents of the current table cell, which could then be followed with
M-w (kill-ring-save).  This would be more general (since you can also
e.g. delete the contents of the cell after marking it), and also not
require more keystrokes (as long as you can find a binding of 3 keys or
less for the mark-cell command).

-- 
Aaron Ecay

Re: [O] org-table: missing vertical boundary when exported

[Shiyuan]

Rick,
   Do you mean that   and 
don't mean the same thing? Their names suggest they do the same things.
That's a terrible naming. Changing the former to the latter does fix the
problem though. Why is that?

Using the #+HTML_HEAD_EXTRA options as you suggest can also fix the
problem. But could you explain why using the HTML_HEAD_EXTRA is more
advisable than setting the  directly as table
attributes? What would you suggest if we want some tables have orders and
others don't have borders in the same html webpage?

Thank you.

Shiyuan


>Org mode generated this line in the html for table but the border is
> not
> >displayed,Â
> > >frame="hsides">
>
> The "border" attribute has nothing to do with it. It's the "frame"
> attribute
> which sets the default top and bottom borders.
>


> >If we use css style to specify the border, Â the table border would
> show
> >up:Â
> > rules="groups"
> >frame="hsides">
>
> No. The CSS should be in the header, not an attribute of the tag. Have you
> tried setting the 'HTML_HEAD_EXTRA' option?  somehting like:
> #+HTML_HEAD_EXTRA: 
> #+HTML_HEAD_EXTRA: table {border-left: 1px solid black; border-right: 1px
> solid black;}
> #+HTML_HEAD_EXTRA: 
>
>
> rick
>

Re: [O] [PATCH] Fix and optimize publishing cache check

[Matt Lundin]

Here is an improved version of the previous patch (please apply it
rather than the previous). This version further optimizes cache checking
by only calling find-buffer-visiting if necessary. (It also fixes some
long lines.) On a test project containing 5000 files, running
org-publish on the project with the cache enabled now takes seconds
rather than minutes.

Best,
Matt

>From ea7203b4d988967f0a70bd45ad7502a961a28aee Mon Sep 17 00:00:00 2001
From: Matt Lundin 
Date: Tue, 12 Aug 2014 23:25:23 -0500
Subject: [PATCH] Fix and optimize publish cache check

* lisp/ox-publish.el: (org-publish-cache-file-needs-publishing) Fix
  org-publish-cache-file-needs-publishing to change timestamp of files
  containing includes. Speed up check for includes by storing
  information about included files in cache itself.

This patch ensures that org-publish-cache-file-needs-publishing does
not keep publishing a file containing includes by updating the
modification time of that file. It also speeds up publishing by
caching information about included files, thus keeping
org-publish-cache-file-needs-publishing from having to visit every
file just to check includes (which can take a long time on a project
containing hundreds or thousands of files).
---
 lisp/ox-publish.el | 68 --
 1 file changed, 41 insertions(+), 27 deletions(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index df40572..e848a0c 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -1167,33 +1167,47 @@ the file including them will be republished as well."
 	 (key (org-publish-timestamp-filename filename pub-dir pub-func))
 	 (pstamp (org-publish-cache-get key))
 	 (org-inhibit-startup t)
-	 (visiting (find-buffer-visiting filename))
-	 included-files-ctime buf)
-(when (equal (file-name-extension filename) "org")
-  (setq buf (find-file (expand-file-name filename)))
-  (with-current-buffer buf
-	(goto-char (point-min))
-	(while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t)
-	  (let* ((element (org-element-at-point))
-		 (included-file
-		  (and (eq (org-element-type element) 'keyword)
-		   (let ((value (org-element-property :value element)))
-			 (and value
-			  (string-match "^\\(\".+?\"\\|\\S-+\\)" value)
-			  (org-remove-double-quotes
-			   (match-string 1 value)))
-	(when included-file
-	  (add-to-list 'included-files-ctime
-			   (org-publish-cache-ctime-of-src
-			(expand-file-name included-file))
-			   t)
-  (unless visiting (kill-buffer buf)))
-(if (null pstamp) t
-  (let ((ctime (org-publish-cache-ctime-of-src filename)))
-	(or (< pstamp ctime)
-	(when included-files-ctime
-	  (not (null (delq nil (mapcar (lambda (ct) (< ctime ct))
-	   included-files-ctime))
+	 (ctime (org-publish-cache-ctime-of-src filename))
+	 (needsp (or (null pstamp) (< pstamp ctime)))
+	 includes)
+;; if the file needs publishing, refresh the included-files cache property
+(when (and needsp
+	   (equal (file-name-extension filename) "org"))
+  (let ((visiting (find-buffer-visiting filename))
+	(buf (find-file-noselect (expand-file-name filename
+	(with-current-buffer buf
+	  (save-excursion
+	(goto-char (point-min))
+	(while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t)
+	  (let* ((element (org-element-at-point))
+		 (included-file
+		  (and (eq (org-element-type element) 'keyword)
+			   (let ((value (org-element-property :value element)))
+			 (and value
+  (string-match "^\\(\".+?\"\\|\\S-+\\)" value)
+  (org-remove-double-quotes
+   (match-string 1 value)))
+		(when included-file
+		  (add-to-list 'includes (expand-file-name included-file)))
+	(unless visiting (kill-buffer buf))
+	(when includes
+	  (org-publish-cache-set-file-property filename :includes includes
+;; return t if needsp or if included files have changed
+(or needsp
+	(when (delq nil
+		(mapcar (lambda (file)
+			  (let ((ct (org-publish-cache-ctime-of-src file)))
+(and (file-exists-p file)
+ (< ctime ct
+			(org-publish-cache-get-file-property filename :includes)))
+	  ;; update the timestamp of the published file if buffer is not modified
+	  (let ((visiting (find-buffer-visiting filename))
+		(buf (find-file-noselect (expand-file-name filename
+	(with-current-buffer buf
+	  (when (not (buffer-modified-p))
+		(set-buffer-modified-p t) (save-buffer)))
+	(unless visiting (kill-buffer buf)))
+	  t
 
 (defun org-publish-cache-set-file-property
   (filename property value &optional project-name)
-- 
2.0.4



Matt Lundin  writes:

> This patch does two things:
>
> 1. It prevents org-publish from perpetually republishing files
> containing includes. Currently, if an included file changes, it is
> published, as is the file that includes it. However, until changes are
> made in the file that includes it (which may be never) its modification

Re: [O] Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

That seems reasonable to me.

-- 
Ashton Kemerling

Re: [O] Some thoughts on MobileOrg and its development ....

[Alexis]

David Wagle writes:

> What's involved in 'rebooting' the project?

My thought involves starting from scratch. Say we use Cordova (i can't
speak to the pros and cons of Cordova vs. Kivy in terms of things like
functionality provided, possible barriers to contribution etc.). Cordova
takes care of a certain amount of the (semi-)boilerplate code needed for
each platform; and of the remainder of the code, the core functionality
would need to get reimplemented in HTML/CSS/JavaScript, with 'shims'
being created between this code and the surrounding platform-specific
code. Consequently, i think there would likely be very little use of
most of the code in either current MobileOrg project.


Alexis.

Re: [O] Some thoughts on MobileOrg and its development ....

[Alexis]

Ashton Kemerling writes:


> I can say for certain that we would have to figure out the handoff of
> various credentials from the old maintainers (who I am assuming would
> not like to continue being maintainers) for the respective app-stores
> and Dropbox tokens.

Not necessarily. One could, for example, create an entirely new project
on GitHub called 'MobileOrgRebooted', and create entirely new apps in
the respective stores using that name. (As it is, there's not a
uniformly named app in any case - we have 'MobileOrg' for iOS, and
'MobileOrg-Android' for, well, Android.) And it certainly seems to me
that it would be best to start the actual coding of the reboot /first/,
and only worry about naming rights issues if and when it takes
off. Doing otherwise is likely to bring into play another possible
obstacle to getting actual implementation happening.


Alexis.

Re: [O] Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

David Wagle  writes:

> What's involved in 'rebooting' the project? Are the various owners of
> the iPhone and Android packages on this list? 
>
> I'm not a coder at all, but I've administratively managed software
> projects before. I'm more than happy to do what I know how to do --
> which is mostly send out emails asking people if they can help do stuff? 
>
> On Tue, Aug 12, 2014 at 8:07 PM, Ashton Kemerling
>  wrote:
>
> I did some digging into that a few months ago. While I'm not an
> experienced iOS dev, I flailed about for a few weeks trying to add
> deadline parsing and failed miserably.
> 
> I'm fairly convinced that most of the code is either super platform
> specific or in need of replacing with easier to maintain & test
> components.
> 
> 
> --
> Ashton Kemerling
> 
>
>

Honestly, I don't know exactly what would be involved, I'm not
experienced in mobile and I don't have anywhere near the spare bandwidth
to be anything other than a secondary contributor. I do suspect that a
lot of existing code would be thrown away in a combined approach due to
the massive semantic and structural differences between native code and
HTML/JS/CSS.

I can say for certain that we would have to figure out the handoff of
various credentials from the old maintainers (who I am assuming would
not like to continue being maintainers) for the respective app-stores
and Dropbox tokens. 

-- 
Ashton Kemerling

Re: [O] Some thoughts on MobileOrg and its development ....

[David Wagle]

What's involved in 'rebooting' the project? Are the various owners of the
iPhone and Android packages on this list?

I'm not a coder at all, but I've administratively managed software projects
before. I'm more than happy to do what I know how to do -- which is mostly
send out emails asking people if they can help do stuff?


On Tue, Aug 12, 2014 at 8:07 PM, Ashton Kemerling  wrote:

> I did some digging into that a few months ago. While I'm not an
> experienced iOS dev, I flailed about for a few weeks trying to add
> deadline parsing and failed miserably.
>
> I'm fairly convinced that most of the code is either super platform
> specific or in need of replacing with easier to maintain & test
> components.
>
>
> --
> Ashton Kemerling
>
>

Re: [O] Some thoughts on MobileOrg and its development ....

[Ashton Kemerling]

I did some digging into that a few months ago. While I'm not an
experienced iOS dev, I flailed about for a few weeks trying to add
deadline parsing and failed miserably. 

I'm fairly convinced that most of the code is either super platform
specific or in need of replacing with easier to maintain & test
components. 


-- 
Ashton Kemerling

Re: [O] babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

Le 12/08/2014 16:24, Ernesto Durante a écrit :
> Hi Thierry,
>
> Thanks you but I don't know who is responsible to apply the patch.
I have been in touch with Eric Schulte and Bastien Guerry who are both
maintainers. Probably Eric is the right person, as he is very involved
in all Babel subjects.

I am not aware of any criteria for accepting a contribution.
Contributions are always welcome. Sending them to the mailing list (as
you did) is the best way to discuss them.

> As you are a contributor and author of ob-C, maybe you know how to proceed. 
You may want to read this page: http://orgmode.org/worg/org-contribute.html

Your patch seems to change less than 15 lines. If this is confirmed,
then your proposal falls in the "tiny change" category. "Tiny changes"
do not need the "assignment contract with the FSF".

However you may want to sign the assignment with the FSF anyway if you
intend to contribute more. (The Free Software Foundation holds the
copyright for Gnu Emacs, Org-mode being part of Emacs). I signed the
assignment. It took several weeks. It covers any future contribution I
may submit.

Technically, the best way to submit your patch is to generate a file
with the "git format-patch" command, then send it to the mailing list.
Obviously you are familiar with Git. Otherwise, read the explanations in
the aforementioned page. You will need to pay attention to the commit
message you will write, in order to be consistent with all other commit
messages.
>
> I have identified a minor bug. When a source code block has the mode
> cpp, we cannot expand the code or more precisely the code is not
> expanded in the correct way because the following function is missing  
>
> (defun org-babel-expand-body:cpp (body params)
>   "Execute BODY according to PARAMS.This function calls 
> `org-babel-expand-body:C++'."
>   (org-babel-expand-body:C++ body params))
Thanks for reporting this ! You may consider submitting a patch for this
bug. The comment "Execute BODY ..." should be changed to "Expand BODY ...".

>
> Best
> Ernesto
You are very welcome
Thierry

Re: [O] A gentle introduction to Emacs & Org-mode?

[Nick Dokos]

David Ongaro  writes:

> John Kitchin  andrew.cmu.edu> writes:
>
>> jorge.a.alfaro  gmail.com (Jorge A. Alfaro-Murillo) writes:
>> 
>> thanks for point that out, I have fixed them now I think. That must be
>> from some link escaping in the translation of org to html I guess. 
>
> No, the problem happens during org-insert-link, so even before
> it's exported anywhere. I had to patch my org.el to fix the
> org-link-escape-chars variable. Maybe it should be fixed in the
> standard distribution, because its a really annoying and
> unexpected behaviour.
>
> Regards,
>
> David
>
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 3e83043..3bca94a 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -9777,8 +9777,8 @@ according to FMT
> "]"))
>  
>  (defconst org-link-escape-chars
> -  ;;%20 %2B %3B %3D %5B %5D
> -  '(?\  ?\+ ?\; ?\= ?\[ ?\])
> +  ;;%20 %2B %3B %5B %5Dnn
> +  '(?\  ?\+ ?\; ?\[ ?\])
>"List of characters that should be escaped in link.
>  This is the list that is used for internal purposes.")

That has already happened: on the master branch, org-link-escape-chars
is (see commit abe931dca9c4c634fe9495eff7579ca952eb8b98):

,
| (defconst org-link-escape-chars
|   ;;%20 %5B %5D
|   '(?\  ?\[ ?\])
|   "List of characters that should be escaped in a link when stored to Org.
| This is the list that is used for internal purposes.")
`

It's going to be visible in the next release.

Nick

Re: [O] A gentle introduction to Emacs & Org-mode?

[David Ongaro]

John Kitchin  andrew.cmu.edu> writes:

> jorge.a.alfaro  gmail.com (Jorge A. Alfaro-Murillo) writes:
> 
> thanks for point that out, I have fixed them now I think. That must be
> from some link escaping in the translation of org to html I guess. 

No, the problem happens during org-insert-link, so even before
it's exported anywhere. I had to patch my org.el to fix the
org-link-escape-chars variable. Maybe it should be fixed in the
standard distribution, because its a really annoying and
unexpected behaviour.

Regards,

David


diff --git a/lisp/org.el b/lisp/org.el
index 3e83043..3bca94a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9777,8 +9777,8 @@ according to FMT
  "]"))
 
 (defconst org-link-escape-chars
-  ;;%20 %2B %3B %3D %5B %5D
-  '(?\  ?\+ ?\; ?\= ?\[ ?\])
+  ;;%20 %2B %3B %5B %5Dnn
+  '(?\  ?\+ ?\; ?\[ ?\])
   "List of characters that should be escaped in link.
 This is the list that is used for internal purposes.")

Re: [O] [PATCH] docstring improvement of org-agenda-refile

[Daimrod]

Charles Millar  writes:

> Charles Millar wrote:
>> Daimrod wrote:
>>> +When GOTO is '(14) or \\[universal-argument]
>>> \\[universal-argument], go to the location of the last refiled
>>> item.
>> ^^
>>  '(16)
> Just opened my own reply and the '(16) may be misaligned.

Good catch.

I've applied the patch with the correction.

--
Daimrod/Greg

[O] Help: How to keep/set fontification when switching agenda to columns view

[Subhan Michael Tindall]

I have a custom agenda I'm using that I need the extra information available 
from switching to columns view (C-c C-x C-c)
When I'm in agenda mode, TODO keywords are highlighted, priorities, links, etc.
However, when I switch to column view all the highlighting goes away
I tried using hi-lock-mode, which when called in column view went off somewhere 
and required a C-g to stop whatever it was doing. When returning from column 
view to the regular agenda view, the strings matching the regexp where 
highlighted.  Didn't do a thing to the table though.
I'm not sure where to go from here, any suggestions?  I'd be happy if I could 
highlight by column, even happier if I could highlight by regexp
Thanks for any help that can be offered!
Subhan



Subhan Michael Tindall
Program Analyst - FamilyCare Health Plans
825 NE Multnomah St, Suite 1400; Portland OR 97232
Direct: 503-471-3127
Fax:  503-471-3177
Email:  subh...@familycareinc.org
[Email-Signature-Logos June 20143]


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] Need info about code block header arguments in (HTML) export

[Rick Frankel]

On 2014-08-11 10:58, Avdi Grimm wrote:

Hi there, Org experts!

I write books in org-mode, and one of the features I've really started
to need is to be able to automatically include filename information
when exporting source code listings. That is, given some Org source
like this:

    #+BEGIN_SRC ruby :tangle foo/bar.rb
      puts "hello, world"
    #+END_SRC

...the final HTML might look something like this:

    
    foo/bar.rb



Currently, you can acheive similar html output by using the
`#+CAPTION' header argument;

#+CAPTION: foo/bar.pl
#+BEGIN_SRC perl :exports code
print "foo\n";
#+END_SRC

which would generate this html:

#+BEGIN_SRC html

foo/bar.pl
print 
"foo\n";



#+END_SRC

I don't see a way to get the `:tangle' keyword during export, as the
parser does not include that in list passed to the src-block export
function.


rick

Re: [O] babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Thierry Banel  writes:

> Le 04/08/2014 18:16, Ernesto Durante a écrit :
>> One suggestion. It will be nice to put the error buffer in
>> compilation-mode, this way errors are highlighted and we can jump
>> directly into the source code. I modified org-babel-eval to launch the
>> compilation mode in case of errors. I also removed the read-only
>> attribute, else the buffer content of org-babel-error-buffer-name cannot
>> be erased.
> The compilation mode is a very good idea !
> I tried it.
>
>>
>> Clearly, it's not a good patch because org-babel-eval seems to be
>> a core function in babel. Maybe for ob-C, this function should be
>> replaced by a new function. 
> It works well for C++, D, Dot
> It fails for Perl, R, Elisp
> But when it fails, it does not do any harm: the behavior is as before.
> So... I vote for your patch.

Hi Thierry,

Thanks you but I don't know who is responsible to apply the patch.
As you are a contributor and author of ob-C, maybe you know how to proceed. 

I have identified a minor bug. When a source code block has the mode
cpp, we cannot expand the code or more precisely the code is not
expanded in the correct way because the following function is missing  

(defun org-babel-expand-body:cpp (body params)
  "Execute BODY according to PARAMS.This function calls 
`org-babel-expand-body:C++'."
  (org-babel-expand-body:C++ body params))


Best
Ernesto

[O] [PATCH] Fix and optimize publishing cache check

[Matt Lundin]

This patch does two things:

1. It prevents org-publish from perpetually republishing files
containing includes. Currently, if an included file changes, it is
published, as is the file that includes it. However, until changes are
made in the file that includes it (which may be never) its modification
time remain older than that of the included file, so it will be
republished every time org-publish is called, even if neither file has
changed. 

   - Note: This patch fixes this behavior by updating the modification
 time of the file that contains the includes. If this is deemed too
 destructive/meddlesome, we could consider alternate behaviors, such
 as setting the cached time with a simple float-time. Let me know
 what would be best.

2. It optimizes checking for included files. Currently,
org-publish-cache-file-needs-publishing visits every file in a project
to check for includes. On my underpowered box, this takes a long time
(over a minute) on a project with 1000+ files, thus defeating the
purpose of the cache. This patch causes org-publish to store information
about included files in the cache itself:

  a. If a file has changed it updates information about the files it
  includes and stores it in the cache.

  b. If a file has not changed, it checks the cache for included files
  and sees if any of those files have been updated (thus preventing the
  need to check every file in the project for includes)

Best,
Matt

>From 94a8061bb30e1992213fb8e71ee949d336d37435 Mon Sep 17 00:00:00 2001
From: Matt Lundin 
Date: Tue, 12 Aug 2014 07:51:44 -0500
Subject: [PATCH] Fix and optimize publish cache check

* lisp/ox-publish.el: (org-publish-cache-file-needs-publishing) Fix
  org-publish-cache-file-needs-publishing to change timestamp of files
  containing includes. Speed up check for includes by storing
  information about included files in cache itself.

This patch ensures that org-publish-cache-file-needs-publishing does
not keep publishing a file containing includes by updating the
modification time of that file. It also speeds up publishing by
caching information about included files, thus keeping
org-publish-cache-file-needs-publishing from having to visit every
file just to check includes (which can take a long time on a project
containing hundreds or thousands of files).
---
 lisp/ox-publish.el | 60 +++---
 1 file changed, 35 insertions(+), 25 deletions(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index df40572..228411f 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -1168,32 +1168,42 @@ the file including them will be republished as well."
 	 (pstamp (org-publish-cache-get key))
 	 (org-inhibit-startup t)
 	 (visiting (find-buffer-visiting filename))
-	 included-files-ctime buf)
-(when (equal (file-name-extension filename) "org")
-  (setq buf (find-file (expand-file-name filename)))
+	 (ctime (org-publish-cache-ctime-of-src filename))
+	 (needsp (or (null pstamp) (< pstamp ctime)))
+	 includes buf)
+;; if the file needs publishing, refresh the included-files cache property
+(when (and needsp
+	   (equal (file-name-extension filename) "org"))
+  (setq buf (find-file-noselect (expand-file-name filename)))
   (with-current-buffer buf
-	(goto-char (point-min))
-	(while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t)
-	  (let* ((element (org-element-at-point))
-		 (included-file
-		  (and (eq (org-element-type element) 'keyword)
-		   (let ((value (org-element-property :value element)))
-			 (and value
-			  (string-match "^\\(\".+?\"\\|\\S-+\\)" value)
-			  (org-remove-double-quotes
-			   (match-string 1 value)))
-	(when included-file
-	  (add-to-list 'included-files-ctime
-			   (org-publish-cache-ctime-of-src
-			(expand-file-name included-file))
-			   t)
-  (unless visiting (kill-buffer buf)))
-(if (null pstamp) t
-  (let ((ctime (org-publish-cache-ctime-of-src filename)))
-	(or (< pstamp ctime)
-	(when included-files-ctime
-	  (not (null (delq nil (mapcar (lambda (ct) (< ctime ct))
-	   included-files-ctime))
+	(save-excursion
+	  (goto-char (point-min))
+	  (while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t)
+	(let* ((element (org-element-at-point))
+		   (included-file
+		(and (eq (org-element-type element) 'keyword)
+			 (let ((value (org-element-property :value element)))
+			   (and value
+(string-match "^\\(\".+?\"\\|\\S-+\\)" value)
+(org-remove-double-quotes
+ (match-string 1 value)))
+	  (when included-file (add-to-list 'includes (expand-file-name included-file)))
+  (unless visiting (kill-buffer buf))
+  (when includes (org-publish-cache-set-file-property filename :includes includes)))
+;; return t if needsp or if included files have changed
+(or needsp
+	(when (delq nil
+		(mapcar (lambda (file)
+			  (let ((ct (org-publish-cache-ctime-of-src file)))
+

Re: [O] problèmes d'accents

[Joseph Vidal-Rosset]

2014-08-12 13:38 GMT+02:00 Joseph Vidal-Rosset <
joseph.vidal.ros...@gmail.com>:

> Unfortunately, I have to forget the highlighting code with minted.



I add that, without minted, the source code between

#+BEGIN_SRC latex

#+END_SRC

is correctly highlighted . I regret that it is not in org-mode for all
formulas which are not between

#+BEGIN_SRC latex

#+END_SRC

like for example

\begin{equation}
A \to B
\end{equation}

I do not know if there is a solution.

Best

Jo.

Re: [O] problèmes d'accents

[Joseph Vidal-Rosset]

Hello Ali,

2014-08-12 13:24 GMT+02:00 Suvayu Ali :

> > Please, tell me how to express this action correctly in emacs dialect.
>
> That would be `C-c C-e l o'.
>

Thanks !


>
> > But I am happy to tell you that I have understood this morning the cause
> of
> > my problem. I had in my init.el  the following dangerous lines:
> >
> > ;; Let the exporter use the -shell-escape option to let latex
> > ;; execute external programs.
> > ;; This obviously and can be dangerous to activate!
> > (setq org-latex-pdf-process
> >  '("xelatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"))
>
> Why do you think this is dangerous?  Because of the `-shell-escape'?
> Without it you will not get source code highlighting (with minted).
> Also -shell-escape is not as dangerous as it seems.  It can be only if
> somehow you have a malicious/buggy package in your texlive installation,
> and you happen to use in your TeX source.
>

:) I have only reproduced the code and its comment from somewhere in the
internet. I am not expert enough to say if it is dangerous or not.
 I just note that the deactivation of this code in my init.el solves the
problem of French accents.
Unfortunately, I have to forget the highlighting code with minted. I had
also some problem with minted, and it seems that things work better with a
more thin  init.el ...

I'm using texlive with Xubuntu at the moment , and it is true that I did
not meet this problem under Debian testing, so, there is maybe a bug
somewhere in the texlive packages of Ubuntu  or Debian sid servers... it is
an unwelcome "troll" ;)

Best wishes

Jo.

Re: [O] problèmes d'accents

[Suvayu Ali]

Hello Joseph,

On Tue, Aug 12, 2014 at 07:36:05AM +0200, Joseph Vidal-Rosset wrote:
> 2014-08-11 23:15 GMT+02:00 Rasmus :
> > Joseph Vidal-Rosset  writes:
> >
> > > The topic of my message is intentionally in French.
> > >
> > > I meet a problem the French accents are not directly exported in the pdf
> > > when I C-c C-l-o . This problem disappears when I compile the .tex file
> > > exported from the org file.
> >
> > C-c C-l exists.  C-c C-l o makes no sense.
> >
> 
> Sorry, I meant C-e followed by l-o  (LateX file + pdf)
> 
> Please, tell me how to express this action correctly in emacs dialect.

That would be `C-c C-e l o'.

> But I am happy to tell you that I have understood this morning the cause of
> my problem. I had in my init.el  the following dangerous lines:
> 
> ;; Let the exporter use the -shell-escape option to let latex
> ;; execute external programs.
> ;; This obviously and can be dangerous to activate!
> (setq org-latex-pdf-process
>  '("xelatex -shell-escape -interaction nonstopmode -output-directory %o 
> %f"))

Why do you think this is dangerous?  Because of the `-shell-escape'?
Without it you will not get source code highlighting (with minted).
Also -shell-escape is not as dangerous as it seems.  It can be only if
somehow you have a malicious/buggy package in your texlive installation,
and you happen to use in your TeX source.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [patch, ox] Unnumbered headlines

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> True.  Personally, I find them nicer as you can just C-c C-c on your
> headline and write down some keyword that is typically easy to
> remember.  For properties I must rely on C-c C-x p — since the syntax
> is so awkward — and while it may be memorable to me try to explain it
> to co-authors who are not long-time Emacs users.
>
>> Another option is to use properties, e.g. "UNNUMBERED", or "NO_NUMBER"
>> with a non-nil value
>>
>>   * Some headline
>> :PROPERTIES:
>> :UNNUMBERED: t
>> :END:
>>
>> It is harder to notice an unnumbered headline, but it doesn't add cruft
>> to the tag line, and this is far less important than :noexport:. This is
>> not perfect either, but I think the trade-off is honest.
>
> I can see you point, and I think I agree, though I personally much,
> much prefer tags.

Of course, tags are easier to use than properties, hence their
popularity. But they have some limitations, too.

I'm not saying that we must use a property, but this is definitely
something to ponder.

> Of course a utility function could be added (like the beamer minor
> mode) that adds the tag to give you a visual clue while the properties
> are really what matter.

Which would defeat the choice of using a property (i.e. avoid visual
clutter).

>> Another advantage is inheritance is already implemented for node
>> properties (see `org-export-get-node-property').
>
> Interesting.  I did not know.

Actually, it's not an "advantage" per se, since `org-export-get-tags'
does it too.

> The most elegant way would perhaps be to introduce in the output of
> `org-export-get-headline-number' whether a headline is unnumbered, but
> I am not sure how to do this without breaking the expected output of
> the function.
>
> A dirty fix might be add an extra 0 to the beginning of the section
> number list when dealing with unnumbered headings, but it is not so
> nice as the numbers loose their meaning. . .

Also, headline numbers can start with 0:

  ** H0.1
  * H1
  ** H1.1

You could add a 0 at the end instead, or begin with a negative number,
which cannot happen otherwise, but that would be hackish, for sure.

Since "ox-html.el", and possibly other back-ends, rely on
`number-to-string', there not much else to do down this road.

> What I am currently trying to do with ox-html is combining
> `org-export-get-headline-number' (which is always a list of numbers)
> and `org-export-numbered-headline-p' to determine if the ID should
> contain the substring "unnumbered".  Then the first unnumbered section
> would be "sec-unnumbered-1" and so forth.
>
>> The previous snippet from "ox-html.el" would become
>>
>>   (format "%d "
>>   level
>>   (org-export-get-headline-id headline info))
>
> What I was experiment with is something like: 
>
> (format "%d "
>(if numberedp "" "unumbered")
>level)
>
> Do you think it would be better to work on
> `org-export-get-headline-id' and "solve" the issue in that way is a
> better approach than what I describe above?

Roughly, both approaches require the same amount of changes and imply
the same incompatibilities.

Nevertheless, I think it is cleaner for `org-export-get-headline-number'
to return nil when a headline is not numbered and to separate both
intents, i.e, provide a number and a unique internal id.

Anyway, feel free to experiment, there's no hurry.

Thanks for your work.


Regards,

-- 
Nicolas Goaziou