Re: [O] problèmes d'accents

[Joseph Vidal-Rosset]

Hi Rasmus,  hello the list,

2014-08-11 23:15 GMT+02:00 Rasmus :

> Hi,
>
> 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.


>
> > If someone can help, thanks. It is not a serious problem, but only a new
> > small one.
>
> Please give an example and report the output of M-x org-version
>

Org-mode version 8.2.7c (8.2.7c-1-gf5065b-elpaplus @
/home/joseph/.emacs.d/elpa/org-plus-contrib-20140804/)

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

Deactivated, all works smoothly now.

Best wishes,

Jo.

[O] Dynamicaly #+INCLUDE files

[Mehul Sanghvi]

I have a directory which has multiple sub-directories.  The sub-directories
contain files, some of which I want included into my org file when I export
it for publishing to HTML
using C-c C-e P p to publish.

Rather than manually adding the files I want to an Org file, Is there a way
to dynamically
include the files and have them processed by the publishing exporter ?
 Something
along the lines of:

  for file in *.c *.cpp *.m *.java *.lisp
  do
 echo #+INCLUDE the file
  done

Is there a way to do what I'm looking for ?


-- 
Mehul N. Sanghvi
email: mehul.sang...@gmail.com

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

[Andrea Rossetti]

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:



bin5FXj1pWhDr.bin
Description: application/emacs-lisp

  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?

  Thanks in advance, kindest regards.

  Andrea

Re: [O] org-8 manual on Amazon!

[Suvayu Ali]

On Fri, Aug 08, 2014 at 10:51:49AM -0700, Carlos Sosa wrote:
> Rasmus  writes:
> 
> > John Kitchin  writes:
> >
> >> I saw on twitter today the org mode 8 manual is available on Amazon
> >> today: http://www.amazon.com/dp/9881327709/. It looks like it covers Org 
> >> 8.2.
> >
> > I'm surprised by the change of publisher¹ and fact that there is no
> > reference to this edition on orgmode.org. . .
> >
> > —Rasmus
> >
> >
> > Footnotes: 
> > ¹   Though Network Theory Ltd isn't printing new manuals cf. 
> > http://www.network-theory.co.uk/about.html.
> 
> So if it's not referenced by orgmode.org, it means it was community
> made?

Looks like a new publisher publishing an updated version of the manual.
I'm wondering if it complies with the GFDL.  When the number of manuals
produced is geater than 100, the publisher is required to distribute the
source too[1].  I do not see any media included with the manual, although
maybe it is possible to point to a web url in the book.


Footnotes:

[1] https://en.wikipedia.org/wiki/GNU_Free_Documentation_License

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] problèmes d'accents

[Rasmus]

Hi,

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.

> If someone can help, thanks. It is not a serious problem, but only a new
> small one.

Please give an example and report the output of M-x org-version.

—Rasmus

-- 
What will be next?

Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line

[Nicolas Goaziou]

Rasmus  writes:

> How about adding the possibility to add hooks to org-fill-paragraph?
> So that people can add "extensions" to fill as they want and the core
> function can rely on org-element only?

