[O] Header ':comments noweb' mangles lines in tangled code
Hello,
consider the following example Org document:
-- 8 --
#+TITLE: Example
#+AUTHOR: Vladimir Lomov
* How ~comments~ interferes with ~noweb~
#+NAME: code1
#+BEGIN_SRC sh
var1
#+END_SRC
#+NAME: code2
#+BEGIN_SRC sh
[[ -t ${SHELL} ]]
#+END_SRC
#+BEGIN_SRC sh :noweb yes :tangle ex-sh.sh
code1 = code1
code2 {
echo HELLO...
}
#+END_SRC
** Now ~comments~ is on
At first, ~comments~ is ~link~
#+BEGIN_SRC sh :noweb yes :tangle ex-c:link.sh :comments link
code1 = code1
code2 {
echo HELLO...
}
#+END_SRC
Then ~comments~ is ~org~
#+BEGIN_SRC sh :noweb yes :tangle ex-c:org.sh :comments org
code1 = code1
code2 {
echo HELLO...
}
#+END_SRC
Now ~comments~ is ~both~
#+BEGIN_SRC sh :noweb yes :tangle ex-c:both.sh :comments both
code1 = code1
code2 {
echo HELLO...
}
#+END_SRC
And finally, ~comments~ is ~noweb~
#+BEGIN_SRC sh :noweb yes :tangle ex-c:noweb.sh :comments noweb
code1 = code1
code2 {
echo HELLO...
}
#+END_SRC
-- 8 --
All combinations except ':comments noweb' give expected results, while
the last one produces a file with mangled lines,
- 8 ex-c:noweb.sh 8 --
# [[file:ex.org::*Now%20~comments~%20is%20on][Now\ ~comments~\ is\ on:4]]
# [[file:~/tmp/ex.org::*How%20~comments~%20interferes%20with%20~noweb~][code1]]
var1
# code1 ends here = #
[[file:~/tmp/ex.org::*How%20~comments~%20interferes%20with%20~noweb~][code1]]
code1 = var1
code1 = # code1 ends here
# [[file:~/tmp/ex.org::*How%20~comments~%20interferes%20with%20~noweb~][code2]]
[[ -t ${SHELL} ]]
# code2 ends here {
echo HELLO...
}
# Now\ ~comments~\ is\ on:4 ends here
-- 8 --
Is it expected behaviour meaning a limitation of ':comments noweb' or a
bug?
I'm using Org mode:
Org-mode version 8.2.5h (release_8.2.5h-777-g5d8cc3
@/usr/share/emacs/site-lisp/org/)
---
WBR, Vladimir Lomov
--
My mother was a test tube; my father was a knife.
-- Friday
Re: [O] HTML table export options essentially undocumented
Hello,
** James Harkins [2014-03-18 13:52:10 +0800]:
The documentation here seems rather un-detailed.
http://orgmode.org/manual/Tables-in-HTML-export.html#Tables-in-HTML-export
What I wanted to do was to have vertical rules between all columns, but not
horizontal rules. Neither this section of the documentation, nor the
docstring for org-html-table-default-attributes, provide any details on how
to do this.
It's a rather busy day and I'm not in the mood to scour through the elisp
sources, so, could someone please enlighten (and fix the docs)?
AFAIU, in current state table decoration is hard coded into exporter.
But that doesn't mean you cannot change they style. Take a look on this
small example:
-- 8 --
#+TITLE: Table with borders
#+AUTHOR: Vladimir Lomov
#+HTML_HEAD_EXTRA: link rel=stylesheet type=text/css href=tbl.css /
* Small table
| Name | Address|
|--+|
| Clifford, A. | Kensington Av. |
| Euler, G | Krechet Str. |
* CSS Style:noexport:
#+BEGIN_SRC css :tangle tbl.css
table {
border: solid 1px;
}
td {
border: solid 1px;
}
#+END_SRC
-- 8 --
How to try: tangle the SRC block and then export the document into HTML.
Open it in any web-browser that supports CSS.
hjh
---
WBR, Vladimir Lomov
--
Some people have a way about them that seems to say: If I have
only one life to live, let me live it as a jerk.
Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
Eric Schulte schulte.e...@gmail.com writes:
John Hendy jw.he...@gmail.com writes:
On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte schulte.e...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug rai...@krugs.de wrote:
On 02/07/14, 17:47 , Eric Schulte wrote:
Rainer M Krug rai...@krugs.de writes:
On 02/07/14, 07:18 , John Hendy wrote:
Greetings,
I don't usually tangle, but am creating a code file to go along with a
presentation I'm giving this weekend so that attendees can try things
out afterward by cloning my github repo where all the data and
necessary files are stored.
In my presentation (Beamer), I create plots via the R pdf() device,
and noticed that all of the tangled code where plots are generated
contains the following:
pdf(file=file.pdf); tryCatch({
code block contents here
},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
paste('ERROR', e$message, sep=' : ')}); dev.off()
Is there a way to omit this?
This is a bug which must have been introduced some time ago - in the
stock version of emacs (Org-mode version 7.9.3f
(release_7.9.3f-17-g7524ef @
/usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
tangle the enclosing commands to create graphics, but in 8.2 it does (I
don't have an older version at hand to go further back).
I believe this was introduced by your commit eaa3a761d. Reversion of
which with the following should provide a temporary workaround.
I take this back, the behavior is unrelated to Rainer's commit adding
try/catch blocks to R graphics creation logic.
In fact I don't believe this is a bug, rather the default behavior is to
expand code block bodies on tangling. This behavior may be changed by
using the :no-expand header argument which will inhibit code block body
expansion during tangling.
Got it, and thanks for the new variable tip!
Out of curiosity, is there a consensus that this is the preferred
behavior for tangling by default?
There may have been a consensus in a single thread motivated by a single
use case, which should not necessarily be a global consensus.
I'm guessing at some point it was decided that the need was preferred
to have these bits inserted before/after code blocks, but just trying
to confirm this. It seems odd to me, at least given R's behavior, that
someone would prefer these bits to show up in the tangled file since
they appeared to serve the purpose of having Org not fail during
export vs. benefitting the code in any way (if I wasn't running code
through R, I'd just get the errors directly).
I'd be happy to add :no-expand to the default R header arguments. Or
even to change this behavior globally, if the current behavior is
universally surprising.
I think the default behavior should be reverted, as tangling and
exporting are two different things. When I tangle, I want to see the
code blocks as they are in the org document (with possible variables and
expansions) but not to create files where I do not put it explicitly
into a code block. These wrappers have nothing to do with the code, and
are only there for the exported engine. So I would either revert to the
original behavior, or, introduce a new header argument,
e.g. :include-wrappers, which would, if set to t, include the export
wrappers in the tangled file. This might be useful for debugging
exporting of code block results, but not for general tangling.
Cheers,
Rainer
Best,
John
Best,
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
--
Rainer M. Krug
email: RMKrugatgmaildotcom
pgpbTlCE4agPe.pgp
Description: PGP signature
Re: [O] \344 in org agenda date string only
Am 06.03.2014 21:28, schrieb Rainer Stengele: All since a few days I see \344 instead of German ä, but only in the date string part of the agenda. The collected headlines from my org files show German Umlaute ä,ö,ü correctly. Also all Org files look good. I wonder if someone has an idea how this can be removec. I run org 8.2.5h and Emacs 24.3.1 on Windows and Linux Thank you, Rainer Hat irgendein deutscher User eine Idee? Has any German speaking user an idea? Thank you, Rainer
Re: [O] HTML table export options essentially undocumented
Hello, James Harkins jamshar...@gmail.com writes: The documentation here seems rather un-detailed. http://orgmode.org/manual/Tables-in-HTML-export.html#Tables-in-HTML-export What I wanted to do was to have vertical rules between all columns, but not horizontal rules. Neither this section of the documentation, nor the docstring for org-html-table-default-attributes, provide any details on how to do this. Did you try column groups? (info (org) Column groups) It is not back-end specific. Regards, -- Nicolas Goaziou
Re: [O] [patch][ox-html] Stylistic changes
On 2014-03-17 23:36, Rasmus wrote: Rick Frankel r...@rickster.com writes: On Mon, Mar 17, 2014 at 11:19:27PM +0100, Rasmus wrote: Hi Rick, Rick Frankel r...@rickster.com writes: On Mon, Mar 17, 2014 at 03:17:10AM +0100, Bastien wrote: Hello, Nicolas Goaziou n.goaz...@gmail.com writes: So if the change is only stylistic, I see no reason to break compatibility with ox-freemind.el. I would favor a solution where the HTML backend uses what's readable (mdash; and friends) and where the Freemind backend deals with this. Maybe `org-html-special-string-regexps' could be a variable and Freemind could temporarily set it up to what it needs? The use of numeric vs. named entities is not just stylistic. XHMTL[45] only support the 5 basic named entities interally: - amp; - the ampersand - quot; - the double quote - apos; single quote ' - lt; - less-than - gt; - greater-than So including any others will generate non-conforming output. Since the change is cosmetic, I don't see the purpose in adding a lot of conditional code to the exporter to output different entities for html[45] vs xhtml[45]. AFAIK, we have a lot more entities in org-entities with PRETTY-NAME;. When I've entities I've used a pretty name over a numeric value when I found one. What's you'r opinion on that? Should we go for readable or aim towards replacing them with these numeric values? We should use only those named entities (above) which are valid in xhtml(5). So, yes, we should change to using numeric entites for any other than the above. Since Emacs knows both the codepoints and the hex for utf8 entities it may be fairly simple to change the HTML representations, though I don't like it. . . When you refer above to utf-8 entities, do you mean the named html entities (e.g., lt;) or the actual utf-8 encoded characters? I believe the named entities are encoding independent, while including encoded characters in html output is fine -- although making sure the page is served with the correct character encoding is another issue entirely. As to using a more extensive set of named entities, as i said above, the problem is that the xhtml flavors don't support them, and I don't see any advantage in making the exporter handle character encoding differently based on ouput doctype. As Nicolas would point out, you can always use a filter to map all the entities in the output. rick
[O] [PATCH] Write org variables into own R environment instead of .GlobalEnv
* (org-babel-R-assign-elisp): replaced simple assignments of variables
to variables in R with assignments into an environment called 'org'
and lock these so that they can not be modified anymore.
* (org-babel-expand-body:R): wrap the call
of `org-babel-variable-assignments:R' into
- detachment of org environment
- creation of new environment org to delete the old environment
- locking of the org environment to prevent adding of bindings
- appending of environment to search path of R
These patch implements the writing of org variables into a separate R
environment and attaches it to the search path. This solves several
not so nice issues:
1) The org variables are now grouped and can be seen via 'ls(org)' in
R
2) As the environment org and all bindings are locked, the variables
can not be accidentally deleted. They can be overwritten, but they can
be =restored by simply deleting the variable in R or by using
`org$VARIABLE' instead of `VARIABLE'
3) All variables can be saved by simply calling `save(org, FILENAME'
in R which makes it possible to store all variable definitions for
tangling in one file.
---
lisp/ob-R.el | 47 +++
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 62aa7f2..da2aea2 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -103,8 +103,12 @@ this variable.)
(append
(when (cdr (assoc :prologue params))
(list (cdr (assoc :prologue params
- (org-babel-variable-assignments:R params)
- (list body)
+'(try(detach(org), silent=TRUE))
+ '(org - new.env())
+(org-babel-variable-assignments:R params)
+'(lockEnvironment(org))
+'(attach(org))
+(list body)
(when (cdr (assoc :epilogue params))
(list (cdr (assoc :epilogue params)))
(if graphics-file
@@ -203,20 +207,31 @@ This function is called by `org-babel-execute-src-block'.
TRUE FALSE))
(row-names (if rownames-p 1 NULL)))
(if (= max min)
- (format %s - read.table(\%s\,
- header=%s,
- row.names=%s,
- sep=\\\t\,
- as.is=TRUE) name file header row-names)
- (format %s - read.table(\%s\,
- header=%s,
- row.names=%s,
- sep=\\\t\,
- as.is=TRUE,
- fill=TRUE,
- col.names = paste(\V\, seq_len(%d), sep =\\))
- name file header row-names max
-(format %s - %s name (org-babel-R-quote-tsv-field value
+ (format assign(
+ '%s',
+ read.table(\%s\,
+ header=%s,
+ row.names=%s,
+ sep=\\\t\,
+ as.is=TRUE
+ ),
+ envir = org
+ )
+ lockBinding('%s', org) name file header row-names name)
+ (format assign(
+ '%s',
+ read.table(\%s\,
+ header=%s,
+ row.names=%s,
+ sep=\\\t\,
+ as.is=TRUE,
+ fill=TRUE,
+ col.names = paste(\V\, seq_len(%d), sep =\\)
+ ),
+ envir = org
+ )
+ lockBinding('%s', org) name file header row-names max
name
+(format assign('%s', %s, envir = org); lockBinding('%s', org) name
(org-babel-R-quote-tsv-field value) name)))
(defvar ess-ask-for-ess-directory) ; dynamically scoped
(defun org-babel-R-initiate-session (session params)
--
1.8.5.2 (Apple Git-48)
--
Rainer M. Krug
email: RMKrugatgmaildotcom
PGP: 0x0F52F982
pgp4BCq73wsCj.pgp
Description: PGP signature
Re: [O] Filter in Captured Column View
Hi Mats, You can add :skip-empty-rows t to the columnview header, so that rows with no Status property will not show. This, however, will also hide the Release headers. Workaround is to add a dummy 'Status' property to these. Doc here: http://orgmode.org/manual/Capturing-column-view.html .j. On Tue, Mar 18, 2014 at 12:38:52PM +0100, Mats Kindahl wrote: I am using the capture column view to capture the contents of a subtree at the beginning of the subtree. However, there are a lot of sections that do not contain anything interesting for the capture in question, so I would like to filter out anything except trees with certain tags. So, for the example below, it shows some headers at the beginning that I would like to avoid showing. Only in information on the individual releases should be shown as groups. Best wishes, Mats Kindahl * Report :PROPERTIES: :COLUMNS: %ITEM %Status :END: #+BEGIN: columnview :hlines 3 :id local | ITEM | Status| |--+---| | * Report | | |--+---| | ** Uninteresting summary | | |--+---| | ** Details | | |--+---| | *** Release 1| | | Feature #1 | Design| |--+---| | *** Release 2| | | Feature #2 | Confused | | Feature #3 | Completed | | Feature #4 | Coding| |--+---| | *** Release 3| | | Feature #5 | Baffled | #+END: ** Uninteresting summary ** Details *** Release 1 Feature #1 :PROPERTIES: :Status: Design :END: *** Release 2 Feature #2 :PROPERTIES: :Status: Confused :END: Feature #3 :PROPERTIES: :Status: Completed :END: Feature #4 :PROPERTIES: :Status: Coding :END: *** Release 3 Feature #5 :PROPERTIES: :Status: Baffled :END:
[O] Write org variables into own R environment instead of .GlobalEnv
Hi I just send a patch which changes the behaviour of how org variables are treated in R. At the moment, org variables are simply stored in the .GlobalEnv which means, that all show up in the variable listing (which can get cluttered when having many variables), they can accidentaly be deleted and not be restored from within R and saving all the variables into from R to make them available after tangling is not that easy. Therefore the patch writes the variables into their own environment (which I simply called org) and locks the environment and the bindings. This means, that the actual variable values are always in the environment and can not be accidentally deleted. As the environment is attached to the search path, they are accessible as before, but they do not clutter the workspace and do not show up separately e=when using ls() to list the contents of the workspace. When using ls(org) all can be seen. They can still be overwritten, but but this only creates a new variable of the ame name in the .GlobalEnv which is simply hidint the original variable passed from org. The original variable can be accessed via org$VARIABLENAME. When removing the defined variable VARIABLENAME via rm(VARIABLENAME), the value passed from org is back. In addition, all variables can be easily be saved to disk by using save(org, file=/PATH/TO/FILE.Rdata) and reloaded with (load(/PATH/TO/FILE.Rdata)). This mechanism could actually be included into tangling as the default mechanism to load the variables to avoid cluttering the code with all the assignment commands of the org variables. The patch is not yet extensively tested. Please provide some feedback about the idea and implementation, Cheers, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom PGP: 0x0F52F982 pgp8YQdhBAMfQ.pgp Description: PGP signature
Re: [O] Filter in Captured Column View
Thanks Juan, It seems to work, so I'll use that for now, but having some sort of filtering supported would be a great feature. I'll play around a little and see if that can be added. Best wishes, Mats Kindahl On 03/18/2014 03:08 PM, Juan Pechiar wrote: Hi Mats, You can add :skip-empty-rows t to the columnview header, so that rows with no Status property will not show. This, however, will also hide the Release headers. Workaround is to add a dummy 'Status' property to these. Doc here: http://orgmode.org/manual/Capturing-column-view.html .j. On Tue, Mar 18, 2014 at 12:38:52PM +0100, Mats Kindahl wrote: I am using the capture column view to capture the contents of a subtree at the beginning of the subtree. However, there are a lot of sections that do not contain anything interesting for the capture in question, so I would like to filter out anything except trees with certain tags. So, for the example below, it shows some headers at the beginning that I would like to avoid showing. Only in information on the individual releases should be shown as groups. Best wishes, Mats Kindahl * Report :PROPERTIES: :COLUMNS: %ITEM %Status :END: #+BEGIN: columnview :hlines 3 :id local | ITEM | Status| |--+---| | * Report | | |--+---| | ** Uninteresting summary | | |--+---| | ** Details | | |--+---| | *** Release 1| | | Feature #1 | Design| |--+---| | *** Release 2| | | Feature #2 | Confused | | Feature #3 | Completed | | Feature #4 | Coding| |--+---| | *** Release 3| | | Feature #5 | Baffled | #+END: ** Uninteresting summary ** Details *** Release 1 Feature #1 :PROPERTIES: :Status: Design :END: *** Release 2 Feature #2 :PROPERTIES: :Status: Confused :END: Feature #3 :PROPERTIES: :Status: Completed :END: Feature #4 :PROPERTIES: :Status: Coding :END: *** Release 3 Feature #5 :PROPERTIES: :Status: Baffled :END: -- Senior Principal Software Developer Oracle, MySQL Department
Re: [O] babel completion notification
However, there is a problem: --8---cut here---start-8--- #+name: notify #+BEGIN_SRC emacs-lisp :results none (shell-command popup.py DONE) #+END_SRC #+name: long-running #+BEGIN_SRC shell :results output :post notify sleep 5 echo DONE #+END_SRC #+RESULTS: long-running : nil --8---cut here---end---8--- The result seems to be the result of the notify block, not the long-running one. Yes, that's how post blocks are supposed to work, they're normally used to post-process results. You should add a variable to the post block and have it return that variable, e.g., #+name: notify #+begin_src emacs-lisp :var data= (shell-command popup.py DONE) data #+end_src -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Org Agenda and BBDB File
Aric Gregson aorc...@mac.com writes: Hello, I am wondering if it is possible to get org-mode to stop asking to read the bbdb file when creating the new agenda. It is a bit annoying because GNUS in another instance of emacs generally has the file. I have seemingly removed any calls to bbdb in my org set-up (initially used it for anniversaries, but now doesn't appear to work in bbbd v3). I now have no dates that need to be looked at for agenda creation in org mode. If I have '(org-agenda-files (quote (~/org))) and the bbdb file is in this directory, it is then used by org mode to create the agenda? My impression was that only files ending in '.org' in the directory were used. I think your impression is correct, assuming that org-agenda-file-regexp has not been modified: , | org-agenda-file-regexp is a variable defined in `org.el'. | Its value is \\`[^.].*\\.org\\' | | Documentation: | Regular expression to match files for `org-agenda-files'. | If any element in the list in that variable contains a directory instead | of a normal file, all files in that directory that are matched by this | regular expression will be included. ` Nick
Re: [O] [patch][ox-html] Support for level based containers
On 2014-03-17 23:31, Rasmus wrote: It's a variable that you can set in your project or in your Org file or in your init file. I don't see why div × 3 is better than section article div or something else conditional on two variables being explicitly set to get fancy HTML5. . . In any case, I don't have strong—if any—preferences on this. Because using these tags is assigning semantic meaning which may or may not be valid for the current document. Based on the spec, your use of =section= seems ok (but could also be used for the other levels), but your use of =article= is probably wrong in most cases. From http://www.w3.org/html/wg/drafts/html/master/sections.html#the-article-element: The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. As to the =section= element, the from the above doc: The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content. The theme of each section should be identified, typically by including a heading (h1-h6 element) as a child of the section element. and A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline. So, using this definition, in html5, the wrappers should be =sections= to the same level as the toc heading level specified for the document, and =divs= after.[1] org-html-text-markup-alist is nice. What do you want to see in addition to the current structure (in patch v2)? Somehow I never saw the original thread, only the email cc'ing me directly. I went to gmane to find the patch, and obviously grabbed the wrong one. Could you please send me the (new) patch so that i can review it? Here's the Gmane link. I believe it's different than what you reviewed before, but perhaps I'm wrong. . . No, i got the wrong patch from gmane. This one looks better modulo: 1. The default should stay the same as it is now -- the string div 2. Minor typo, but backward comparability should be backwards compatibility. But, after reviewing the spec (see above vis. =section= and =article=), i would submit that a better patch would be to implement [1] above -- remove the defcustom (i only added to support using a different default wrapper element in html5), and use =section= and =div= based on toc level when html5-fancy is true. As far as i can tell from the spec, =article= would almost never be correct for the average org doc. Here's a relevant quote from the spec: Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element. I think the best way to implement this would be letting the user specify it with the =HTML_CONTAINER= property already implemented. As this seems very much in keeping with the spec, i will implement this change when i have some time in the next couple of weeks if i don't hear any strong arguments against. As an aside, the complex semantics of the new html5 tags is why we have been slow in implementing them in ox-html. =div= is by definition a non-semantic tag meant to be used for grouping and styling, but the new tags have very specific meanings associated with them and their mis-use is worse than their non-use. rick
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
Bastien b...@gnu.org writes: Ilya Shlyakhter ilya_...@alum.mit.edu writes: When I open emacs with this file, move to the emacs-lisp block, and evaluate it, I get aaa. I can reproduce your problem now, I'm on it, and the problem is real, but I need to make sure all tests pass fine before fixing this. Okay, so I committed a different fix in maint and master. Please test it and let me know. Thanks, PS: You may want to read the commit message: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=42ee862d -- Bastien
Re: [O] [PATCH] Write org variables into own R environment instead of .GlobalEnv
Hi Rainer, did you sign the FSF papers? We need this before considering applying the patch. Also, the formatting of the Changelog entry is not correct, please carefully read http://orgmode.org/worg/org-contribute.html Thanks, -- Bastien
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Hi Luke,
Luke Crook l...@balooga.com writes:
#+LATEX_HEADER: \newcommand{\orgtitle}TITLE
My understanding is that Org's macros cannot be used
within #+... options.
HTH,
--
Bastien
Re: [O] [PATCH] Only set org-hide foreground if one is available
Hi Nikolai, Nikolai Weibull n...@disu.se writes: (org-mode): When loading Org buffers through desktop I'm not sure what the above means, can you explain it? Also, what is exactly the bug this fixes (beyond setting something that does not need setting)? Thanks, -- Bastien
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
Thanks Bastien. Property API documentation could be made more precise in some places. From the documentation of org-entry-get (both the docstring and the Org manual), it would seem that unless the inherit argument is non-nil, file-wide and system-wide property settings should not be checked at all? The Org manual seems especially clear: By default, this only looks at properties defined locally in the entry. Logically, it makes sense to think of file-wide properties as being on an implicit level 0 headline under which all headlines in the file are grouped, and system-wide properties as being on an implicit level -1 headline under which all level-0 headlines are grouped. But, existing code and Org files might rely on org-entry-get without inheritance considering file-wide and system-wide properties? Documentation of the variable org-use-property-inheritance also can be read to mean that it controls the inheritance of file-wide and system-wide properties, though currently it does not (When nil, only the properties directly given in the current entry count.) For org-entry-properties, it says Get all properties of the entry -- but it returns only properties explicitly defined at the entry, not anything inherited from up the hierarchy or file-wide or system-wide, right? It also says, Keys may occur multiple times if the property key was used several times. -- but the manual also says that a property can only have one entry per Drawer. Also, #+PROPERTY: lines have an effect no matter where they are in the file, but what happens when several of them set the same property isn't fully specified; I assume they're processed top-to-bottom, and later settings overwrite earlier ones, just as later prop+ settings append to earlier ones? (So in this sense it does matter where in the file a #+PROPERTY line is). It might also be useful to clarify that even if a subtree is archived, global property settings in that subtree continue to have an effect (because they aren't really in a subtree). Manual says that #+PROPERTY lines specify properties that can be inherited by any entry in a file; more precise would be that they specify property settings inherited by every entry? Likewise for the variable org-global-properties. On Tue, Mar 18, 2014 at 11:14 AM, Bastien b...@gnu.org wrote: Bastien b...@gnu.org writes: Ilya Shlyakhter ilya_...@alum.mit.edu writes: When I open emacs with this file, move to the emacs-lisp block, and evaluate it, I get aaa. I can reproduce your problem now, I'm on it, and the problem is real, but I need to make sure all tests pass fine before fixing this. Okay, so I committed a different fix in maint and master. Please test it and let me know. Thanks, PS: You may want to read the commit message: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=42ee862d -- Bastien
Re: [O] [PATCH] Fix clock table when there are links in headings.
Hi Alexey, Alexey Lebedeff bina...@gmail.com writes: Sorry, I failed to explicitly mention that it was in agenda clockreport. It was in the screenshot, but I forgot that clocktable is used in other places than agenda. You need to configure `org-agenda-clockreport-parameter-plist' like this: (setq org-agenda-clockreport-parameter-plist '(:link nil :maxlevel 2)) HTH, -- Bastien
Re: [O] [patch] capture property table-line-pos can be a function
Hi Thomas, Thomas Holst thomas_ho...@gmx.de writes: ok here is the patch for documentation. Thanks -- can you read this page? http://orgmode.org/worg/org-contribute.html#sec-5 There are advice on how to format the Changelog entry. See in particular this list: - Variables and functions names are quoted like `this' (backquote and single quote). - Sentences should be separated by two spaces. - Sentences should start with an uppercase letter. - Avoid the passive form: i.e., use change instead of changed. I know it's boring, but even more boring to fix this when we merge Org with Emacs :) Thanks in advance, -- Bastien
Re: [O] `org-attach-file-list' doesn't allow dotfiles
Hi Oleh, Oleh ohwoeo...@gmail.com writes: I would modify it like this to ignore just . and ..: --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -425,7 +425,7 @@ This can be used after files have been added externally. Return a list of files in the attachment directory. This ignores files starting with a \.\, and files ending in \~\. (delq nil - (mapcar (lambda (x) (if (string-match ^\\. x) nil x)) + (mapcar (lambda (x) (if (string-match ^\\.\\.?$ x) nil x)) (directory-files dir nil [^~]\\' I pushed a slightly different change: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=74162d9e Is there a reason behind this dot file restriction? Would anything break if the proposed change was made? I cannot think of any and John seems too busy right now. Let's continue with this change and see if anything breaks. Thanks, -- Bastien
Re: [O] How to use an image as an anchor in HTML export?
On 2014-03-18 11:46, William Denton wrote: I would like to use an image as an anchor in an HTML export (specifically in a reveal.js export---I really like this). I can't figure out how to make it work, and just end up with either a link with a missing image or an image with no link. I don't see this documented. Is it possible? What I want to end up with in the output is something like: a href=foo.htmlimg src=./images/foo.jpg/a #+BEGIN_SRC org ,* Test image link [[http://example.com][file:image1.png]] #+END_SRC which generates (with subtree export): #+BEGIN_SRC html !DOCTYPE html html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en head titleTest image link/title meta charset=utf-8 / meta name=generator content=Org-mode / meta name=author content=Rick Frankel / link rel=stylesheet href=org.css / /head body div id=content h1 class=titleTest image link/h1 div class=figure pa href=http://example.com;img src=image1.png alt=image1.png //a /p /div /div /body /html #+END_SRC
Re: [O] Ye Olde org-with-silent-modifications problem
Pardon me for resurrecting an old thread, but I am sorry to report that I'm experiencing the issue described below today. Since I use eschulte's starter kit for my emacs initialization, it's not easy to start a fresh emacs and install org-mode from ELPA before calling any org-mode functions. Presently I'm going to start emacs -Q and manually set up the package repos and install org-mode. I'm vaguely concerned that it will get installed in the wrong directory or something... Let's see. Cheers, --Dave From: Tom Slee Sent: Friday, July 26, 2013 9:58 AM To: emacs-orgmode@gnu.org Subject: [O] Ye Olde org-with-silent-modifications problem I know that the cause of this message is usually installing org-mode from elpa in a session that has already accessed org files: org-refresh-category-properties: Invalid function: org-with-silent-modifications However, I have tried to reinstall in a clean fashion several times and so far no luck. Any ideas would be appreciated. My setup is on Windows, with this version Org-mode version 8.0.6 (8.0.6-5-gb4a8ec-elpaplus @ c:/Users/Tom/.emacs.d/elpa/org-plus-contrib-20130722/) I wonder if the problem is that my emacs initialization files are org-mode files, based of Eric Schulte's starter kit? I have tried doing an uninstall orgmode, restart, restart, restart, install org-mode to ensure that there are no changes to org-mode init files that would cause them to be re-installed, but I don't see anything there. Tom
Re: [O] Is there an environment for Org syntax?
Sorry, Fletcher, but this is beyond me. If what you want is essentially a
buffer-based screenshot, then it may in theory be easier, relatively speaking,
to build elisp routines to copy the contents of buffers, but that would be even
further beyond my abilities.
Phil
- Original Message -
From: Fletcher Charest fletcher.char...@gmail.com
To: Phil Regier preg...@ittc.ku.edu
Cc: emacs-orgmode@gnu.org
Sent: Monday, March 17, 2014 8:58:18 AM
Subject: Re: [O] Is there an environment for Org syntax?
Hello Phil,
When I use the edit buffer (by pressing C-c '), my Org syntax is indented
properly (in accordance with org-indent-mode, which is set to t). The code
block itself looks like this after editing:
#+BEGIN_SRC org :exports code
,* Top level headline
,** Second level
,*** Third level
some text
,*** Third level
more text
#+END_SRC
As you can see, the text ('some text' and 'more text') is not indented.
This is a little bit annoying, but not too much - I can add the spaces
myself.
The problem is with the HTML export: I can't see the HTML output as I would
see it in my Emacs buffer, that is to say, without the leading stars. In my
output (see attached), leading stars are visible, although not colored. I
would like them to be completely invisible.
Do you observe the same thing? My org-version is 8.2.5h-30-gdd810b-elpaplus
under GNU Emacs 24.3.1.
Thanks,
FC
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Bastien bzg at gnu.org writes:
Hi Luke,
Luke Crook luke at balooga.com writes:
#+LATEX_HEADER: \newcommand{\orgtitle}TITLE
My understanding is that Org's macros cannot be used
within #+... options.
HTH,
Bastien, thanks. That would certainly explain it. I think I will try to
define my own class.
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
Bastien writes: Okay, so I committed a different fix in maint and master. That fix (and the explanation) makes much more sense… I'll have to see that this also gets tested, but I won't get to it for some time, unfortunately. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
[O] plotting a transposed table
I have a table where the data runs left-to-right instead of top-to-bottom. For example: | year | 2014 | 2015 | 2016 | 2017 | 2018 | | value |1 |2 |3 |4 |5 | Gnuplot expects the data to be top-to-bottom, but I want to keep the table in that format. I know that I could write an external script create a transposed copy of the table, but I was wondering if there was an easier way to plot the data. -- Hubert Chathi - Email/Jabber: hub...@uhoreg.ca - http://www.uhoreg.ca/ PGP/GnuPG key: 4096R/113A1368 (Key available at pool.sks-keyservers.net) Fingerprint: F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Re: [O] plotting a transposed table
Aloha hubert, Could you use the transpose function in the Library of Babel? #+name: transpose-example | 1 | 2 | 3 | | 4 | 5 | 6 | #+name: transpose #+begin_src emacs-lisp :var table=transpose-example (apply #'mapcar* #'list table) #+end_src #+results: transpose | 1 | 4 | | 2 | 5 | | 3 | 6 | All the best, Tom hubert hub...@uhoreg.ca writes: I have a table where the data runs left-to-right instead of top-to-bottom. For example: | year | 2014 | 2015 | 2016 | 2017 | 2018 | | value |1 |2 |3 |4 |5 | Gnuplot expects the data to be top-to-bottom, but I want to keep the table in that format. I know that I could write an external script create a transposed copy of the table, but I was wondering if there was an easier way to plot the data. -- Thomas S. Dye http://www.tsdye.com
Re: [O] [PATCH] Only set org-hide foreground if one is available
On Tue, Mar 18, 2014 at 4:27 PM, Bastien b...@gnu.org wrote: Nikolai Weibull n...@disu.se writes: (org-mode): When loading Org buffers through desktop I'm not sure what the above means, can you explain it? Also, what is exactly the bug this fixes (beyond setting something that does not need setting)? Sorry, I realize that I was way too terse. When loading Org buffers from a desktop file (see (desktop-save-mode)) when Emacs starts as a daemon (through, for example, emacsclient --alternate-editor '' -t), org-hide (and I’m guessing other faces as well – I’m not well versed with Emacs’ faces) will apparently not contain any information. My guess is that until a frame has been created (or perhaps displayed), which won’t happen until after the Org buffers have been created and thus Org mode has been initialized and this code called, faces won’t be initialized, perhaps to account for things such as rules relating to background/foreground (such as those defined in (defface org-hide)). Thus it’s not safe to simply assume that (face-foreground 'org-hide) will return a non-nil value, which means that (org-find-invisible-foreground) /can/ return nil. If we set (face-foreground 'org-hide nil) during initialization, for some other reason that I’m similarly unfamiliar with, my themed setting of org-hide (via (load-theme)) won’t be applied (and the default value specified in the defface of org-hide will similarly not be used). As should be painfully obvious from that description, I’m not sure why (face-foreground 'org-hide) is returning nil and I’m not sure why (set-face-foreground 'org-hide nil) prevents the themed setting to be applied. I am, however, sure that this solved the issue of org-hide having an unspecified foreground.
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien writes: Okay, so I committed a different fix in maint and master. That fix (and the explanation) makes much more sense… I'll have to see that this also gets tested, but I won't get to it for some time, unfortunately. I'll first fix the documentation, as Ilya suggested, then it will be easier to design the tests. -- Bastien
Re: [O] [patch] capture property table-line-pos can be a function
Hi Bastien,
· Bastien b...@gnu.org wrote:
Thomas Holst thomas_ho...@gmx.de writes:
ok here is the patch for documentation.
Thanks -- can you read this page?
http://orgmode.org/worg/org-contribute.html#sec-5
There are advice on how to format the Changelog entry.
See in particular this list:
- Variables and functions names are quoted like `this' (backquote and
single quote).
- Sentences should be separated by two spaces.
- Sentences should start with an uppercase letter.
- Avoid the passive form: i.e., use change instead of changed.
I know it's boring, but even more boring to fix this when we merge
Org with Emacs :)
Thanks in advance,
I am sorry, I used =git format-patch= for the patches assuming all will
go well. Here are both patches with rewritten commit messages. Hopefully
I made them well.
--
Bis neulich ...
Thomas
From e5f906f20b796326e50057fa4fc21599368bd347 Mon Sep 17 00:00:00 2001
From: Thomas Holst thomas_ho...@gmx.de
Date: Sat, 15 Mar 2014 16:22:44 +0100
Subject: [PATCH 1/2] capture: property `:table-line-pos' can be a function
name, a string or a variable
org-capture.el: Implement new features for capture templates
* lisp/org-capture.el (org-capture-place-table-line): If the value of
`:table-line-pos' is a function name, its return value is used to
determine the position inside the table. Return value must be a string
like II-3. Else `:table-line-pos' is 'eval'ed.
TINYCHANGE
---
lisp/org-capture.el | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index e7f5e20..cf6c9e2 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1149,6 +1149,9 @@ may have been stored before.
;; Check if the template is good
(if (not (string-match org-table-dataline-regexp txt))
(setq txt | %?Bad template |\n))
+(if (functionp table-line-pos)
+ (setq table-line-pos (funcall table-line-pos))
+ (setq table-line-pos (eval table-line-pos)))
(cond
((and table-line-pos
(string-match \\(I+\\)\\([-+][0-9]\\) table-line-pos))
--
1.7.9.5
From 436e5adb0a9d0bc9ac37352bd90018c973dfdabf Mon Sep 17 00:00:00 2001
From: Thomas Holst thomas_ho...@gmx.de
Date: Mon, 17 Mar 2014 09:01:40 +0100
Subject: [PATCH] docu change for table-line-pos new feature
org.texi: Document new features for capture templates
* doc/org.texi: Document new features of `:table-line-pos' in capture
templates.
---
doc/org.texi |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b53b668..2bebae4 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -7095,9 +7095,10 @@ narrow it so that you only see the new material.
@item :table-line-pos
Specification of the location in the table where the new line should be
-inserted. It should be a string like @code{II-3} meaning that the new
-line should become the third line before the second horizontal separator
-line.
+inserted. It can be a string, a variable holding a string or a function
+returning a string. The string should look like @code{II-3} meaning that
+the new line should become the third line before the second horizontal
+separator line.
@item :kill-buffer
If the target file was not yet visited when capture was invoked, kill the
--
1.7.9
Re: [O] plotting a transposed table
On Tue, 18 Mar 2014 07:44:20 -1000, t...@tsdye.com (Thomas S. Dye) said: [...] #+name: transpose #+begin_src emacs-lisp :var table=transpose-example (apply #'mapcar* #'list table) #+end_src Thanks. That works, except that hlines in the table confuse it, so I modified it as below (using --filter from dash.el). #+name: transpose #+begin_src emacs-lisp :var table=plans (apply #'mapcar* #'list (--filter (not (eq 'hline it)) table)) #+end_src A solution that doesn't require an intermediate table would be ideal, but this is usable. -- Hubert Chathi - Email/Jabber: hub...@uhoreg.ca - http://www.uhoreg.ca/ PGP/GnuPG key: 4096R/113A1368 (Key available at pool.sks-keyservers.net) Fingerprint: F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Re: [O] Org Agenda and BBDB File
Nick Dokos ndo...@gmail.com writes: I think your impression is correct, assuming that org-agenda-file-regexp has not been modified: Thanks Nick. So I am left trying to figure out why org agenda creation keeps pulling in the bbdb file. Aric
Re: [O] [patch][ox-html] Support for level based containers
Rick, Rick Frankel r...@rickster.com writes: On 2014-03-17 23:31, Rasmus wrote: It's a variable that you can set in your project or in your Org file or in your init file. I don't see why div × 3 is better than section article div or something else conditional on two variables being explicitly set to get fancy HTML5. . . In any case, I don't have strong—if any—preferences on this. Because using these tags is assigning semantic meaning which may or may not be valid for the current document. Based on the spec, your use of =section= seems ok (but could also be used for the other levels), but your use of =article= is probably wrong in most cases. From http://www.w3.org/html/wg/drafts/html/master/sections.html#the-article-element: The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. OK. Thanks for your through clarification. As to the =section= element, the from the above doc: The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content. The theme of each section should be identified, typically by including a heading (h1-h6 element) as a child of the section element. This happens with the patch (as is does with divs ATM). and A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline. So, using this definition, in html5, the wrappers should be =sections= to the same level as the toc heading level specified for the document, and =divs= after.[1] So you want it to be section until h:N? That should be easy. org-html-text-markup-alist is nice. What do you want to see in addition to the current structure (in patch v2)? Somehow I never saw the original thread, only the email cc'ing me directly. I went to gmane to find the patch, and obviously grabbed the wrong one. Could you please send me the (new) patch so that i can review it? Here's the Gmane link. I believe it's different than what you reviewed before, but perhaps I'm wrong. . . No, i got the wrong patch from gmane. This one looks better modulo: 1. The default should stay the same as it is now -- the string div As you prefer. 2. Minor typo, but backward comparability should be backwards compatibility. Thanks. But, after reviewing the spec (see above vis. =section= and =article=), i would submit that a better patch would be to implement [1] above -- remove the defcustom (i only added to support using a different default wrapper element in html5), and use =section= and =div= based on toc level when html5-fancy is true. As far as i can tell from the spec, =article= would almost never be correct for the average org doc. Here's a relevant quote from the spec: OK. That certainly makes it easier. But should it not then be a cons or an alist specifying which container to use when the headline level is above or below h:N and deepening on whether html5-fancy is used? Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element. So blogs, technical docs and similar? I can see people using Org such things? Or do W3-people thinkg of something different when they say it is syndicatable I think the best way to implement this would be letting the user specify it with the =HTML_CONTAINER= property already implemented. As this seems very much in keeping with the spec, i will implement this change when i have some time in the next couple of weeks if i don't hear any strong arguments against. I can change my patch to this behavior if you want. Though I think it's pretty strong to hardcode values, as one would might have reasons to change it in say an ox-publish project. As an aside, the complex semantics of the new html5 tags is why we have been slow in implementing them in ox-html. =div= is by definition a non-semantic tag meant to be used for grouping and styling, but the new tags have very specific meanings associated with them and their mis-use is worse than their non-use. Good point. Thanks again Rick. —Rasmus -- Governments should be afraid of their people
Re: [O] [patch][ox-html] Stylistic changes
Rick Frankel r...@rickster.com writes: On 2014-03-17 23:36, Rasmus wrote: When you refer above to utf-8 entities, do you mean the named html entities (e.g., lt;) or the actual utf-8 encoded characters? The latter. Do M-x describe-char on such an character. Emacs will tell you the code points. My conjecture is therefore that one could write a script that would translate html values to these weird hex string or codepoints. It would create more ugly source output, but perhaps better for XHTML. Personally, I don't care about XHTML as I have little intuition as to when to use. . . I believe the named entities are encoding independent, while including encoded characters in html output is fine -- although making sure the page is served with the correct character encoding is another issue entirely. Not what I meant. I'm only addressing your concern about HUMAN-READABLE-NAME; vs %HEX-VALUE;. As to using a more extensive set of named entities, as i said above, the problem is that the xhtml flavors don't support them, and I don't see any advantage in making the exporter handle character encoding differently based on ouput doctype. Definitely not. Why I ask if there's a point in changing nice entities to ugly entities for the sake of not getting them in XHTML-encoded documents. As Nicolas would point out, you can always use a filter to map all the entities in the output. With ox-latex.el we for instance don't include entities that are not supported by the default package alist. A similar concern could be at play here. –Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
I tried creating a custom class and then tried creating a custom style. But
I found the easiest to be the following;
#+AUTHOR: author
#+LATEX_HEADER: \newcommand{\orgauthor}{author}
#+EMAIL: email
#+LATEX_HEADER: \newcommand{\orgemail}{email}
#+TITLE: Title
#+LATEX_HEADER: \newcommand{\orgtitle}{Title}
#+DATE: Date
#+LATEX_HEADER: \newcommand{\orgdate}{Date}
Then in my custom Latex title page;
#+LATEX_HEADER: \input{template}
I use \orgauthor{} etc. for the relevant fields.
Works very well, apart from the duplication of author, email, date etc.
It would be great if org-mode added support for substitution to the #+
fields.
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Luke Crook l...@balooga.com writes: It would be great if org-mode added support for substitution to the #+ fields. Nicolas, what do you think? -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
Hi Samuel, Samuel Wales samolog...@gmail.com writes: as far as i know, my assessment below is correct, but i cannot confirm. I revisited this thread. i believe that if undo-related code is ripped out of babel, then undo will work correctly in the source buffer and in the edit buffer. i am not clear on what the purpose of changing undo behavior is? Time flies: maybe it was clear before, but for now undo works fine for me, in the source editing buffer and in the original buffer too. When I do C-c ' from the *Org Src* buffer, then C-/, the buffer is restored to its previous state, that is: before the insertion of the edited source. Can you restate what the bug is? Thanks, -- Bastien
Re: [O] Write org variables into own R environment instead of .GlobalEnv
Hi Rainer, Rainer M Krug rai...@krugs.de writes: Hi I just send a patch which changes the behaviour of how org variables are treated in R. At the moment, org variables are simply stored in the .GlobalEnv which means, that all show up in the variable listing (which can get cluttered when having many variables), they can accidentaly be deleted and not be restored from within R and saving all the variables into from R to make them available after tangling is not that easy. Therefore the patch writes the variables into their own environment (which I simply called org) and locks the environment and the bindings. This means, that the actual variable values are always in the environment and can not be accidentally deleted. As the environment is attached to the search path, they are accessible as before, but they do not clutter the workspace and do not show up separately e=when using ls() to list the contents of the workspace. When using ls(org) all can be seen. They can still be overwritten, but but this only creates a new variable of the ame name in the .GlobalEnv which is simply hidint the original variable passed from org. The original variable can be accessed via org$VARIABLENAME. When removing the defined variable VARIABLENAME via rm(VARIABLENAME), the value passed from org is back. In addition, all variables can be easily be saved to disk by using save(org, file=/PATH/TO/FILE.Rdata) and reloaded with (load(/PATH/TO/FILE.Rdata)). This mechanism could actually be included into tangling as the default mechanism to load the variables to avoid cluttering the code with all the assignment commands of the org variables. The patch is not yet extensively tested. Please provide some feedback about the idea and implementation, Currently I lack the time to test the patch. So, this is just a (not-so-helpful) feedback on the idea: Seems to be very good! Regards, Andreas
Re: [O] Incorrect hexification in URLs in LaTeX Export
On Mar 18, 2014, at 11:41, Bastien b...@gnu.org wrote: Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: The second link is not clickable in the resulting pdf. This should be fixed now, thanks. Hi Bastien, I just tried with 35f27a1fe and my issue is fixed. (The one about the hexifying of a valid character. I.e., if (fundamental-mode) shows a valid link, the resulting export is also valid) Can't comment on Andreas's issue about unescaping text when it's given to org already escaped. Thanks, Michael
[O] Converting to a useful table in org-mode?
I have this list of books that I've read on my kindle which I now want to store for posterity in org-mode. 24-11-13 - Andrew Lane - young sherlock Holmes, fire storm 3-12-13 - Richmal Compton - just Williams New years day 9-12-13 - richmal compton - still william 11-1-14 - Pc wren - beau geste 18-1-14 - Andrew Lane - young sherlock Holmes, the red leech 26-1-14 - Ian Fleming - casino royale 24-02-14 - Cory doctorow - little brother How can I create a table of them please? I've tried highlighting them and then converting the region, but with a bit of elbow-grease and deletions I get this - | 24-11-13 | Andrew Lane | young sherlock Holmes, fire storm | | 3-12-13 | Richmal Compton | justWilliams New years day | | 9-12-13 | richmal compton | still william | | 11-1-14 | Pc wren | beaugeste | | 18-1-14 | Andrew Lane | young sherlock Holmes, theredleech | | 26-1-14 | Ian Fleming | casino royale | | 24-02-14 | Cory doctorow | little brother | which looks stilted and unnatural! How can I close the gaps in the cells please and get it all left-aligned? I've tried tabbing in the cell and that didn't work, and neither did 'C-c C-c'. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots Debian testing, Fluxbox 1.3.5, emacs 24.3.1 Registered Linux user 561944 signature.asc Description: PGP signature
Re: [O] Howto: different faces for begin_src and results
Just curious, what do you find unpleasant about the default coloring? At first I didn't like the grey, but after time I came to value it because I don't want the code to really jump out, instead just be reference-able since C:c ' brings up the editor with full highlighting. Really, I'm just curious, because I always want to find new ways to work with literate docs. On Mon, Mar 10, 2014 at 5:49 AM, Miguel Ruiz rbeni...@inbox.com wrote: Hi I was wondering if it's possible to have different faces for #+begin_src/#+end_src and results so distinguishing the blocks is easier. TIA. Protect your computer files with professional cloud backup. Get PCRx Backup and upload unlimited files automatically. Learn more at http://backup.pcrx.com/mail -- Grant Rettke | ACM, AMA, COG, IEEE g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] Strange newline characters in org-export-as-html
Hi Bastien, My config is definitely to blame. With my config newlines are output as: Even on 8.2.5h. On Thu, Mar 13, 2014 at 3:15 AM, Bastien b...@gnu.org wrote: Hi Grant, I just tested the minimal example with Org 8.2.5h and fci-mode activated but didn't notice anything strange. Do you still have the problem with Org 8.2.5h? If so, can you give the full Org version by hitting M-x org-version RET ? Thanks, -- Bastien -- Grant Rettke | ACM, AMA, COG, IEEE g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] Converting to a useful table in org-mode?
On Mar 18, 2014, at 20:39, Sharon Kimble boudic...@talktalk.net wrote: I have this list of books that I've read on my kindle which I now want to store for posterity in org-mode. (OT thus sounds more like tasks/checklists to me) 24-11-13 - Andrew Lane - young sherlock Holmes, fire storm 3-12-13 - Richmal Compton - just Williams New years day 9-12-13 - richmal compton - still william 11-1-14 - Pc wren - beau geste 18-1-14 - Andrew Lane - young sherlock Holmes, the red leech 26-1-14 - Ian Fleming - casino royale 24-02-14 - Cory doctorow - little brother How can I create a table of them please? I've tried highlighting them and then converting the region, but with a bit of elbow-grease and deletions I get this - | 24-11-13 | Andrew Lane | young sherlock Holmes, fire storm | | 3-12-13 | Richmal Compton | justWilliams New years day | | 9-12-13 | richmal compton | still william | | 11-1-14 | Pc wren | beaugeste | | 18-1-14 | Andrew Lane | young sherlock Holmes, thered leech | | 26-1-14 | Ian Fleming | casino royale | | 24-02-14 | Cory doctorow | little brother | That looks like a table -- assuming the leftmost pipe is the first character in each row, org should recognize it as a table. For me, the most obvious sign involves turning it purple but I'm not sure if that's set by my color theme or not. If it's a table, just put point anywhere inside it and hit TAB and it should auto align (left justified by default) If that's not working, please send a copy of the file in question and details of your setup, including but not limited to the output of `M-x org-version` and everything in your .emacs with an org in it. Hope that helps, Michael which looks stilted and unnatural! How can I close the gaps in the cells please and get it all left-aligned? I've tried tabbing in the cell and that didn't work, and neither did 'C-c C-c'. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots Debian testing, Fluxbox 1.3.5, emacs 24.3.1 Registered Linux user 561944
Re: [O] babel completion notification
The other options are prettier and the hook is more flexible; I had only cared about tangling though so I set this: (defadvice org-babel-tangle (before org-babel-tangle-before activate) (message (concat org-babel-tangle BEFORE: (format-time-string %Y-%m-%dT%T%z) ))) (defadvice org-babel-tangle (after org-babel-tangle-after activate) (message (concat org-babel-tangle AFTER: (format-time-string %Y-%m-%dT%T%z) ))) For some reason couldn't get around advice working here, it was just never run. On Tue, Mar 18, 2014 at 9:32 AM, Eric Schulte schulte.e...@gmail.comwrote: However, there is a problem: --8---cut here---start-8--- #+name: notify #+BEGIN_SRC emacs-lisp :results none (shell-command popup.py DONE) #+END_SRC #+name: long-running #+BEGIN_SRC shell :results output :post notify sleep 5 echo DONE #+END_SRC #+RESULTS: long-running : nil --8---cut here---end---8--- The result seems to be the result of the notify block, not the long-running one. Yes, that's how post blocks are supposed to work, they're normally used to post-process results. You should add a variable to the post block and have it return that variable, e.g., #+name: notify #+begin_src emacs-lisp :var data= (shell-command popup.py DONE) data #+end_src -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D -- Grant Rettke | ACM, AMA, COG, IEEE g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
[O] Navigating from agenda causes incorrect expansion of children
Not sure if this is a feature or a bug, but those on #org-mode prompted me to post it. GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) Org version 8.2.5c If you take the following minimal example of an org file: * A ** B *** TODO C *** D *** E And navigate to TODO C from an agenda buffer this will be the *displayed* text: * A ** B *** TODO C *** D... Leaving it to appear that D has children, when it in fact has a sibling that's been hidden. Is this some type of custom variable I'm missing, or is this working as intended - or is this truly a bug? May be worth mentioning, myself and others in #org-mode have noticed this happening in other contexts, however this was the only reproducible method. - dan lamanna
Re: [O] Converting to a useful table in org-mode?
Sharon Kimble boudic...@talktalk.net writes: I have this list of books that I've read on my kindle which I now want to store for posterity in org-mode. 24-11-13 - Andrew Lane - young sherlock Holmes, fire storm 3-12-13 - Richmal Compton - just Williams New years day 9-12-13 - richmal compton - still william 11-1-14 - Pc wren - beau geste 18-1-14 - Andrew Lane - young sherlock Holmes, the red leech 26-1-14 - Ian Fleming - casino royale 24-02-14 - Cory doctorow - little brother How can I create a table of them please? Mark the region and then do C-u C-u C-u M-x org-table-convert-region RET When it prompts you for a separator regexp, type ' - ' (without the quotes, but include the spaces). -- Nick
[O] A JavaScript Org-mode parser I'm experimenting with
Hi, people. Just want to share that, for the last few days, I'm playing with a JavaScript Org-mode parser written by Masafumi Oyamada, found here: https://github.com/mooz/org-js To my eyes at least, it is very speedy, and fairly clean internally (contrasting with other JavaScript Org parsers I've seen). It does a reasonable job for a particular set of practical cases I currently have. I found a few bugs which I reported today, and I hope, should not last for long. We'll see! :-) Might someone, familiar enough with the Org mode Web site, add a pointer for it in the http://orgmode.org/worg/org-tools/index.html page? François
