Re: [O] string joining accumulated noweb references
Achim Gratz writes: > Eric Schulte writes: >> I just pushed up a new customization variable named >> `org-babel-noweb-separator' which is used to join multiple accumulated >> noweb references like the above. The value defaults to a newline giving >> the same behavior resulting from your patch but can be set to any >> string. > > Now, lets say I'd want to accumulate one set of noweb references with > one separator and another set with a different one, maybe even in the > same document. How'd I do that? > Not possible in the same document, although on a document-by-document basis I would recommend the use of file local variables. > > Also, using a customization variable for the purpose of changing the > semantics of documents is generally fraught with peril: if someone does > customize this variable, their documents will break in subtle ways for > somebody with a different or no customization. I suggest that such > changes should always be visible in the source document itself. > That is a very good point. I had originally started to implement this parameter using a header argument, but then decided that it didn't make sense to implement a multi-block parameter using a header argument. Now that you mention this however I do agree that a customization parameter is even less appropriate. Given that header arguments may be set on the file and subtree level, I suppose they do offer the range of application appropriate for this sort of parameter, and they are more likely (though not guaranteed) to have their value present in the buffer. I've just pushed up a change converting the `org-babel-noweb-separator' customization variable to the :noweb-sep header argument. Thanks, > > > Regards, > Achim. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] string joining accumulated noweb references
Eric Schulte writes: > I just pushed up a new customization variable named > `org-babel-noweb-separator' which is used to join multiple accumulated > noweb references like the above. The value defaults to a newline giving > the same behavior resulting from your patch but can be set to any > string. Now, lets say I'd want to accumulate one set of noweb references with one separator and another set with a different one, maybe even in the same document. How'd I do that? Also, using a customization variable for the purpose of changing the semantics of documents is generally fraught with peril: if someone does customize this variable, their documents will break in subtle ways for somebody with a different or no customization. I suggest that such changes should always be visible in the source document itself. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Problem at capture time
Hi François, Hi Bastien, At Mon, 09 Jan 2012 07:50:54 -0500, François Pinard wrote: > > Bastien writes: > > > Hi François, please be patient -- your patches are under radar, > > resending them does not help. > > OK, sorry. I do not know enough, yet, how Org works. I sent a problem, > got a question, sent a reply which was rejected, then nothing. A mere > short acknowledgement would have told me the message was not lost. > > > What helps is to send them using git format-patch, to include a > > detailed and clean changelog entry, and to make it clear whether the > > patch is okay or for testing purpose first. When I read your message, > > I could not be sure you were yourself confident it was the right fix. > > I'm still not confident. And I'm not pedant enough -- yet! :-) -- to > write formal patches when I'm not at least rather sure. > > Besides the lack of confidence in a solution, however, the problem is > real. The patch I sent was merely a trail for thinking. But if nothing > else, it would do I presume. > > > I will look into this later on. > > Let me the one thanking you for supporting Org mode and its users, even > those like me! :-) Sorry for my silence, haven't looked into the Orgmode mailing list for a while. I just pushed a fix for this problem: If the :exact-position for a list item is supplied we don't search for the position in an existing list at all but insert the item whereever :exact-position points to. I'll mark the patch in patchwork as superseeded this evening as soon as I recover my password. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpXeMllWqvRS.pgp Description: PGP signature
[O] export-as-hmtl fail
Hello, When I use a python code block in a document any export-as-html results in the error "Invalid file-name". Without a code block the export goes without a hitch. Other exports work no probs such as export-as-ascii. The code block within the document acts as expected, it is only the export that fails. I was on org7.5 but updated to 7.8.03 but have the same result. Also, it is only the python code blocks that fail, others work. My babel setup is (org-babel-do-load-languages 'org-babel-load-languages '( (dot . t) (sh . t) (python . t) (emacs-lisp . t) )) (setq org-babel-python-command "python2.6") My code block is #+begin_src python :results output print "hi" #+end_src #+results: : hi Does anyone have any tips on what I might do to troubleshoot this. Could it be something else in my setup or system? Any else ever experienced this? cheers, aaron.
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
On Mon, Jan 23, 2012 at 10:05 PM, Eric Schulte wrote:
> Leo Alekseyev writes:
>
>> On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte wrote:
>>> Leo Alekseyev writes:
>>>
Since all source blocks are evaluated on export, I don't think it
should be necessary to issue org-babel-execute-buffer before invoking
export. However, running HTML export without org-babel-execute-buffer
currently produces garbage output.
>>>
>>> What do you mean by "garbage" output?
>>
>> That wasn't a very good description, sorry.
>
> No problem, thanks for clarifying.
>
> [... moot bug removed ...]
>
>>>
>>> Could you isolate a minimal example demonstrating just the failure of
>>> results replacement?
>>
>> Run the below code a few times with C-c C-v b, and you'll see
>>
>> snip-
>> #+property: session *R-babel*
>>
>> #+NAME: foo
>> #+HEADER: :var plot.filename="conv1.png"
>> #+BEGIN_SRC R :results output silent
>> cat.fname.link <- function() { cat(plot.filename,"\n",sep="") }
>> cat.fname.link()
>> #+END_SRC
>>
>> src_R[:results output replace]{ cat.fname.link() }
>> snip-
>>
>>
>> You can also replace src_R with
>>
>> #+begin_src R :results output raw replace :exports results
>> cat.fname.link()
>> #+end_src
>>
>> and it will also fail to replace results.
>>
>> All the above examples were run with the latest pull of org.
>>
>
> Ah, I see now. Unfortunately it is not possible to replace the results
> of inline code blocks. This is because there is no general way to
> identify where the results begin and end. Maybe adding [:results
> silent] to your inline code blocks would solve the problem. Then you
> could evaluate the whole buffer, and could previews the values produced,
> but would not have to worry about duplicate results.
Yes, that's a good suggestion.
Just to be clear, do you consider the following to be an inline block?
(I usually think of inline as limited to src_R{ ...} type things).
Or are you generally talking about the distinction between #+begin_src
/ #+end_src lines vs #+call lines?
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
Finally, in the last file of my original message I try to use #+call's
everywhere instead of source blocks. Cleaned up example is pasted
below. It looks broken (the first #+call bar is out of order, the
second and third #+call bar's don't run), see
http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
broken
--snip-
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var a="a1.png"
#+BEGIN_SRC R :results output silent
cat("in foo block\n")
cat.a <- function() { cat(a,"\n",sep="") }
cat.a()
#+END_SRC
#+NAME: bar
#+begin_src R :results output raw replace :exports none
cat.a()
#+end_src
Should have all a1 stuff
#+call: foo(a="a1.png")
#+call: bar()
Should have all a2 stuff
#+call: foo(a="a2.png")
#+call: bar()
Should have all a3 stuff
#+call: foo(a="a3.png")
#+call: bar()
Re: [O] string joining accumulated noweb references
Wow - this is /fast/ development :-); now I'm glad my son kept me awake this night, so that I could check my mails sooner than I normaly would have... Eric Schulte writes: > Tom Regner writes: > >> Eric Schulte writes: >> >>> I'd rather not change the default silently in this way. >> I understand that. > > My apologies, now that I understand the issue I see that the current > behavior is most likely confusing and I agree with your original > suggestion to change the default. Yes, well -- but changing current behaviour is always tricky -- you never know, how many people/documents rely on it. That's why I think that... > >> Example document: >> --->% >> * Subtree >> :PROPERTIES: [...] > > I just pushed up a new customization variable named > `org-babel-noweb-separator' which is used to join multiple accumulated > noweb references like the above. The value defaults to a newline giving > the same behavior resulting from your patch but can be set to any > string. ...this change is way better than my proposal; as it now does the "right thing"™ per default, but existing workflows depending on the old behaviour are easily mended. Thanks again -- impressive speed in reacting and thinking, and overall a polite and civil environment for contributors. I like that. Kind regards, Tom
Re: [O] [BUG] Inconsistency in src block hiding
Leo Alekseyev writes: > "Tucking stuff away" can mean different things to different users. > Personally, I have treated them purely as an organizational device for > supplementary information (I have :DETAILS: drawers all over my org > files). (Out of Context) Drawer contents => Marginalia[1]? or Presentation Notes? It could also be useful as side-bar notes that have interesting trivia like "Ever seen a subliminal arrow in the Fedex logo?" Footnotes: [1] http://en.wikipedia.org/wiki/Marginalia --
Re: [O] [BUG] Inconsistency in src block hiding
> statement above. The tag-line to the "Drawers" section in the manual is
> "Tucking stuff away" which I think is often how drawers are used.
> Changing the default drawer export behavior from "don't export" to "do
> export" would be surprising, would break many existing work flows, and
> would likely make drawers less useful.
>
> In general I think the Org-mode specification is best defined by how
> Org-mode is used and how it may be more easily and intuitively used in
> the future. Org-mode doesn't currently have a formal specification, and
> I think that is a good thing. Formal specification don't prevent bugs,
> they just move them from the code to the spec.
"Tucking stuff away" can mean different things to different users.
Personally, I have treated them purely as an organizational device for
supplementary information (I have :DETAILS: drawers all over my org
files). The problem is that I may or may not want this supplementary
information in the export, and will really vary from case to case.
(Personally, in most cases, I do want to export that information --
but not always!) Furthermore, assuming that I _do_ want drawers
exported, I may or may not want the drawer markup to be exported, i.e.
if drawers are used purely for organizing the presentation of
information, the drawer markup doesn't belong in the export. On the
other hand, in certain cases one might want to denote the information
as supplementary, either by exporting drawer markup (or, more likely,
by putting drawer contents inside something like a block).
If I were designing this behavior from scratch, I would allow for
maximum flexibility by
(1) creating e.g. org-drawers-to-export variable which could take on
the values nil (don't export), 'all (all drawers except :PROPERTIES:)
exported, or a list of drawer names to export
(2) introducing drawer flags that would control the export and display
behavior of individual drawers. For instance, something like
:FOO: -vis -export
stuff...
:END:
would indicate that this drawer is to be kept unfolded and exported by default.
(3) controlling whether the drawer contents are separated out from the
rest of the contents by some markups ('s or a block)
I'm not sure how easy and/or practical any of this would be. My
general philosophy is that if a behavior isn't specified, many
possible (sensible) behaviors should be considered and accommodated.
In that sense, hiding #+name: blocks is a good thing, because it
increases the amount of allowed sensible usage patterns. If we were
to take it away, I think it would be necessary to compensate for this
by increasing the amount of allowed sensible usage patterns of the
drawers, kind of along the lines of what I described above.
--Leo
Re: [O] Prompts for `C-c .' and `C-c !'
On 2012-01-24 00:01 +0800, François Pinard wrote: > Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and > the date is prompted in the mini-buffer in the same way for both > commands. One of them is going to insert , the other [DATE]. The > mini-buffer always show , like this: > >Date+time [2012-01-23]: => <2012-01-23 lun> > > Could it be: > >Date+time [2012-01-23]: => [2012-01-23 lun] I think this is a good suggestion. <> is unconditionally set in org-time-stamp-custom-formats but it can be fixed by tweaking org-read-date-display. Leo
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Leo Alekseyev writes:
> On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte wrote:
>> Leo Alekseyev writes:
>>
>>> Since all source blocks are evaluated on export, I don't think it
>>> should be necessary to issue org-babel-execute-buffer before invoking
>>> export. However, running HTML export without org-babel-execute-buffer
>>> currently produces garbage output.
>>>
>>
>> What do you mean by "garbage" output?
>
> That wasn't a very good description, sorry.
No problem, thanks for clarifying.
[... moot bug removed ...]
>>
>> Could you isolate a minimal example demonstrating just the failure of
>> results replacement?
>
> Run the below code a few times with C-c C-v b, and you'll see
>
> snip-
> #+property: session *R-babel*
>
> #+NAME: foo
> #+HEADER: :var plot.filename="conv1.png"
> #+BEGIN_SRC R :results output silent
> cat.fname.link <- function() { cat(plot.filename,"\n",sep="") }
> cat.fname.link()
> #+END_SRC
>
> src_R[:results output replace]{ cat.fname.link() }
> snip-
>
>
> You can also replace src_R with
>
> #+begin_src R :results output raw replace :exports results
> cat.fname.link()
> #+end_src
>
> and it will also fail to replace results.
>
> All the above examples were run with the latest pull of org.
>
Ah, I see now. Unfortunately it is not possible to replace the results
of inline code blocks. This is because there is no general way to
identify where the results begin and end. Maybe adding [:results
silent] to your inline code blocks would solve the problem. Then you
could evaluate the whole buffer, and could previews the values produced,
but would not have to worry about duplicate results.
Sorry I don't have a more satisfying answer.
Best,
>
> HTH,
>
> --Leo
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte wrote:
> Leo Alekseyev writes:
>
>> Since all source blocks are evaluated on export, I don't think it
>> should be necessary to issue org-babel-execute-buffer before invoking
>> export. However, running HTML export without org-babel-execute-buffer
>> currently produces garbage output.
>>
>
> What do you mean by "garbage" output?
That wasn't a very good description, sorry.
..
I just wrote a detailed description of the bug, and then remembered
that I forgot to copy the latest org pull into
/usr/share/emacs/24/lisp/org. This bug is now gone, probably as a
result of you fixing export evaluation order. However, the
description of "replace results" bug is still relevant. I'll denote
issues that are now fixed with appropriate markup.
#+BEGIN_MOOT_POINT
Take test-export4.org from my original message, and export (C-c C-e h;
don't evaluate the buffer beforehand). You will see the following
output: http://i.imgur.com/IM3oy.png
There are two problems:
(1) Notice that the output of _every_ src_R block is "images/conv2.png"
It should be "conv1.png" on the first invocation "conv2.png" on the
second, and "conv3.png" on the third.
(2) The last src_R block is not evaluated and, in fact, appears in the
output (which it shouldn't), mangled, as the underscore is taken as a
subscript.
#+END_MOOT_POINT
For comparison, if you first evaluate the buffer, and then export, you
will see this:
http://i.imgur.com/V6PXq.png
The output of the src_R blocks is now correct, but I don't see why one
needs to pre-evaluate the buffer to get correct output on export. The
overall output, as you can see, is _not_ correct, since the results
from invocation of src_R blocks via the export are _appended_ to those
that were generated via C-c C-v b.
>
> Could you isolate a minimal example demonstrating just the failure of
> results replacement?
Run the below code a few times with C-c C-v b, and you'll see
snip-
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var plot.filename="conv1.png"
#+BEGIN_SRC R :results output silent
cat.fname.link <- function() { cat(plot.filename,"\n",sep="") }
cat.fname.link()
#+END_SRC
src_R[:results output replace]{ cat.fname.link() }
snip-
You can also replace src_R with
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
and it will also fail to replace results.
All the above examples were run with the latest pull of org.
HTH,
--Leo
Re: [O] [BUG] Inconsistency in src block hiding
Nicolas Goaziou writes: > Hello, > > Eric Schulte writes: > >> Thanks for taking the time to collect these changes into a patch, >> however I believe the changes you describe present /new/ behavior (e.g., >> new export semantics for drawers), rather than a bug repair. > > I'd rather say that its intent is to fix an old bug: incomplete > specifications of drawers. Also, I don't add export semantics for > drawers: I remove any, by default. > I apologize if I come across as argumentative, but I disagree with the statement above. The tag-line to the "Drawers" section in the manual is "Tucking stuff away" which I think is often how drawers are used. Changing the default drawer export behavior from "don't export" to "do export" would be surprising, would break many existing work flows, and would likely make drawers less useful. In general I think the Org-mode specification is best defined by how Org-mode is used and how it may be more easily and intuitively used in the future. Org-mode doesn't currently have a formal specification, and I think that is a good thing. Formal specification don't prevent bugs, they just move them from the code to the spec. Incidentally this is also why I consider the loss of result folding to be a regression because it breaks existing usage patterns. > > Again, drawers allow to fold any part of an Org buffer without adding > semantics to its contents. It's a more general solution than > keywords. But you already know that. > >> For the time being I am going to bring back results folding until an >> acceptable alternative can be agreed upon and implemented. > > There is already an acceptable alternative. I sincerely hope that > reverting this won't make it impossible to be implemented later. > There is no rule against reverting a revision :), so we could always do that if there is a consensus on list. To my mind a better path moving forward would be to change the behavior of the :RESULTS: drawer so that it is exported but *not* to change the default drawer export behavior. This way with a :wrap header argument the code block results could be hidden with tab but would still be exported. PRO: allows hiding code block results with tab, makes it clear where results begin and end, uses drawers for hiding which is what they are designed for, avoids the potential for hiding anything with a name CON: more syntactic weight around results, changes the existing default behavior, makes the "RESULTS" drawer a special type of drawer There is likely a better option but this is the best that comes to mind. Personally I am also content with the current behavior in which anything under a #+name: may be hidden. Cheers, > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] string joining accumulated noweb references Was: (no subject)
Tom Regner writes: > Eric Schulte writes: > >> I'd rather not change the default silently in this way. > I understand that. My apologies, now that I understand the issue I see that the current behavior is most likely confusing and I agree with your original suggestion to change the default. > Example document: > --->% > * Subtree > :PROPERTIES: > :noweb-ref: subtree > :END: > ** Part 1 > #+begin_src sh > Line One > #+end_src sh > ** Part 2 > #+begin_src sh > Line Two > #+end_src sh > * Assamble it > #+begin_src sh :tangle yes :noweb tangle > <> > #+end_src sh I just pushed up a new customization variable named `org-babel-noweb-separator' which is used to join multiple accumulated noweb references like the above. The value defaults to a newline giving the same behavior resulting from your patch but can be set to any string. Thanks for pointing this out, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Scrolling down after Shift-TAB ?
François Pinard wrote: > It usually does not do the proper thing alone, but `C-l C-l C-l' is > closer to what I want. > Well, the proper thing is very much in the eye of the beholder :-) Also, I never noticed the binding change: I've been living my life thinking that C-l *is* recenter... Thanks for the wake-up call. Nick
Re: [O] Scrolling down after Shift-TAB ?
Nick Dokos writes: > François Pinard wrote: >> Very, very often, after a Shift-TAB that collapses all entries, [...] >> I [...] scroll down so see it all. > You'd need to code it somewhat carefully sp that you wouldn't lose the > property that after a couple of S-TABs, the buffer looks the same as > when you started and point has not moved: that's useful in order to zoom > out and orient yourself in the larger context and then zoom in again to > continue working. That's a nice property indeed. Thanks for your patience with me! :-) > Have you tried C-l after the collapse? It usually does not do the proper thing alone, but `C-l C-l C-l' is closer to what I want. > If you like the behavior, you can always advise org-cycle so that it > always calls recenter afterwards: > (defadvice org-cycle (after org-cycle-recenter) > "Recenter after org-cycle)" > (recenter)) > (ad-activate 'org-cycle) This was a good hint, thanks. Starting from your idea, I ended up with: (defun fp-org-cycle-recenter (type) "Recenter after global collapsing." (when (eq type 'overview) (recenter (1- (window-body-height) (add-hook 'org-cycle-hook 'fp-org-cycle-recenter) When returning to a more expanded view, the original line is recovered at the center of the window instead of at its precise previous position, which is quite acceptable to me. From there, another full cycle of course leaves the impression that the position did not move. François
Re: [O] (no subject)
Eric Schulte writes: > I'd rather not change the default silently in this way. I understand that. > > Could you provide a minimal example of the difference you describe? I > just tried viewing the expanded form of the following code block and saw > no difference between :noweb-ref and normal #+name: based expansions. > > * examples > > #+name: first > #+begin_src sh > echo 1 > #+end_src > > #+begin_src sh :noweb-ref second > echo 2 > #+end_src > #+begin_src sh :noweb yes > <> > <> > #+end_src > > Thanks, > Example document: --->% * Subtree :PROPERTIES: :noweb-ref: subtree :END: ** Part 1 #+begin_src sh Line One #+end_src sh ** Part 2 #+begin_src sh Line Two #+end_src sh * Assamble it #+begin_src sh :tangle yes :noweb tangle <> #+end_src sh --->% tangled without my patch: --->% Line OneLine Two --->% tangled with my patch --->% Line One Line Two --->%
Re: [O] Scrolling down after Shift-TAB ?
François Pinard wrote: > Hi again. > > Very, very often, after a Shift-TAB that collapses all entries, a few > lines in the vicinity of the cursor are shown at the top of the window, > which is mainly empty for its reminder; we contemplate the vacuum > *after* the file. As my Org files are such that all the top level lines > usually fit in one window, I then invariably scroll down so see it all. > > I wonder if this could be automated, yet it is a bit uneasy to exactly > define what would be the ideal. Let me try an initial suggestion: > > - If the whole Org file could be displayed at once, scrolling should > automatically occur so the first line of the window displays the > beginning of the Org file. > > - Otherwise, if the last line of the window would be *outside* the Org > file, scrolling should automatically occur so the last line of the > window displays the end of the Org file. > > - If neither of the above holds, do not automatically scroll. > > Maybe others could improve on this with better ideas or algorithms ? > You'd need to code it somewhat carefully sp that you wouldn't lose the property that after a couple of S-TABs, the buffer looks the same as when you started and point has not moved: that's useful in order to zoom out and orient yourself in the larger context and then zoom in again to continue working. Have you tried C-l after the collapse? S-TAB C-l doesn't do quite what you specified, but perhaps it's enough: it shrinks the vacuum after the file, maybe to nothing, and it does not shift point. If you like the behavior, you can always advise org-cycle so that it always calls recenter afterwards: --8<---cut here---start->8--- (defadvice org-cycle (after org-cycle-recenter) "Recenter after org-cycle)" (recenter)) (ad-activate 'org-cycle) --8<---cut here---end--->8--- Nick
Re: [O] Side-by-side support
Hi Jambunathan, On 2012-01-24 01:34, Jambunathan K wrote: In my case, I have simply separated the columns by a character and set the tab-width to a sensible value for nice on-screen display. These are 'text' and 'translation of that text' side-by-side, When you are saying on-screen display, I presume you are referring to the Emacs screen? I have a strong feeling that you are using two column editing. Otherwise, it would be extremely difficult to keep one's sanity. Actually I started out using 2C editing for this, but it came constantly in my way, so currently what I am doing is: (1) use a tab character to separate the two columns and (2) set the tab-width to 30 (in most cases), so that most of the columns are nicely separated. This works very well for editing in Emacs. However, at the moment I do not have an easy way to export this to ODT as it s. Now I have given further thought to this, maybe the following will work: (1) consecutive lines with 1 or more characters and the *same* number of such s will be considered as a table and the exporter will work with this as if it were a org-table. (Note that I usually only have two columns and as you said, with more columns one is probably better off using proper tables) (2) This option is switched on or off through a variable or a OPTION line in the header of the file. (3) as I mentioned earlier, it would be good to be also able to globally set the proportions (maybe this can already be done with column properties?) All the best, Christian -- Christian Wittern, Kyoto
[O] Scrolling down after Shift-TAB ?
Hi again. Very, very often, after a Shift-TAB that collapses all entries, a few lines in the vicinity of the cursor are shown at the top of the window, which is mainly empty for its reminder; we contemplate the vacuum *after* the file. As my Org files are such that all the top level lines usually fit in one window, I then invariably scroll down so see it all. I wonder if this could be automated, yet it is a bit uneasy to exactly define what would be the ideal. Let me try an initial suggestion: - If the whole Org file could be displayed at once, scrolling should automatically occur so the first line of the window displays the beginning of the Org file. - Otherwise, if the last line of the window would be *outside* the Org file, scrolling should automatically occur so the last line of the window displays the end of the Org file. - If neither of the above holds, do not automatically scroll. Maybe others could improve on this with better ideas or algorithms ? François
Re: [O] C-a in lists when org-special-ctrl-a/e
Nicolas Goaziou writes: >> It all depends if we read the letter or the spirit of the second >> sentence. "[ ]" is a kind of TODO, and "[X]" is a kind of DONE, as >> demonstrated by the commands `C-x -' and `C-x *'. That's why I quite >> naturally expect the cursor to be positioned after the check box. > Ok, then, let's read the spirit. I've implemented this behaviour in > master branch. We'll see how it goes. Also, for those, like me, who > would rather read the letter, I've also modified the doc-string > accordingly. > Thanks for your suggestion. Thanks for the implementation, and of course, for the open spirit :-). François
Re: [O] C-a in lists when org-special-ctrl-a/e
On 12-Jan-23, at 3:30 PM, Nicolas Goaziou wrote: > pin...@iro.umontreal.ca (François Pinard) writes: > >> It all depends if we read the letter or the spirit of the second >> sentence. "[ ]" is a kind of TODO, and "[X]" is a kind of DONE, as >> demonstrated by the commands `C-x -' and `C-x *'. That's why I quite >> naturally expect the cursor to be positioned after the check box. > > Ok, then, let's read the spirit. I've implemented this behaviour in > master branch. We'll see how it goes. It's interesting... I've wished for this for a long time, but now that you've built it, I see a problem: "[" is not in the beginning of word regex set, so there is no easy way to get back to the "[". With that one sole exception, I think the behaviour gives a better user experience this way than the way it was before. It's easier to get to your text. -anthony
[O] [PATCH] Save undo history after org-edit-src-save.
It's been irritating me that after saving an edit buffer, the undo history disappears; the attached patch restores the undo history. diff --git a/lisp/org-src.el b/lisp/org-src.el index 8cdf81e..e85e04e 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -661,7 +661,7 @@ the language, a switch telling if the content should be in a single line." (setq org-edit-src-saved-temp-window-config nil (defmacro org-src-in-org-buffer (&rest body) - `(let ((p (point)) (m (mark)) msg) + `(let ((p (point)) (m (mark)) (ul buffer-undo-list) msg) (save-window-excursion (org-edit-src-exit 'save) ,@body @@ -670,6 +670,7 @@ the language, a switch telling if the content should be in a single line." (let ((org-src-window-setup 'current-window)) (org-edit-src-code 'save)) (org-edit-src-code 'save))) + (setq buffer-undo-list ul) (push-mark m 'nomessage) (goto-char (min p (point-max))) (message (or msg ""
Re: [O] LaTeX export: Keep point position in TeX file
Eric S Fraga writes: > If so, I suggest you could achieve what you want by using the > org-export-* hooks to, for instance, save current position before export > and then jump to that position after export? Maybe > org-export-first-hook and org-export-latex-final-hook could be used? > Thanks for your thoughts on this and sorry for being late to reply. I stumbled upon your reply and have tried it today with this: --8<---cut here---start->8--- (defun my-org-latex-export-save-point () (interactive) (let ((latexfile (concat (file-name-sans-extension (buffer-name)) ".tex")) (orgfile (buffer-name))) (if (get-buffer latexfile) (save-excursion (set-buffer latexfile) (setq temppoint (point))) (message "Open exported LaTeX file to save point position" --8<---cut here---end--->8--- `(interactive)' is only for testing purposes. Saving of point in .tex file under `temppoint' works this way. I tried further restoring point but failed. For reference: --8<---cut here---start->8--- (defun my-org-latex-export-restore-point () (interactive) (let ((latexfile (concat (file-name-sans-extension (buffer-name)) ".tex")) (orgfile (concat (file-name-sans-extension (buffer-name)) ".org"))) (progn (switch-to-buffer-other-frame (get-buffer latexfile)) (goto-char temppoint --8<---cut here---end--->8--- The switching to latex file works, but `(goto-char temppoint)' does not - for a reason I do not understand. The only benefit of this is that after export, emacs switches to the latex file automatically, which may or may not be wanted (in my case, it is). The last thing is to bind the functions to the correct hooks. I found this worked: --8<---cut here---start->8--- (add-hook 'org-export-latex-after-initial-vars-hook 'my-org-latex-export-save-point) (add-hook 'org-export-latex-after-save-hook 'my-org-latex-export-restore-point) --8<---cut here---end--->8--- > Untried and obviously untested! And likely beyond my elisp capabilities > so I'd be very keen on seeing a solution. This behaviour has also > bothered me (well, very minor irritation) for a long time as I often > export to latex when debugging the export to PDF. > It is also a minor irritation to me. And even if I could get my solution to work as intended, this approach only helps for minor edits, since the org-export could insert arbitrarily many new lines into the latex file, making the "restore by previous point position" rather useless. What would be needed is a context sensitive position check which can check for environments and contents simultaneously. Just guessing and thinking aloud here. A solution by hobby-elispers like me will be necessarily cumbersome, but maybe someone more skilled can pick up the scraps and make it work better :-) Best, Michael
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes:
> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> A quick question and a couple of comments on the LaTeX exporter.
>>
>> With the old exporter I set (setq org-export-latex-hyperref-format
>> "\\ref{%s}") so a link to a headline would cross reference properly in
>> LaTeX. How do I achieve this with the new exporter? I want my text to
>> read, e.g., "In section 1 ..." So far with the new exporter, I've only
>> been able to get "In section First headline ..."
>
> Indeed, it seems that I forgot to create that variable in the new
> exporter. I don't mind adding it, but I'm not sure about where it should
> apply.
>
> At the moment, "\\hyperref[%s]{%s}" format string is applied to id,
> custom-id, target, radio, fuzzy/target and fuzzy/headline links.
> Changing all those links with just a single variable seems wrong to me.
>
> Maybe it should replace the default value only for id, custom-id and
> fuzzy/headline. And since it would only apply to headlines, it could be
> renamed `org-e-latex-link-to-headline-format' or something alike.
>
> What do you think about all of this?
>
>> My initial impression is the new exporter is extremely fast.
>
> Unfortunately, it's only an impression. It will be slower than the
> current exporter in most cases.
>
> Oh, by the way, it reminds me that I implemented something in the LaTeX
> back-end that you had asked for a while ago. If you didn't notice it,
> you can try a LaTeX export on the following test buffer:
>
> #+latex_header: \usepackage{paralist}
>
> * Head 1
>
> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
> eiusmod tempor incididunt ut labore et dolore magna aliqua.
> #+attr_latex: inparaenum i.
> - item 1
> - item 2
> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
> eiusmod tempor incididunt ut labore et dolore magna aliqua.
>
> There is support for the following keywords: inparaenum, asparaenum,
> inparaitem, asparaitem, inparadesc, asparadesc, all accepting an
> optional bullet argument.
I've given the paralist facility a test run and it seems to work like a
charm. Thanks very much for augmenting the LaTeX exporter. This will
be a big help.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> The file name passed to \includegraphics is formed like this: >> ~/path/to/graphics/file >> >> My LaTeX doesn't recognize this as a path. >> >> The old exporter passed a file name where the tilde was expanded: >> /Users/user/path/to/graphics/file > > It should be fixed now. Thank you. > > > Regards, It is fixed. Thank you! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Prompts for `C-c .' and `C-c !'
Lolo le 13 writes: > Hi ! > > If I understood well, I think that the difference between C-c . and > C-c ! is that the timestamp is active or not. > > is an active date that appear in agenda view. So you have ti > use it if you want to see the task scheduled or deadlined. > > [DATE] format does not allow the timestamp to interact with agenda > view. It is used to indicate date just for information. You can include inactive timestamps in the agenda with the [ and ] keys. -Bernt
Re: [O] [ODT] image scaling overridden by long caption
Hello, Jambunathan K writes: > Does the existing behaviour as captured in [[Side-by-Side images laid > out by hand]] be preserved with new export driver? I'm not sure to get the syntax right, but in the new exporter, you can see what is the next or previous element, along with its properties. Thus, you can detect when two paragraphs are back to back, if they have appropriate :attr_latex properties and if they are enclosed in a parent center-block element. The check could be done at the paragraph level, and, if positive, org-odt-paragraph could return the ... string. Am I missing something? Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Eric Schulte writes: >> It's out of exporter's scope. > > I disagree. The current exporter conforms to the value of the :results > header argument (e.g., silent, replace, append, etc...) when executing > code blocks during export. I see no reason why the new exporter should > not as well. The new exporter conforms to the output of `org-export-blocks-preprocess'. It doesn't pay attention to header arguments. > Hmm, in light of this description it seems that the new export /should/ > have the same behavior WRT code block execution as the current > exporter. If not I wonder if a complete minimal example could be > provided. Martyn Jago provided one in this thread. Here it is: --8<---cut here---start->8--- * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 --8<---cut here---end--->8--- Regards, -- Nicolas Goaziou
Re: [O] C-a in lists when org-special-ctrl-a/e
pin...@iro.umontreal.ca (François Pinard) writes: > It all depends if we read the letter or the spirit of the second > sentence. "[ ]" is a kind of TODO, and "[X]" is a kind of DONE, as > demonstrated by the commands `C-x -' and `C-x *'. That's why I quite > naturally expect the cursor to be positioned after the check box. Ok, then, let's read the spirit. I've implemented this behaviour in master branch. We'll see how it goes. Also, for those, like me, who would rather read the letter, I've also modified the doc-string accordingly. Thanks for your suggestion. Regards, -- Nicolas Goaziou
Re: [O] (no subject)
I'd rather not change the default silently in this way. Could you provide a minimal example of the difference you describe? I just tried viewing the expanded form of the following code block and saw no difference between :noweb-ref and normal #+name: based expansions. * examples #+name: first #+begin_src sh echo 1 #+end_src #+begin_src sh :noweb-ref second echo 2 #+end_src #+begin_src sh :noweb yes <> <> #+end_src Thanks, Tom Regner writes: > From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001 > From: Tom Regner > Rcpt To: emacs-orgmode@gnu.org > Date: Mon, 23 Jan 2012 12:39:52 +0100 > Subject: [PATCH] ob.el Adhere to current :padline header during noweb > dereferencing. > > At the moment using the :noweb-ref: property approach on subtrees results in > the tangled code beeing broken > because the newlines before the #+end_src line are excluded from the output. > This patch uses :padline > to check if a newline should be added. The default being yes, tangling with > subtree mangling now produces correct > results; code depending on the (errorneous?) behaviour would be broken though. > --- > lisp/ob.el |9 ++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/lisp/ob.el b/lisp/ob.el > index 47be708..398a997 100644 > --- a/lisp/ob.el > +++ b/lisp/ob.el > @@ -2211,13 +2211,16 @@ block but are passed literally to the > \"example-block\"." >(nth 4 i)) >source-name) > (let* ((body (org-babel-expand-noweb-references > i)) > - (full (if comment > + (padded (if (not (string= "no" (cdr > (assoc :padline (nth 2 i) > + (concat body > "\n") > + body )) > + (full (if comment > ((lambda (cs) > (concat (c-wrap (car cs)) "\n" > - body "\n" > + padded "\n" > (c-wrap (cadr cs > (org-babel-tangle-comment-links > i)) > - body))) > + padded))) > (setq expansion (concat expansion full > expansion) > ;; possibly raise an error if named block doesn't exist -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] ob.el Adhere to current :padline header during noweb dereferencing.
At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken because the newlines before the #+end_src line are excluded from the output. This patch uses :padline to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct results; code depending on the (errorneous?) behaviour would be broken though. --- lisp/ob.el |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 47be708..398a997 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -2211,13 +2211,16 @@ block but are passed literally to the \"example-block\"." (nth 4 i)) source-name) (let* ((body (org-babel-expand-noweb-references i)) -(full (if comment +(padded (if (not (string= "no" (cdr (assoc :padline (nth 2 i) + (concat body "\n") + body )) +(full (if comment ((lambda (cs) (concat (c-wrap (car cs)) "\n" - body "\n" + padded "\n" (c-wrap (cadr cs (org-babel-tangle-comment-links i)) -body))) +padded))) (setq expansion (concat expansion full expansion) ;; possibly raise an error if named block doesn't exist -- 1.7.5.4
Re: [O] [ANN] ASCII back-end for new export engine
>> 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), >> as shown above, then the exporter appears to export the in-buffer >> results /and/ the export-generated results (where :exports is results >> or both) resulting in two sets of identical results in the export. > > It's out of exporter's scope. I disagree. The current exporter conforms to the value of the :results header argument (e.g., silent, replace, append, etc...) when executing code blocks during export. I see no reason why the new exporter should not as well. > When you ask to export some buffer, what is really parsed is a copy of > the current buffer with `org-export-blocks-preprocess' applied to it. > > So, simply apply that function in your test buffer, and you will see > what is sent to the parser. That will explain why the results appear > twice. > > In other words, tweaking the output of `org-export-blocks-preprocess' > will automatically change the outcome of the export process. > Hmm, in light of this description it seems that the new export /should/ have the same behavior WRT code block execution as the current exporter. If not I wonder if a complete minimal example could be provided. Thanks, > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Is it possible to include #+call lines in HTML export?
Leo Alekseyev writes: > Currently, my org files look something like this: > > * And now, let's do the analysis ! > #+call: foo(bar) > > #+results: > : earth-shattering results > : gonna land me a Nobel /and/ a Fields! > > But because #+call is not exported, it's not clear what function was > called and with what parameters. It makes a lot of sense for it to be > included in the export (unless its evaluation is turned off via e.g. > :eval no-export), but I can't find an option for this. > Currently what you describe is not possible. Call lines are by default replaced with their results on export. ... Alright, I just pushed up an addition which allows the specification of a call line export template to include information like the name of the call line used to generate the results. For example, add the following to your config and export a buffer with call lines. (setq org-babel-exp-call-line-template "\n: call: %line") Best, > > --Leo > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ODT] image scaling overridden by long caption
Hello Andreas I have added support for character anchored images as part of the following commit release_7.8.03-201-g1d99fd7. I am attaching a sample Org file and the associated ODT output. Nicolas/Eric Don't be surprised. Please Read on ... --8<---cut here---start->8--- #+TITLE: side-by-side.org #+AUTHOR:Jambunathan K #+EMAIL: kjambunat...@gmail.com #+DATE: 2012-01-23 Mon #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t #+OPTIONS: TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: #+XSLT: Nicolas, Does the existing behaviour as captured in [[Side-by-Side images laid out by hand]] be preserved with new export driver? Eric, 1. can the extraneous parbreaks in [[Side-by-Side images using Babel]] be removed? 2. Can [[http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00678.html][this issue with #+header lines ]] be fixed? * Side-by-Side images using Babel Creating side-by-side images with Babel is problematic. #+caption: foo #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file foo.png #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src #+caption: foo #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file foo.png #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src The images are vertically stacked because Babel introduces extraneous parbreaks. This forces the images to be anchored as character, but to *successive* paragraphs. Here is a segment of Org buffer as seen by the ODT exporter at the end of =org-export-preprocess-string=. #+BEGIN_SRC org ,Creating side-by-side images with Babel is problematic. ,[[file:foo.png][file:foo.png]] ,[[file:foo.png][file:foo.png]] ,The images are vertically stacked because Babel introduces extraneous ,parbreaks. This forces the images to be anchored as character, but to ,*successive* paragraphs. #+END_SRC * Side-by-Side images laid out by hand To create side-by-side images flank them with paragraph boundaries. #+BEGIN_CENTER #+caption: foo #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file foo.png [[./foo.png]] #+caption: bar #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file bar.png [[./bar.png]] #+END_CENTER You should be seeing side-by-side images. --8<---cut here---end--->8--- side-by-side.odt Description: side-by-side.odt >>> On a related note: Could I place two (correctly scaled) images >>> side-by-side? >> >> For the sake of record, your request is much similar to what is >> discussed here >> http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html - >> save for (dynamically-generated) images taking the place of src blocks. >> >> Try something like this: >> >> #+begin_list-table >> - [[./foo1.png]] >> - [[./foo2.png]] >> #+end_list-table >> >> Make sure that the images are "small" images. If you replace the image >> links above with R srcblocks or attach caption/attr_odt to the above >> above images, the results are less than satisfactory. So the answer to >> your question is a "soft" no. > > Thanks for this. For two reasons that does not work for me: > (1) I want to use captions on my images > (2) it is odt-export specific > >> >> Notes to self: >> >> There are multiple ways to achieve side-by-side effect. >> - use tables (aka "list tables") >> - use 2-Column sections >> - 2-column frames (what is this?) >> >> "side-by-side" has surfaced in the list for the second time, I think it >> deserves to be supported "out of the box". > > +1. And ideally generic enough, s.t. also the LaTeX supports it. > Beamer has the concept of columns, which is nicely supported in org > mode. Maybe that could be a general concept supported by all (or, most) > exporters? --
Re: [O] Prompts for `C-c .' and `C-c !'
Hi ! If I understood well, I think that the difference between C-c . and C-c ! is that the timestamp is active or not. is an active date that appear in agenda view. So you have ti use it if you want to see the task scheduled or deadlined. [DATE] format does not allow the timestamp to interact with agenda view. It is used to indicate date just for information. Lolo Le 23/01/2012 17:01, François Pinard a écrit : Hi, Org people! :-) Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and the date is prompted in the mini-buffer in the same way for both commands. One of them is going to insert, the other [DATE]. The mini-buffer always show, like this: Date+time [2012-01-23]: => <2012-01-23 lun> Could it be: Date+time [2012-01-23]: => [2012-01-23 lun] when appropriate? This feedback would be useful (to me at least), in case I mixed `C-c .' and `C-c !' in my head, and am using the wrong one. François
[O] Absolute paths in exported files
Hello!
An older topic was here:
http://lists.gnu.org/archive/html/emacs-orgmode/2010-01/msg00573.html
The problem seems to persist as of now for latex (and thus pdf)
export. The results are sort of diffuse though.
I am working with emacs on Cygwin using the latest git-version and
native Windows "Adobe Reader" and "Sumatra PDF" as PDF Viewers.
* Apparently [[file:file]] is exported as
\href{file://.file}{file:file} (note the extra period)
* The same happens with [[./file]] and other local paths like
[[file:plots/somefile.pdf]]
* For some reason sometimes relative paths get exported as absolute paths.
Examples:
[[file:/labbook.org]] => \href{file://./labbook.org}{file:/labbook.org}
[[./labbook.org]] => \href{file:///absolute/path/to/labbook.org}{./labbook.org}
[[./plot/test.plt]] => \href{file://../plot/test.plt}{./plot/test.plt}
[[/labbook.org]] => \href{file://./labbook.org}{/labbook.org}
In another org file:
[[./local.plt]] => \href{file://../local.plt}{./local.plt}
[[file:local.org]] => \href{file://.local.org}{file:local.org}
[[./local.org]] => \href{file://../local.org}{./local.org}
Also:
* file://relative/path - style urls fail to be opened (adobe reader
passes it to the browser, the browser treats it as absolute path).
Might also be related to the windows environment, but a PDF should be
portable anyway.
* Researching the problem, I read that hyperref's \href doesn't
support relative paths to begin with.
Any ideas? It works well for html export and for use within the
org-mode buffer, but it would be nice if the links in the PDF file
could support local files properly too (though I'm not sure if the
viewers even support this).
kind regards, Yu
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes: > The file name passed to \includegraphics is formed like this: > ~/path/to/graphics/file > > My LaTeX doesn't recognize this as a path. > > The old exporter passed a file name where the tilde was expanded: > /Users/user/path/to/graphics/file It should be fixed now. Thank you. Regards, -- Nicolas Goaziou
Re: [O] org-babel order of evaluation
Leo Alekseyev writes: > On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel wrote: >> On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote: >>> Rick Frankel writes: >>> >>> Turns out it was not that difficult to change this behavior. You and >>> Leo are both correct that in-buffer-order evaluation is more natural and >>> expected than the previous behavior. I've just pushed up a fix after >>> which evaluating the following > > Eric, > The fix doesn't seem to be working for me when I export the buffer to > HTML. My previous fix only set the order of evaluation for interactive buffer evaluation. I've just pushed up another fix which sets the order of evaluation during export. Best, > The ordering of call and source blocks once again becomes randomized, > and in general, exported file is missing a bunch of stuff unless I run > org-babel-execute-buffer prior to export. Since the export engine > does its own evaluation, it doesn't seem like org-babel-execute-buffer > should be a necessity. But I can't run org-babel-execute-buffer on > anything with a src_ inline block as it gives me an error. > > I'm attaching two files which do not export correctly, at least when > one doesn't run org-babel-execute-buffer; just do C-c C-e h and look > at the output. > > --Leo > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)
Fixed. Thanks, "Sebastien Vauban" writes: > Hi Eric, > > Eric Schulte wrote: >> there are two related functions which should help. >> >> ,[org-babel-view-src-block-info] bound to C-c C-v I >> | org-babel-view-src-block-info is an interactive Lisp function in >> | `ob.el'. >> | >> | (org-babel-view-src-block-info) >> | >> | Display information on the current source block. >> | This includes header arguments, language and name, and is largely >> | a window into the `org-babel-get-src-block-info' function. >> ` >> >> and >> >> ,[org-babel-check-src-block] bound to C-c C-v c >> | org-babel-check-src-block is an interactive Lisp function in `ob.el'. >> | >> | (org-babel-check-src-block) >> | >> | Check for misspelled header arguments in the current code block. >> ` > > When checking for suspicious header arguments on[1]: > > #+name: mean > #+begin_src emacs-lisp :var lst=() > (let ((num (car lst)) (nums (cdr lst))) > (/ (float (+ num (apply #'+ nums))) (1+ (length nums > #+end_src > > it reports: > > supplied header ""var"" is suspiciously close to ""dir"" > > Can you enlighten me on what's suspicious here? > > Best regards, > Seb > > Footnotes: > > [1] which is supposed to be used in the following table: > > | 1 | > | 2 | > | 3 | > | 4 | > | 5 | > | 6 | > | 3.5 | > #+TBLFM: @7$1='(sbe mean (lst @1..@6)) -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)
Have you tried using the `org-babel-noweb-error-langs' variable that I mentioned previously? It should help in these situations. Yu writes: > Hello again! > > I thought about the *noweb* part again. I tried the following: > > == > #+begin_src sh :tangle test.out :noweb tangle > <> > cat << test.org >> test.out2 > #+end_src > #+begin_src sh :noweb-ref task1 > echo "hello world" > #+end_src > == > > The tangled output file "test.out" looked like this: > == > /bin/sh > > echo "hello world" > cat test.out2 > == > > i.e. the syntactically valid "<< test.org >>" construct was omitted. > Thus a separate syntax for forcing a literal "<<" in the tangled > output is needed anyway (if not yet implemented) and if so, warning > about undefined code blocks should be possible too. > > The big relevance of warning about undefined and never used code > blocks struck me, when recently I tried to use it again. The natural > work flow to me would have been to write something like > > : The task at hand has an overall structure > : #+begin_src python :tangle foo.py :noweb tangle > : <> > : <> > : <> > : #+end_src > > When proceeding after this however I would have to keep in mind open > tasks or (slightly better) to instantly create TODO sections for said > blocks. However, having this order of working imposed on me sort of > defeats the purpose for my understanding. I'd rather prefer to do an > `M-x org-babel-tangle' tell me, that I forgot to implement one of the > partial tasks, rather than having to find out missing code blocks from > the output file (where, as mentioned, they result in "nothing" rather > than an unresolved "<<...>>" construct). > > kind regards, Yu > > > > 2012/1/14 Eric Schulte : >> Yu writes: >> >>> Hello! >>> >>> I was wondering, if there is a way to get warnings for typos (e.g. >>> when specifying invalid properties or header arguments). It can just >>> easily happen that I mix up e.g. ":exports" and ":export" (though >>> that's probably a very harmless example). >>> >> >> While there is currently no way to do this there are two related >> functions which should help. >> >> ,[org-babel-view-src-block-info] bound to C-c C-v I >> | org-babel-view-src-block-info is an interactive Lisp function in >> | `ob.el'. >> | >> | (org-babel-view-src-block-info) >> | >> | Display information on the current source block. >> | This includes header arguments, language and name, and is largely >> | a window into the `org-babel-get-src-block-info' function. >> ` >> >> and >> >> ,[org-babel-check-src-block] bound to C-c C-v c >> | org-babel-check-src-block is an interactive Lisp function in `ob.el'. >> | >> | (org-babel-check-src-block) >> | >> | Check for misspelled header arguments in the current code block. >> ` >> >> This problem is not trivial because new language are permitted to create >> and use *any* header arguments they like, so there are no /wrong/ header >> arguments, there are only /suspicious/ header arguments (like the >> :exports option you suggest). The above function reports any suspicious >> header arguments. Perhaps there would be a way to integrate the above >> function with flyspell for automatic highlighting of suspicious header >> arguments. I'll put looking into such integration on my long-term Org >> task queue. >> >>> >>> More important it gets though, when trying to use the literate >>> programming facilities. >>> >>> Say I have a source code >>> >>> #+begin_src sh :noweb tangle :tangle foo.sh >>> <> >>> #+end_src >>> #+begin_src sh :noweb-ref fo >>> echo '... how are you?'; >>> #+end_src >>> >>> then tangling would run through without any indication of the typo in >>> the name of the "foo" block. Such errors might be hard to debug, >>> because there is no indication of the error, maybe nothing other than >>> runtime errors. >>> >>> An error message for the /use/ of undefined references only wouldn't >>> avoid such problems either, e.g. consider >>> >>> #+begin_src sh :noweb tangle :tangle foo.sh >>> <> >>> #+end_src >>> #+begin_src sh :noweb-ref foo >>> echo 'Hello World...'; >>> #+end_src >>> #+begin_src sh :noweb-ref fo >>> echo 'Hello World...'; >>> #+end_src >>> >>> where the only detectable error is, that "fo" was never used anywhere. >>> >>> A similiar question (though without the second part) was asked here: >>> http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00273.html >>> As far as I can tell, it stands unanswered. >>> >> >> Yes, although in many languages constructs like <> are valid code, >> so it would be inappropriate for tangling to raise errors by default. >> It is possible to turn on such errors on a language-by-language basis, >> by customizing the following variable. >> >> ,[org-babel-noweb-error-langs] >> | org-babel-noweb-error-langs is a variable defined in `ob.el
Re: [O] org-babel functions for Io evaluation
Hi Andrzej, This looks wonderful, thanks for sharing! Would you be willing to complete the FSF copyright assignment [1] so that we can include this into the Org-mode core? If that is not possible then we could still distribute this in the contrib directory, but inclusion in the core is definitely preferable. Many Thanks, Andrzej Lichnerowicz writes: > Hello list. > > Attached file (also available at https://gist.github.com/1652684), > implements org-babel evaluation functions for Io language > (http://iolanguage.org). It's not yet fully functional (no value > results, and session support) as I'm still learning org-mode from > developer perspective, but if you're interested, I'd be happy to > contribute it. > > Best regards, > Andrzej > Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to include comments on export? org-exp-blocks.el?
There are currently begin/end_comment blocks implemented as part of org-exp-blocks.el. See the `org-export-blocks-format-comment' function which is fairly simple and should not be difficult to customize. Best, Samuel Wales writes: > We had a wonderful discussion of it once, along with different > possible uses for inline tasks, inclusion of paragraphs, non-exported > headlines for easier structure editing, universal syntax, and > returning text to higher level. > > On my blog I use a colored background, which could also serve as comment > blocks: > > #+HTML: > > Some text. > > #+HTML: > > A bit rudimentary perhaps. > > Samuel > > On 2011-10-24, Herbert Sitz wrote: >> I'm trying to see if there is a way to include comments on export, to show >> up as >> something like the comments boxes you see in MS Word. >> >> I see Eric Schulte did some work on this and that somehow it ended up (I >> think) >> as part of what you could do using the org-exp-blocks addon. But I'm not >> sure >> how you actually use it. >> >> Can someone give an example of how org-exp-blocks (or anything else) could >> be >> used to export comment blocks as graphic notes in the text? >> >> Thanks, >> >> Herb >> >> >> >> -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Leo Alekseyev writes: > Since all source blocks are evaluated on export, I don't think it > should be necessary to issue org-babel-execute-buffer before invoking > export. However, running HTML export without org-babel-execute-buffer > currently produces garbage output. > What do you mean by "garbage" output? > > On the other hand, I have several examples where running HTML export > _after_ org-babel-execute-buffer produces the wrong output due to the > fact that :results replace directive appears to append instead of > replacing the output > Could you isolate a minimal example demonstrating just the failure of results replacement? Thanks, > > I am attaching three simple examples where I simulate generating and > exporting image data (I just generate and print filenames). If I > understand the documentation correctly, they are all supposed to > produce identical output on HTML export; however, none of the files > produces the expected output, namely, blocks of the form: > > > | some output > | images/conv1.png > | > | images/conv1.png > \-- > > Here, the first two lines should be enclosed in a code block, and the > last line should be raw org output. > > To reproduce, load any of my examples, do > > C-c C-e h <- will produce garbage output on export > C-c C-v b <- will produce expected output in the buffer > C-c C-e h <- will produce extraneous output on export despite :results > replace being on > C-c C-v b <- will produce extraneous output in the buffer > > This was tested on my test-export4.org, but the other examples behave > in a similar fashion. > > --Leo > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [PATCH] narrowing in agenda file
Litvinov Sergey writes: > "Narrowing" in the agenda file does not "survive" agenda redo. Please > see an example in the first patch. I think the second patch fixes this > problem. Hi Sergey, I haven't had a chance to try your patch yet but I recently tried to fix this behaviour as well but there are other issues that crop up when you keep the narrowed region. Please make sure that at least the following work as expected with your patch: - org agenda clock reports are correct - You don't have the LOGBOOK drawer aligned with tags when clocking in from the agenda (this was with emacs -q (no org-indent-mode) - Column view in the agenda shows correct clocking amounts for each task - Visiting a task with RET or SPC goes to the task when outside the narrowed region - Remote editing of a task outside the narrowed region changes the target task and not something in your narrowed region instead I'm hoping your patch works since I also want this desired behaviour but so far my attempts to achieve this failed miserably :( Regards, Bernt
Re: [O] C-a in lists when org-special-ctrl-a/e
Nicolas Goaziou writes: > pin...@iro.umontreal.ca (François Pinard) writes: >> On check lists however, I would have expected a corresponding >> behavior. Currently, on the first C-a, the cursor moves back on the >> "[" character, while I think it should move after the space following >> "]". > According to the documentation: "In an item, this will be the position > after the bullet". Thus, that behaviour seems correct to me. Note > that check-boxes are not part of the bullet (text is indented below > them on second line of an item). The text says: When t, `C-a' will bring back the cursor to the beginning of the headline text, i.e. after the stars and after a possible TODO keyword. In an item, this will be the position after the bullet. It all depends if we read the letter or the spirit of the second sentence. "[ ]" is a kind of TODO, and "[X]" is a kind of DONE, as demonstrated by the commands `C-x -' and `C-x *'. That's why I quite naturally expect the cursor to be positioned after the check box. This is of course all debatable. I think the spirit and usefulness of org-special-ctrl-a/e would be better guaranteed, if the behavior was amended. François
Re: [O] customize agenda time boundaries
sergio writes: > On 01/23/2012 07:17 AM, Bernt Hansen wrote: > >> (setq org-agenda-start-on-weekday nil) >> >> C-c a a j -3 w > > OK, it works. But it's complicated and week was just an example. > How to do the same for 3 days? For one day (show 12 hours before, and 12 > after the current moment)? I don't know. You might be able to use org-agenda-span to accomplish some of this. Regards, Bernt
Re: [O] Prompts for `C-c .' and `C-c !'
pin...@iro.umontreal.ca (François Pinard) writes: > Hi, Org people! :-) > > Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and > the date is prompted in the mini-buffer in the same way for both > commands. One of them is going to insert , the other [DATE]. The > mini-buffer always show , like this: > >Date+time [2012-01-23]: => <2012-01-23 lun> > > Could it be: > >Date+time [2012-01-23]: => [2012-01-23 lun] > > when appropriate? This feedback would be useful (to me at least), in That's probably not worth the effort. If you use the wrong one just put point on the [ or < and hit S-up arrow to switch it. Regards, Bernt
Re: [O] org-e-latex remove logfiles
Hello, t...@tsdye.com (Thomas S. Dye) writes: > The documentation string for org-e-latex-remove-logfiles might better > be: > > "Non-nil means remove files with the extensions listed in > org-e-latex-extensions." I think that the first sentence of the doc-string should be a tad bit shorter. In an attempt to split it, what about something like: "Non-nil means remove some files created during PDF export. Any file whose extension is listed in `org-e-latex-extensions' will be deleted." Regards, -- Nicolas Goaziou
Re: [O] C-a in lists when org-special-ctrl-a/e
Hello, pin...@iro.umontreal.ca (François Pinard) writes: > On check lists however, I would have expected a corresponding > behavior. Currently, on the first C-a, the cursor moves back on the > "[" character, while I think it should move after the space following > "]". According to the documentation: "In an item, this will be the position after the bullet". Thus, that behaviour seems correct to me. Note that check-boxes are not part of the bullet (text is indented below them on second line of an item). Regards, -- Nicolas Goaziou
Re: [O] (no subject)
Tom Regner writes: > From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001 > From: Tom Regner > Rcpt To: emacs-orgmode@gnu.org > Date: Mon, 23 Jan 2012 12:39:52 +0100 > Subject: [PATCH] ob.el Adhere to current :padline header during noweb > dereferencing. [...] I'm awfully sorry -- shall I remail the patch without the errorneous empty line in between the headers, so that the patchwork server will receive it? kind regards, Tom
Re: [O] Side-by-side support
Hello Christian Christian Wittern writes: > On 2012-01-20 05:03, Jambunathan K wrote: >> "side-by-side" has surfaced in the list for the second time, I think it >> deserves to be supported "out of the box". > I strongly support this, since I have a lot of files with side-by-side > content. The first question is of course how does the org source look > like. I think laying out tables either "list tables" (or for that matter, it's "beamer equivalent") will become particularly "inconvenient" to edit. In both the cases, the two-dimensional structure is laid out along the single-dimension and it would become difficult to "remember" which column or row when one is editing at a given point in time. > In my case, I have simply separated the columns by a character > and set the tab-width to a sensible value for nice on-screen display. > These are 'text' and 'translation of that text' side-by-side, When you are saying on-screen display, I presume you are referring to the Emacs screen? I have a strong feeling that you are using two column editing. Otherwise, it would be extremely difficult to keep one's sanity. See C-h k C-x 6 2 (info "(emacs) Two-Column"). I have a wild-thought. Why not use use 2C editing for creating multi-paragraph Org tables. I am Ccing Nicolas (who is likely to have thought more about this stuff) since the last conversation. > sometimes interrupted by section headers, notes and so on. Therefore I > end up with multiple 'tables', which will need to have the same width > throughout the document. Therefore for this use-case, I would like to > see a global setting for the relative width of these columns. --
[O] Why functions like org-show-subtree are undocumented?
Hi all, I just reviewed code in org.el and noticed that function org-show-subtree, which is called by org-cycle, unconditionally shows whole subtree (exactly what I wanted to have in my shortcuts!). So the question is - why such useful functions like org-show-subtree, hide-subtree, show-children aren't documented in manual? Because of that, previously I thought that what I wanted was impossible (without source change). Thanks
[O] Prompts for `C-c .' and `C-c !'
Hi, Org people! :-) Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and the date is prompted in the mini-buffer in the same way for both commands. One of them is going to insert , the other [DATE]. The mini-buffer always show , like this: Date+time [2012-01-23]: => <2012-01-23 lun> Could it be: Date+time [2012-01-23]: => [2012-01-23 lun] when appropriate? This feedback would be useful (to me at least), in case I mixed `C-c .' and `C-c !' in my head, and am using the wrong one. François
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes:
> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> #+CAPTION[An example photograph]: An example photograph.
>> #+NAME: fig:photo
>>
>> for me, yields:
>>
>> \caption{\label{fig:photo}An example photograph}
>>
>> I was expecting:
>>
>> \caption[An example photograph]{\label{fig:photo}An example
>> photograph}
>
> I get the expected caption command in that case, even from a fresh emacs
> -q. You may need to reload Org, or even Emacs.
>
>
> Regards,
Thanks, that worked.
The file name passed to \includegraphics is formed like this:
~/path/to/graphics/file
My LaTeX doesn't recognize this as a path.
The old exporter passed a file name where the tilde was expanded:
/Users/user/path/to/graphics/file
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] Prompts for C-. and
Re: [O] typo in doc/orgguide.texi
Hi Guido, Guido Arnold writes: > Hello, > please forgive me for not filing a proper bug report, I am not even a > org-mode user yet, but I am very interested. I just had a look at the > quick guide and found a typo in line 1908: > http://orgmode.org/w/?p=org-mode.git;a=blob;f=doc/orgguide.texi;h= > 0e6295a121a6ac0b2eb8738c1156f2672c24548d;hb=minted > > s/will also works/will also work/ > ^ > I hope someone with write privileges on this list can fix this. Fixed, thanks! http://orgmode.org/w/?p=org-mode.git;a=commit;h=8a7799473c90e71bff460c63a71e7551dfa4e4e2 -- Bastien
[O] [PATCH] narrowing in agenda file
"Narrowing" in the agenda file does not "survive" agenda redo. Please see an example in the first patch. I think the second patch fixes this problem. >From 60ef46625131391c6a49fccd26861f933a984515 Mon Sep 17 00:00:00 2001 From: Litvinov Sergey Date: Mon, 23 Jan 2012 14:22:53 +0100 Subject: [PATCH 1/2] Add a test "narrowed" agenda file --- testing/examples/org-agenda-test.org | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 testing/examples/org-agenda-test.org diff --git a/testing/examples/org-agenda-test.org b/testing/examples/org-agenda-test.org new file mode 100644 index 000..ecd00e5 --- /dev/null +++ b/testing/examples/org-agenda-test.org @@ -0,0 +1,10 @@ +#+Title: a collection of examples for org-agenda tests +* TODO should be visible +ob-agenda-test.org buffer should be narrowed after execution of this block +#+BEGIN_SRC elisp :results silent + (let ((org-agenda-files (list buffer-file-name))) +(narrow-to-region 1 (- (buffer-size) 23)) +(org-agenda nil "t") +(org-agenda-redo)) +#+END_SRC +* TODO should be hidden -- 1.7.3.4 >From 188d95624fec5d53403fd705679167ed7d7345a2 Mon Sep 17 00:00:00 2001 From: Litvinov Sergey Date: Mon, 23 Jan 2012 14:26:14 +0100 Subject: [PATCH 2/2] Make narrowing of the agenda file survive (org-agenda-redo) * lisp/org.el (org-prepare-agenda-buffers): move '(save-excursion (save-restriction' construction --- lisp/org.el | 67 +-- 1 files changed, 33 insertions(+), 34 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index f6a1160..9e23c18 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16498,47 +16498,46 @@ When a buffer is unmodified, it is just killed. When modified, it is saved (inhibit-read-only t) (rea (concat ":" org-archive-tag ":")) bmp file re) -(save-excursion - (save-restriction (while (setq file (pop files)) (catch 'nextfile (if (bufferp file) (set-buffer file) (org-check-agenda-file file) (set-buffer (org-get-agenda-file-buffer file))) - (widen) - (setq bmp (buffer-modified-p)) - (org-refresh-category-properties) - (setq org-todo-keywords-for-agenda - (append org-todo-keywords-for-agenda org-todo-keywords-1)) - (setq org-done-keywords-for-agenda - (append org-done-keywords-for-agenda org-done-keywords)) - (setq org-todo-keyword-alist-for-agenda - (append org-todo-keyword-alist-for-agenda org-todo-key-alist)) - (setq org-drawers-for-agenda - (append org-drawers-for-agenda org-drawers)) - (setq org-tag-alist-for-agenda - (append org-tag-alist-for-agenda org-tag-alist)) - (save-excursion - (remove-text-properties (point-min) (point-max) pall) - (when org-agenda-skip-archived-trees - (goto-char (point-min)) - (while (re-search-forward rea nil t) - (if (org-at-heading-p t) - (add-text-properties (point-at-bol) (org-end-of-subtree t) pa - (goto-char (point-min)) - (setq re (format org-heading-keyword-regexp-format - org-comment-string)) - (while (re-search-forward re nil t) - (add-text-properties - (match-beginning 0) (org-end-of-subtree t) pc))) - (set-buffer-modified-p bmp) -(setq org-todo-keywords-for-agenda - (org-uniquify org-todo-keywords-for-agenda)) -(setq org-todo-keyword-alist-for-agenda - (org-uniquify org-todo-keyword-alist-for-agenda) - org-tag-alist-for-agenda (org-uniquify org-tag-alist-for-agenda + (save-restriction + (widen) + (setq bmp (buffer-modified-p)) + (org-refresh-category-properties) + (setq org-todo-keywords-for-agenda + (append org-todo-keywords-for-agenda org-todo-keywords-1)) + (setq org-done-keywords-for-agenda + (append org-done-keywords-for-agenda org-done-keywords)) + (setq org-todo-keyword-alist-for-agenda + (append org-todo-keyword-alist-for-agenda org-todo-key-alist)) + (setq org-drawers-for-agenda + (append org-drawers-for-agenda org-drawers)) + (setq org-tag-alist-for-agenda + (append org-tag-alist-for-agenda org-tag-alist)) + (save-excursion + (remove-text-properties (point-min) (point-max) pall) + (when org-agenda-skip-archived-trees + (goto-char (point-min)) + (while (re-search-forward rea nil t) + (if (org-at-heading-p t) + (add-text-properties (point-at-bol) (org-end-of-subtree t) pa + (goto-char (point-min)) + (setq re (format org-heading-keyword-regexp-format + org-comment-string)) + (while (re-search-forward re nil t) + (add-text-properties + (match-beginning 0) (org-end-of-subtree t) pc))) + (set-buffer-modified-p bmp) + (setq org-todo-keywords-for-agenda + (org-uniquify org-todo-keywords-for-agenda)) + (setq org-todo-keyword-alist-for-agenda + (org-uniquify org-todo-keyword-alist-for-agenda) + org-tag-alist-for-agenda (org-uniquify org-tag-alist-for-agenda Embedded
[O] C-a in lists when org-special-ctrl-a/e
Hi, Org people. This morning, I activated org-special-ctrl-a/e (setting it to "t"). It works as documented on header lines having TODO keywords. On check lists however, I would have expected a corresponding behavior. Currently, on the first C-a, the cursor moves back on the "[" character, while I think it should move after the space following "]". François
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes:
[...]
>
> As a side note, #+label has been deprecated in favor of #+name (though
> the former is immediately translated into the latter at parse time).
Sorry for hijacking this thread. But this side note is only valid for
the new exporter, correct? As it does not yield the expected result in
the current LaTeX and odt exporter (the only ones I tried).
== test.org ===
* Test name
#+caption: Test name
#+name: testname
#+begin_src R :exports results :results graphics :file foo.png
plot(1)
#+end_src
As can be seen in Figure \ref{testname}...
As can be seen in Figure [[testname]]
#+caption: Test name 2
#+label: testnametwo
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnametwo}...
As can be seen in Figure [[testnametwo]]
#+caption: Test name 3
#+label: testnamethree
#+name: testnamethree
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnamethree}...
As can be seen in Figure [[testnamethree]]
===
Best,
Andreas
[O] (no subject)
>From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001 From: Tom Regner Rcpt To: emacs-orgmode@gnu.org Date: Mon, 23 Jan 2012 12:39:52 +0100 Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing. At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken because the newlines before the #+end_src line are excluded from the output. This patch uses :padline to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct results; code depending on the (errorneous?) behaviour would be broken though. --- lisp/ob.el |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 47be708..398a997 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -2211,13 +2211,16 @@ block but are passed literally to the \"example-block\"." (nth 4 i)) source-name) (let* ((body (org-babel-expand-noweb-references i)) -(full (if comment +(padded (if (not (string= "no" (cdr (assoc :padline (nth 2 i) + (concat body "\n") + body )) +(full (if comment ((lambda (cs) (concat (c-wrap (car cs)) "\n" - body "\n" + padded "\n" (c-wrap (cadr cs (org-babel-tangle-comment-links i)) -body))) +padded))) (setq expansion (concat expansion full expansion) ;; possibly raise an error if named block doesn't exist -- 1.7.5.4
Re: [O] [bug] Tables in lists not exported to ODT
On 1/23/12 11:48 AM, Andreas Leha wrote: Jambunathan K writes: Just pushed a fix whereby one can control the width of the tables. Thanks for this very useful feature. Works nicely for me. +1! Thanks, Christian
Re: [O] [bug] Tables in lists not exported to ODT
Jambunathan K writes: > Jambunathan K writes: > >> Btw, I was trying to make the tables cute-looking > > Just pushed a fix whereby one can control the width of the tables. > > , commit f9d242 > | Customize table width using :rel-width option. For example, to create a > | table of width 60% use: > | > | #+attr_odt: :rel-width 60 > | > | | A | B | > | |---+---| > | | | | > ` Thanks for this very useful feature. Works nicely for me. - Andreas
Re: [O] Inconsistency in odt export to other exporters
Jambunathan K writes: >> The following snippet exports correctly to LaTeX and to html, but >> produces the text "Figure Figure" in odt. > > Fixed. Works great for me, thanks! And thanks for all these fast responses! Best, Andreas
Re: [O] Capitalisation and good taste ?
Bernt Hansen writes:
> Eric S Fraga writes:
>
>> Bernt Hansen writes:
>>
>>
>> [...]
>>
>>> I added the following to my .emacs to keep lowercase.
>>
>> Thanks. This is a great suggestion! Two possible typos, by the way,
>> that would only affect you if you use muse tags:
>>
>>> ("v" "#+begin_verse\n?\n#+end_verse" "\n?\n/verse>")
>>> ("c" "#+begin_center\n?\n#+end_center" "\n?\n/center>")
>>
>> Missing "<" for closing tag in each case, after last \n.
>
> I just took the default setting and lowercased it without actually
> looking closely at it -- so I think the problem is in the defcustom in
> org.el for org-structure-template-alist too.
>
> Regards,
> Bernt
Indeed. Attached is a very simple patch to fix these missing "<"s. Untested.
diff --git a/lisp/org.el b/lisp/org.el
index f6a1160..f47a104 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11031,9 +11031,9 @@ This function can be used in a hook."
("q" "#+BEGIN_QUOTE\n?\n#+END_QUOTE"
"\n?\n")
("v" "#+BEGIN_VERSE\n?\n#+END_VERSE"
- "\n?\n/verse>")
+ "\n?\n")
("c" "#+BEGIN_CENTER\n?\n#+END_CENTER"
- "\n?\n/center>")
+ "\n?\n")
("l" "#+BEGIN_LaTeX\n?\n#+END_LaTeX"
"\n?\n")
("L" "#+LaTeX: "
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.192.g32af.dirty)
Re: [O] Organizing by time or by subject and an idea
Max Mikhanosha writes: > At Fri, 20 Jan 2012 12:04:51 -0600, > John Hendy wrote: [...] > Generally I think the way to tackle this is to take advantage that you > are working with plain text and not with Word document, and use > standard Emacs/Unix tools for working with text. Agreed! > Some ideas: > > Before updating each project, cut-n-paste it into the new > revision.. Org mode makes it easy to cut-n-paste trees, for myself > duplicating a headline is simply pressing Y then P over a folded > headline (viper/vimpulse user) Is it not easier to simply make use of any of the revision control systems (git, mercurial, svn, even RCS) that are out there? You can easily tag a particular revision based on milestones and then see diffs between the current content and any previous version. In terms of the original questions, I use a combination of hierarchical structure that is filled in as a project develops, with revision control to allow me to see progress, together with a log based recording of activities (e.g. meetings, deliverables delivered, issues raised). That is, I mix both of the approaches mentioned by John in his initial email. The key, as John has already stated, is to record everything! With emacs, I can usually pull out what I want *if* the information was recorded in the first place. Finally, tags can be very useful for quick searching as well. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.8.03 (release_7.8.03.192.g32af)
Re: [O] Inconsistency in odt export to other exporters
> The following snippet exports correctly to LaTeX and to html, but > produces the text "Figure Figure" in odt. Fixed.