You can `defadvice' anything to your heart's content.

OTOH, providing a hook for such a core feature is just
over-engineering.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line

[Nicolas Goaziou]

Federico Beffa  writes:

> The example highlight the difference that I suggested to remove in the
> very first place (by making \[...\] an environment). This was rejected
> to preserve backward compatibility and that's fine. So I moved on to a
> second proposal: modify the paragraph filling function.

This example illustrates that it would be nice to fill two different
structures, well, differently.

> From your sentence in your last reply:
>"... even though M-q cannot tell that difference (with your proposal,
>the behaviour would be the same in both cases)."
> I understand that there is no technical deficiency in it.

I cannot speak about technical deficiency. I didn't look closely at the
code. There are some gotchas, though, e.g., when auto-filling (moving
from "inline" to "block").

> Am I therefore correct in saying that if you prefer not to include
> this proposal in org-mode it isn't for technical reasons but it is
> a matter of opinion/taste?

I'm just pointing out an ergonomy (or consistency) annoyance in your
proposal. I'm not thrilled by faking the filling mechanism.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line

[Rasmus]

Federico Beffa  writes:

> On Mon, Aug 11, 2014 at 3:06 PM, Nicolas Goaziou  
> wrote:
>> Federico Beffa  writes:
>>
>
>>> to help me understand what kind of problems one could face with HTML (or
>>> another back-end), could you give a concrete example?
>>
>> line 1
>> line 2
>> \[1+1\]
>>
>> ==>
>>
>> 
>> line 1
>> line 2
>> 
>> 
>>
>> whereas
>>
>> line 1
>> line 2
>> \begin{equation*}
>> 1+1
>> \end{equation*}
>>
>> ==>
>>
>> 
>> line 1
>> line 2
>> 
>>
>> 
>> 
>> 
>>
>> IOW, there are two different structures in the document:
>>
>>   ((paragraph latex))
>>
>>   vs
>>
>>   ((paragraph) (latex))
>>
>> even though M-q cannot tell that difference (with your proposal, the
>> behaviour would be the same in both cases).
>
> The example highlight the difference that I suggested to remove in the
> very first place (by making \[...\] an environment). This was rejected
> to preserve backward compatibility and that's fine. So I moved on to a
> second proposal: modify the paragraph filling function.
>
> Didn't the following comment in your previous reply refer to the
> second proposal?
>
>> Ignoring \[...\] when filling the paragraph is misleading. You may
>> believe the object doesn't belong to the paragraph at all. I think M-q
>> should, on the contrary, give clues about the structure of the document.
>>
>> Also, it doesn't make a difference when exporting to LaTeX, but it might
>> in back-ends with a different definition for paragraphs (e.g. HTML).
>
> From your sentence in your last reply:
>"... even though M-q cannot tell that difference (with your proposal,
>the behaviour would be the same in both cases)."
> I understand that there is no technical deficiency in it. Am I
> therefore correct in saying that if you prefer not to include this
> proposal in org-mode it isn't for technical reasons but it is a matter
> of opinion/taste?
>
> I would like to know, because in any case I would like to use the
> proposed filling function in my copy of org-mode and if you see
> technical problems/errors I very much would like to be aware of them
> and, if possible, avoid/correct them.

How about adding the possibility to add hooks to org-fill-paragraph?
So that people can add "extensions" to fill as they want and the core
function can rely on org-element only?

—Rasmus

-- 
Lasciate ogni speranza, voi che leggete questo.

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

[Thierry Banel]

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.
> Thanks to everyone for orgmode and babel to exist. 
>
> Best
> Ernesto
>
>

Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line

[Federico Beffa]

On Mon, Aug 11, 2014 at 3:06 PM, Nicolas Goaziou  wrote:
> Federico Beffa  writes:
>
>> to help me understand what kind of problems one could face with HTML (or
>> another back-end), could you give a concrete example?
>
> line 1
> line 2
> \[1+1\]
>
> ==>
>
> 
> line 1
> line 2
> 
> 
>
> whereas
>
> line 1
> line 2
> \begin{equation*}
> 1+1
> \end{equation*}
>
> ==>
>
> 
> line 1
> line 2
> 
>
> 
> 
> 
>
> IOW, there are two different structures in the document:
>
>   ((paragraph latex))
>
>   vs
>
>   ((paragraph) (latex))
>
> even though M-q cannot tell that difference (with your proposal, the
> behaviour would be the same in both cases).

The example highlight the difference that I suggested to remove in the
very first place (by making \[...\] an environment). This was rejected
to preserve backward compatibility and that's fine. So I moved on to a
second proposal: modify the paragraph filling function.

Didn't the following comment in your previous reply refer to the
second proposal?

> Ignoring \[...\] when filling the paragraph is misleading. You may
> believe the object doesn't belong to the paragraph at all. I think M-q
> should, on the contrary, give clues about the structure of the document.
>
> Also, it doesn't make a difference when exporting to LaTeX, but it might
> in back-ends with a different definition for paragraphs (e.g. HTML).

>From your sentence in your last reply:
   "... even though M-q cannot tell that difference (with your proposal,
   the behaviour would be the same in both cases)."
I understand that there is no technical deficiency in it. Am I
therefore correct in saying that if you prefer not to include this
proposal in org-mode it isn't for technical reasons but it is a matter
of opinion/taste?

I would like to know, because in any case I would like to use the
proposed filling function in my copy of org-mode and if you see
technical problems/errors I very much would like to be aware of them
and, if possible, avoid/correct them.

Regards,
Federico

[O] Manipulating Dates Automatically in a Headline

[Matt Price]

Hi Everyone,

I've asked this before, but that was a year or two ago and am hoping
someone has an idea now, perhaps involving babel or something.

every year at this time I rewrite a set of syllabi. I do a lot of
moving htings around while i'm oding it, and at the end I have to
enter a whole bunch of dates somewhat laboriously.  I have headlines
that look about like either like this:

-
* Outline
** Week 1: Topic Title (<2013-09-10>)
Longish Description
*** Reading
- Article 1
- Article 2
*** Lab
*** Notes
---

or like this:
--
* Outline
** Week 1: <2013-09-09>
*** Seminar: Technology and Society  (<2013-09-10>)
*** Reading
- Article 1
- Article 2
*** Plenary: Global Citizenship (<2013-09-13>)


I would like to replace the timestamps with code that dynamically
generates timestamps based on the value either in the last sibling
headline, or the parent headline.  It seems to me this ought to be
possible, but I'm not at all sure how to do it.  i would really
appreciate any guidance.  thanks!

Matt

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

[Rick Frankel]

On Sat, Aug 09, 2014 at 05:49:27PM -0700, Shiyuan wrote:
>Hi,�
>� � I learned a bit a about html/css and took another look the issue. It
>turns out that org-mode uses the border attribute which is not respected
>by my browser(Google Chrome version 36.0.1985.125 on Mac 10.9.4) .�
>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:�
>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, ox] Unnumbered headlines

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> In a recent thread¹ Tom and Alan mention that authors sometimes need
>> unnumbered headlines, e.g. for prefaces.  This patch (tries to) add
>> this feature via the tag :nonumber: (customizable via Custom or
>> in-file).
>
> Interesting.  Some comments follow.
>
>> I make two assumptions.  First, the tag is recursive, so if the parent
>> is not numbered the child is not numbered.
>
> Indeed.
>
>> Secondly, I depart from the LaTeX tradition of ignoring unnumbered
>> headlines in the TOC (except in the case of ox-latex.el where it
>> depends on org-latex-classes). (See example below).
>
> OK.

The TOC part can easily be added, of course, but it's second order at
the moment. 

>> In my opinion a :nonumber: tag is a natural continuation of :export:
>> and :noexport:
>
> First, maybe a tag is not the best way to specify it. Tags are rather
> obnoxious and their length is somewhat limited by the width of the
> window.

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

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

Interesting.  I did not know.

>> and unlike :ignoreheading: the implementation is fairly clean (or
>> maybe I'm cheating myself here).
>
> Do not underestimate it: implementing this feature is a bit tricky, and
> will introduce backward incompatible changes to export back-ends
> (possibly outside the scope of core+contrib).
>
> A major problem comes from `org-export-get-headline-number', which
> always returns a unique non-nil value for headlines in a parse tree.
> Even unnumbered headlines (e.g. with option num:2) get a number.

> Consequently, some back-ends use this number as a unique ID, as this
> excerpt from "ox-html.el"
>
>   (format "%s "
>   level
>   (mapconcat #'number-to-string numbers "."))
>
> It is not possible to rely on this mechanism with your patch.
>
> A solution is to create two functions for the two features:
>
>   - `org-export-get-headline-number' :: the same as today, but returns
>nil if headline is unnumbered.
>
>   - `org-export-get-headline-id' :: returns a unique ID, as an integer,
>for the current headline, notwithstanding its numbering status.
>
> Then `org-export-get-ordinal' should probably try to call the first one
> and fallback to the second one.

In my local branch (not published; still problems with ox-html) I
"solve" this by retaining a number for unnumbered headlines and having
parallel numbering.  That is, there may exists a numbered section X.y
as well as a unnumbered section X.y when applicable.

Of course there is still an issue in that there is no way of
differentiating the a number list from a numbered section and an
unnumbered one and consequently e.g. ox-html IDs will still be broken.

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

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?

> Obviously, this implies that every back-end using this construct should
> be updated accordingly.

Thanks,
Rasmus

--

[O] Latex Preview Equations(with C-u C-u)

[Darlan Cavalcante Moreira]

Recently the latex preview equation in org-mode was improved.
Particularly 'C-c C-c' no longer removes the latex equations overlays,
and now we have a single function, org-toggle-latex-fragment, to
create/remove the image and overlays.

I think these changes were very good. One small inconvenient, however,
is that I usually pass two prefix arguments, 'C-u C-u', to
org-toggle-latex-fragment to render everything in the buffer. If I add a
new equation and then call org-toggle-latex-fragment again with 'C-u
C-u' org-mode will simply remove the overlays. This was not a problem
when there was a single function that only created overlays and another
to remove them.

I think having a 'toggle function' is better, but if the user passes two
prefix arguments he wants to render everything in the buffer, even if
there are already equations overlays in the buffer. Could org-mode be
changed to behave like that?

-- 
Darlan Cavalcante Moreira

[O] Need info about code block header arguments in (HTML) export

[Avdi Grimm]

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

puts "Hello,
world"



However, I already do a lot of post-processing on the exported HTML, so I'm
thinking that a simpler, more general solution would be sufficient:



puts "Hello,
world"



As you can see, in this version the header arguments are inserted,
unchanged, into a new data-org-header-args attribute. This would give me
enough information to munge the final HTML into the form I need.

So my question is: can anyone give me pointers on how to accomplish this?
Thanks!
-- 
Avdi Grimm
http://avdi.org

Re: [O] Programming with org-element-cache -> short introduction?

[Nicolas Goaziou]

Thorsten Jolitz  writes:

> Is it ok to do these two things:
>
>  - let-bind a value returned by `org-element-at-point' and modify it (with
>plist-put), and 

No, per advice given before. `plist-put' is destructive.

Instead, create a new element. You can use `org-combine-plists' to
generate its property list.


[...]

>  - globally set a value returned by `org-element-at-point', modify it
>(with plist-put) in a function call, but use the variable as a quoted
>(!) function arg and reset the original value with this trick:

Ditto.

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

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> In a recent thread¹ Tom and Alan mention that authors sometimes need
> unnumbered headlines, e.g. for prefaces.  This patch (tries to) add
> this feature via the tag :nonumber: (customizable via Custom or
> in-file).

Interesting.  Some comments follow.

> I make two assumptions.  First, the tag is recursive, so if the parent
> is not numbered the child is not numbered.

Indeed.

> Secondly, I depart from the LaTeX tradition of ignoring unnumbered
> headlines in the TOC (except in the case of ox-latex.el where it
> depends on org-latex-classes). (See example below).

OK.

> In my opinion a :nonumber: tag is a natural continuation of :export:
> and :noexport:

First, maybe a tag is not the best way to specify it. Tags are rather
obnoxious and their length is somewhat limited by the width of the
window.

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.

Another advantage is inheritance is already implemented for node
properties (see `org-export-get-node-property').

> and unlike :ignoreheading: the implementation is fairly clean (or
> maybe I'm cheating myself here).

Do not underestimate it: implementing this feature is a bit tricky, and
will introduce backward incompatible changes to export back-ends
(possibly outside the scope of core+contrib).

A major problem comes from `org-export-get-headline-number', which
always returns a unique non-nil value for headlines in a parse tree.
Even unnumbered headlines (e.g. with option num:2) get a number.

Consequently, some back-ends use this number as a unique ID, as this
excerpt from "ox-html.el"

  (format "%s "
  level
  (mapconcat #'number-to-string numbers "."))

It is not possible to rely on this mechanism with your patch.

A solution is to create two functions for the two features:

  - `org-export-get-headline-number' :: the same as today, but returns
   nil if headline is unnumbered.

  - `org-export-get-headline-id' :: returns a unique ID, as an integer,
   for the current headline, notwithstanding its numbering status.

Then `org-export-get-ordinal' should probably try to call the first one
and fallback to the second one.

The previous snippet from "ox-html.el" would become

  (format "%d "
  level
  (org-export-get-headline-id headline info))

Obviously, this implies that every back-end using this construct should
be updated accordingly.

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: [O] Programming with org-element-cache -> short introduction?

[Thorsten Jolitz]

Nicolas Goaziou  writes:

Hello,

> Thorsten Jolitz  writes:
>
>> when programming with Org elements sometimes things seem to work and
>> then something strange happens - what smells like a cache problem. I
>> don't mean a cache bug, but a programmer (me) not taking the cache
>> into account the right way.
>
> It might also be a cache problem. Do not hesitate to report it.

Ok

>> Is there a short introduction somewhere about the 'todos' and 'nogos' in
>> programming with elements wrt to the org-element-cache?
>
> The only "nogo" is to never modify (destructively) a value returned by
> `org-element-at-point' or `org-element-context'. Consider their return
> value as read-only, and possibly invalid as soon as you modify the
> buffer.

This one directly applies to my use-case (wrt `org-element-at-point'). 
Is it ok to do these two things:

 - let-bind a value returned by `org-element-at-point' and modify it (with
   plist-put), and 

   1. then return the interpreted value or

   2. do (delete-region ...) on old element and then insert the
  (interpreted) new one?

 - globally set a value returned by `org-element-at-point', modify it
   (with plist-put) in a function call, but use the variable as a quoted
   (!) function arg and reset the original value with this trick:
   
   #+begin_src emacs-lisp
 (setq X (org-element-at-point))

 (defun foo (element &optional replace-p)
   (let ((elem (eval element)))
 [...destructively modify elem...]
 [...interpret elem ...]
 (when replace-p
   [...delete old-element ...]
   [...insert interpreted elem, goto beg ...]
   (set element (org-element-at-point)

 (foo 'X t)
   #+end_src

> These advices don't apply to `org-element-parse-buffer', which doesn't
> use cache (if it did, it should copy cached elements beforehand anyway).

Ok

-- 
cheers,
Thorsten

Re: [O] Programming with org-element-cache -> short introduction?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  writes:

> when programming with Org elements sometimes things seem to work and
> then something strange happens - what smells like a cache problem. I
> don't mean a cache bug, but a programmer (me) not taking the cache
> into account the right way.

It might also be a cache problem. Do not hesitate to report it.

> Is there a short introduction somewhere about the 'todos' and 'nogos' in
> programming with elements wrt to the org-element-cache?

The only "nogo" is to never modify (destructively) a value returned by
`org-element-at-point' or `org-element-context'. Consider their return
value as read-only, and possibly invalid as soon as you modify the
buffer.

These advices don't apply to `org-element-parse-buffer', which doesn't
use cache (if it did, it should copy cached elements beforehand anyway).


HTH,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line

[Nicolas Goaziou]

Federico Beffa  writes:

> to help me understand what kind of problems one could face with HTML (or
> another back-end), could you give a concrete example?

line 1
line 2
\[1+1\]

==>


line 1
line 2



whereas

line 1
line 2
\begin{equation*}
1+1
\end{equation*}

==>


line 1
line 2






IOW, there are two different structures in the document:

  ((paragraph latex))

  vs

  ((paragraph) (latex))

even though M-q cannot tell that difference (with your proposal, the
behaviour would be the same in both cases).


Regards,

-- 
Nicolas Goaziou0x80A93738

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

[Charles Millar]

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.

Charlie

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

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

[Charles Millar]

Daimrod wrote:

+When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the 
location of the last refiled item.

^^
 '(16)


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

[O] Bug: clock table total time parsed incorrectly [8.2.7c (8.2.7c-elpa @ /home/loic/.emacs.d/elpa/org-20140730/)]

[Loic Dachary]

Hi,

In the following clock table:

#+BEGIN: clocktable :maxlevel 3 :emphasize nil :scope file :block 2014-08 
:formula % :narrow 100
#+CAPTION: Clock summary at [2014-08-11 lun. 10:17], for août 2014.
| <100> 
   ||  |   |   |
| Headline  
   |   Time |  |   | % |
|--++--+---+---|
| *Total time*  
   | *1d 16:04* |  |   | 100.0 |
|--++--+---+---|
| STARTED Read mail 
   |   8:23 |  |   |  52.2 |
| STARTED GSoC  
   |   0:49 |  |   |   5.1 |
...
#+TBLFM: $5='(org-clock-time% @3$2 $2..$4);%.1f
#+END: clocktable

The total time is apparently parsed as 16:04 instead of 1d 16:04 which leads to 
the incorrect conclusion that 8:23 is 52.2% of the time.

Emacs  : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7)
 of 2014-03-07 on lamiak, modified by Debian
Package: Org-mode version 8.2.7c (8.2.7c-elpa @ 
/home/loic/.emacs.d/elpa/org-20140730/)

-- 
Loïc Dachary, Artisan Logiciel Libre



signature.asc
Description: OpenPGP digital signature

[O] problèmes d'accents

[Joseph Vidal-Rosset]

Hello everybody,


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.

If someone can help, thanks. It is not a serious problem, but only a new
small one.

Best

Jo.

Re: [O] How can I autorun M-x linum-mode when file is opened?

[Sharon Kimble]

Samuel W Flint  writes:

> On 10 Aug 2014, Sharon Kimble wrote:
> [Edited for the sake of brevity]
>
 How can I have a command auto-run when a file is opened from
 'desktop recovery' please? I want to auto-run "M-x linum-mode" when
 I open my daily journal, which stays open all the time. Running that
 command will switch off linum-mode for that file, which may stop
 "file-rot" that I have observed in the past. This can, at present,
 only be resolved by shutting down emacs for half an hour or so, and
 then restarting it, and normal functionality will have been
 restored.
>
> Have you considered using a hook?  That is what they are for, and
> generally, I’ve found that linum mode in an org file can be annoying, so
> in my init file I have =(add-hook ‘org-mode-hook #’(lambda ()
> (linum-mode -1)))=, and, while I have Linum on globally, this disables
> it for all org mode files.
>
Thanks for this Sam, it is now working beautifully.

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
my git repo = https://bitbucket.org/boudiccas/dots
TGmeds = http://www.tgmeds.org.uk
Debian testing, fluxbox 1.3.5, emacs 24.3.92.1


signature.asc
Description: PGP signature

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

[Suvayu Ali]

On Sun, Aug 10, 2014 at 01:50:50AM +0200, Daimrod wrote:
>  
> -When GOTO is 0 or '(64), clear the refile cache.
> -When GOTO is '(16), go to the location of the last refiled item.
> +When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] 
> \\[universal-argument], clear the refile cache.
> +When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to 
> the location of the last refiled item.
>  RFLOC can be a refile location obtained in a different way.
>  When NO-UPDATE is non-nil, don't redo the agenda buffer."

I would say this is an improvement :).

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Custom environment for LaTeX export

[Suvayu Ali]

On Sun, Aug 10, 2014 at 08:59:10AM +0200, Julien Cubizolles wrote:
> 
> 
> Sebastien Vauban 
> writes:
> 
> 
> > Throwing an idea here: make the `consequence' environment be a no-op in 
> > Beamer?
> 
> How would I do that, is there a variable excluding some environments ?

I'm guessing Seb's idea could be implemented by redefining the
consequence environment when in beamer, leave it alone otherwise.

However, I would like to suggest something a bit different.  Why not
instead of #+BEGIN_consequence, you use a macro.  Something like this:

  #+MACRO: cbeg @@latex:\begin{consequence}@@
  #+MACRO: cend @@latex:\end{consequence}@@

Then you can do:

  {{{cbeg}}}
  stuff
  {{{cend}}}

and only LaTeX export will have the environment.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

[O] How to capture to... null

[Marcin Antczak]

Hi list,


I would like to use org-capture to create entries on my Gitlab host via 
API and then I would like to make template dissapear and not write 
output data anywhere.


I know that I can use function as target for my capture template.
But when I set template as follows:

(setq org-capture-templates
'(("i"
"issue"
plain
(function
(lambda() ))
:immediate-finish t)))

Then I get this error message:

byte-code: Capture abort: (buffer-read-only #)

Is this possible to tell org-capture to not to try to write output anywhere?


Regards,
Marcin

Re: [O] How can I autorun M-x linum-mode when file is opened?

[Suvayu Ali]

On Sun, Aug 10, 2014 at 01:07:36PM -0500, Samuel W Flint wrote:
> On 10 Aug 2014, Sharon Kimble wrote:
> [Edited for the sake of brevity]
> 
> >>> How can I have a command auto-run when a file is opened from
> >>> 'desktop recovery' please? I want to auto-run "M-x linum-mode" when
> >>> I open my daily journal, which stays open all the time. Running that
> >>> command will switch off linum-mode for that file, which may stop
> >>> "file-rot" that I have observed in the past. This can, at present,
> >>> only be resolved by shutting down emacs for half an hour or so, and
> >>> then restarting it, and normal functionality will have been
> >>> restored.
> 
> Have you considered using a hook?  That is what they are for, and
> generally, I’ve found that linum mode in an org file can be annoying, so
> in my init file I have =(add-hook ‘org-mode-hook #’(lambda ()
> (linum-mode -1)))=, and, while I have Linum on globally, this disables
> it for all org mode files.

FWIW, if anyone is curious, the following post gives some insight into
why that might be.



Cheers,

-- 
Suvayu

Open source is the future. It sets us free.