[O] calendar date adjustments blocked
I needed to enter information for two dates in org-mode and went into calendar using c-c+! and got the current date as expected then hit c-b to move the date to yesterday and pointer remained on today's date. So I ended up hitting cr on today's date and editing it in the actual org file and filling the rest of my entry in after it. Then I repeated the operation for today and entered today's information. I was a bit surprised that the date was locked like that once calendar mode was entered but managed a workaround anyway. Jude jdash...@shellworld.net When people ask do you believe in Numerology, the proper reply for me at least is do you believe in a hammer? The proper answer for me for both questions is no, they're both tools and to be used under appropriate circumstances.
[O] A quick way to empty contents of entries?
Hi, all I want to empty all my contents but leave only with the headlines and the properties, is there a fast way? Cheers, gylns
[O] [OT] FSF, GPL, cedit case (was: custom IDs not exported)
On Thu, Nov 03 2011, Nick Dokos wrote: Jambunathan K kjambunat...@gmail.com wrote: [...] [Context Switch] An interesting read (Euphemism for *totally* OT) http://news.ycombinator.com/item?id=2820986 Also google - Emacs violates GPL. Is this the cedet/semantic parser flap-a-doodle? Yes. LWN covered it some time ago. AFAIK, it has been resolved. Yes. http://article.gmane.org/gmane.emacs.announce/25 Note that it is not accurate to write that Emacs violates the GPL. The FSF didn't violate it, but Anyone redistributing those versions is violating the GPL, through no fault of his own. (see http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01155.html) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
Re: [O] A quick way to empty contents of entries?
On Nov 4, 2011, at 7:56 AM, gylns wrote: Hi, all I want to empty all my contents but leave only with the headlines and the properties, is there a fast way? Make backup copies before you try this For one file: perl -ne 'print if /^\*+ / or /^\s*:PROPERTIES:\s*$/../^\s*:END:\s*$/' old.org stripped.org For a bunch of files, with .bak backup copies perl -ni.bak -e 'print if /^\*+ / or /^\s*:PROPERTIES:\s*$/../^\s*:END:\s*$/' *.org HTH - Carsten
Re: [O] Video showing Jambunathan's ODT exporter
Hi, This is some seriously cool functionality for Org that deserves wider exposure. Jambunathan's done a great job. Yep I tried it a few days ago and the results were nearly perfect. It's obviously not for everyone; I'm sure some Org users have no need for documents in a word processor and steer as far away as possible. Others may love it, though, and it could potentially bring more users to Org community. Well it becomes particular important if it comes to collaboration with MS-Office people. I can write my stuff in org and make a LaTeX export for the final submission, however, I can send co-authors ODT (and by resaving doc) formats to allow them to make changes and comments to the manuscript. I've seen comments about an ODT import that I haven't had a chance to look into yet. Well this is the exact point which is missing now. For now, I open the resubmitted modified ODT version on my PC and make all changes accordingly in my org-file. Thanks to a dual screen set-up it is rather ok. However, still very error prone. Having the possibility to re-import the ODT-file into org and make a kind of diff which I simply step through and either agree or disagree would be perfect. Emacs already has diff functionallity. What would be needed is a way to re-import the ODT-file in a as much as possible exact way like it was originally. The ODF format is open and I wonder whether there is some kind of metadata tag, which could be used to save the org-mode stuff directly beside the odt text stuff... this would allow to restore the org-mode file rather efficiently. Pseudo code: metadata *** DONE This is a subsubsub-header :COAUTHOR: \metadata Cheers, Herb
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte schulte.e...@gmail.com wrote: One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. This suggestion would get my vote. Cheers, Rainer Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. I also wouldn't think of this as new syntax, I don't see 8 rules for the 8 types above but rather one rule along the lines of #+begin_SOMETHING where the SOMETHING can be anything. Best -- Eric My idea was to avoid parsing both #+html and #+begin_html. And that #+begin_xxx syntax is already available for folding, which is a feature we might want for #+text and
Re: [O] custom IDs not exported
On Thu, Nov 03, 2011 at 02:18:09PM -0400, Nick Dokos wrote: Jambunathan K kjambunat...@gmail.com wrote: Oh, I thought I had run out on my quota: I do have a patch that I can send in, I just don't want to cause headaches (particularly to you) down the line. I'll add a Changelog, mark it as a TINYCHANGE and send it in - is that OK? AFAIK, there is fair amount of audit of ChangeLogs that is done when anything - that includes Org - goes in to Emacs proper. Also considering FSF gives primacy to copyright assignment disclaimer in *paper format* and the mere existence of support machinery around it - a copyright clerk etc etc - one needs to take good amount of care to make sure that the *sum total* (it is sum total right?) of TINYCHANGES don't add up to no more than palmful. That's what I vaguely remembered, and that's why I thought my quota has run out. I think I will *not* be sending the patch after all. Sten, are you up to doing the work? Yes, I'll look into it over the weekend. Unfortunately, I know next to nothing about Lisp, so I might need some help getting this done. But with your previous explanations it should be doable. best regards, Sten -- Sten Lindner e-mail: s.lind...@stenlindner.de
Re: [O] A quick way to empty contents of entries?
Carsten Dominik carsten.dominik at gmail.com writes: For one file: perl -ne 'print if /^\*+ / or /^\s*:PROPERTIES:\s*$/../^\s*:END:\s*$/' old.org stripped.org Thanks Carsten, It works!
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric: Thanks - but for the moment I will go with Jambunathan's suggestion and stick with the latest version before the removal of BABEL. For the record, I created a local branch before the removal of BABEL and used git checkout MyBranch to switch to this branch. So I can keep my local git repo up-to-date and switch back to master if I want to. Cheers, Rainer On Thu, Nov 3, 2011 at 7:51 PM, Jambunathan K kjambunat...@gmail.comwrote: Rainer - if he feels uncomfortable - can choose *not* to update his git repo and switch his local checkout to a historical version. [1] to see the info page evaluate (info (elisp)File Local Variables) A usage note for adding these variables without straining the brain. M-x add-file-local-variable RET M-x add-file-local-variable-prop-line RET These commands are documented here. (info (emacs) Specifying File Variables) -- -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
[O] agenda secondary filtering by category
Hi all, I love the fast way of secondary filtering by tag. I already have several custom agenda views sorted by category. Having lots of org files the display of the result of a custom agenda view is slow on my machines. I would therefore love to have the possibility of secondary filtering by category. What do others think? Best, Rainer
Re: [O] agenda secondary filtering by category
Hi Rainer, This is a frequent request, and a very reasonable one. I have a patch for this, I just need to polish it a bit. I will commit it over the week-end. Thanks, -- Bastien
[O] OT: syncing computers with git (was: Best way to set up Org mode with MobileOrg over Dropbox)
* Gregor Kappler g.kapp...@gmx.net wrote: I am using git to sync several laptops and Desktop computers. Every 5 minutes a cronjob runs a shell script that automatically runs =git pull= -- and =git add= on org files as well files listed in the =.gitcroncommit= file. The commit message is comprised of the filenames of all changed files as well as a prefix for detection in git logs (cron autocommit, parameterized) and the hostname. The auto commit is performed only if - no files have been staged manually. - git is in the auto branch (where mine is always). This prevents cluttering the git history of the master branch. If you want to switch from a pulling to an interrupt system, you might be interested in http://www.mayrhofer.eu.org/dvcs-autosync -- Karl Voit Hallo, mein Name ist Web 2.0. Gib mir dein Adressbuch und lass mich Emails lesen
Re: [O] agenda secondary filtering by category
Hi Bastien, excellent! Thanks a lot. This will speed up working in the agenda! Rainer Am 04.11.2011 13:34, schrieb Bastien: Hi Rainer, This is a frequent request, and a very reasonable one. I have a patch for this, I just need to polish it a bit. I will commit it over the week-end. Thanks,
Re: [O] New version of VimOrganizer, an Org-mode clone in Vim
On Thu, Nov 3, 2011 at 7:26 PM, Herbert Sitz hes...@gmail.com wrote: Michael Brand michael.ch.brand at gmail.com writes: or at a similar place that there is also the possibility to have the vi modal editing paradigm and most of the vi key bindings within Emacs itself by using a vi emulation like Viper mode. (I use Emacs with Viper mode all the time to have the best of both worlds.) Michael Michael -- No problem, this issue was of course brought up when I started the project a year or so ago. Actually for the many Vim users who have tried to make the transition to Emacs I think it is pretty well known that there are several different Vim emulators for Emacs. (Evil is a fairly new one I still want to try out; I'm not sure but I think it's by same team and intended to supplant Vimpulse, which itself extends Viper: http://gitorious.org/evil ) Evil is very nice. I like it a lot and could never get used to Vimpulse. It is intended to replace Viper/Vimpulse. I second your idea of better org integration. See here for a start of a customization: http://zuttobenkyou.wordpress.com/tag/orgmode/ Anyway, I'm looking forward to trying VimOrganizer.
Re: [O] custom IDs not exported
Sten Lindner s.lind...@stenlindner.de wrote: On Thu, Nov 03, 2011 at 02:18:09PM -0400, Nick Dokos wrote: Jambunathan K kjambunat...@gmail.com wrote: Oh, I thought I had run out on my quota: I do have a patch that I can send in, I just don't want to cause headaches (particularly to you) down the line. I'll add a Changelog, mark it as a TINYCHANGE and send it in - is that OK? AFAIK, there is fair amount of audit of ChangeLogs that is done when anything - that includes Org - goes in to Emacs proper. Also considering FSF gives primacy to copyright assignment disclaimer in *paper format* and the mere existence of support machinery around it - a copyright clerk etc etc - one needs to take good amount of care to make sure that the *sum total* (it is sum total right?) of TINYCHANGES don't add up to no more than palmful. That's what I vaguely remembered, and that's why I thought my quota has run out. I think I will *not* be sending the patch after all. Sten, are you up to doing the work? Yes, I'll look into it over the weekend. Unfortunately, I know next to nothing about Lisp, so I might need some help getting this done. But with your previous explanations it should be doable. OK, that's great: feel free to query the list (or contact me off list, if you prefer) for any questions. And I'd be happy to review the patch before you submit it. Thanks, Nick
Re: [O] Video showing Jambunathan's ODT exporter
Torsten Wagner torsten.wagner at gmail.com writes: It's obviously not for everyone; I'm sure some Org users have no need for documents in a word processor and steer as far away as possible. Others may love it, though, and it could potentially bring more users to Org community. Well it becomes particular important if it comes to collaboration with MS-Office people. I can write my stuff in org and make a LaTeX export for the final submission, however, I can send co-authors ODT (and by resaving doc) formats to allow them to make changes and comments to the manuscript. Great point. On related note, did you see the tweak Jambunathan added a week or so ago to translate note blocks in Org into author-attributed comment bubbles in Word/LibreOffice: http://article.gmane.org/gmane.emacs.orgmode/48585 Another benefit I just thought about with to exporting to ODT is the power it gives users to modify document formats. LaTeX is amazing, but it's not something where the average user is going to be able to tweak the output very easily. Word/LibreOffice, on the other hand, allow the average user to tweak formatting fairly easily, either after export by changing styles directly in the document, or (I assume) before export by changing the styles that are used by Jambunathan's exporter. Though I must say the formatting he's using right now seems very good. I particularly like the way section headings have slightly more whitespace above than they do below, makes for nice connection of headings to their text, which if I recall is a touch that's not done as nicely in many LaTeX classes. Having the possibility to re-import the ODT-file into org and make a kind of diff which I simply step through and either agree or disagree would be perfect. Emacs already has diff functionallity. What would be needed is a way to re-import the ODT-file in a as much as possible exact way like it was originally. The ODF format is open and I wonder whether there is some kind of metadata tag, which could be used to save the org-mode stuff directly beside the odt text stuff... this would allow to restore the org-mode file rather efficiently. That could be sort of a holy grail type of workflow, seamless export out and import back in from MS Word. I know Org's exports to other formats are also amazing, but the export to MS Word seems somehow more magic. I think it's because I'm a relative old-time and still think of Word as being monstrosity from the days of proprietary binary formats. Now with ODT support it's (almost) like making it part of the plain-text crowd. Regards, Herb
Re: [O] [bug] Org link dialog escapes URL spaces incorrectly
I just pulled the latest org-mode. The problem persists for me, even though it was reported as fixed in a previous thread. Can anyone replicate with the latest org? Org-mode version 7.7 (release_7.7.513.g2a5877) GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev On Tue, Nov 1, 2011 at 22:02, Jeff Horn jrhorn...@gmail.com wrote: Org-mode version 7.7 (release_7.7.404.ga17c.dirty) GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev Inserting a link through the link dialog doesn't escape URLs with spaces properly. Where a space is '%20', org will insert the link as '%2520'. I'm not certain of URL escape codes, but could org be trying to escape the % sign? Perhaps a missing slash in a regexp somewhere? 1) Use =C-c C-l= to use dialog. Paste a link, like the following. http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf 2) Use =C-c C-o= to open the link. Be weirded out about a 404. Inspect URL. ,[ Actual ] | - [ ] [[http://www.dartmouth.edu/~dirwin/Did%2520France%2520Cause%2520the%2520Great%2520Depression.pdf][Link Description]] ` ,[ Expected ] | - [ ] [[http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf][Link Description]] ` -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ -- Jeffrey Horn http://www.failuretorefrain.com/jeff/
Re: [O] [bug] Org link dialog escapes URL spaces incorrectly
Jeff Horn jrhorn...@gmail.com wrote: I just pulled the latest org-mode. The problem persists for me, even though it was reported as fixed in a previous thread. Can anyone replicate with the latest org? Org-mode version 7.7 (release_7.7.513.g2a5877) GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev On Tue, Nov 1, 2011 at 22:02, Jeff Horn jrhorn...@gmail.com wrote: Org-mode version 7.7 (release_7.7.404.ga17c.dirty) GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev Inserting a link through the link dialog doesn't escape URLs with spaces properly. Where a space is '%20', org will insert the link as '%2520'. I'm not certain of URL escape codes, but could org be trying to escape the % sign? Perhaps a missing slash in a regexp somewhere? 1) Use =C-c C-l= to use dialog. Paste a link, like the following. http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf 2) Use =C-c C-o= to open the link. Be weirded out about a 404. Inspect URL. ,[ Actual ] | - [ ] [[http://www.dartmouth.edu/~dirwin/Did%2520France%2520Cause%2520the%2520Great%2520Depression.pdf][Link Description]] ` ,[ Expected ] | - [ ] [[http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf][Link Description]] ` The problem is in org-insert-link: in one case, when we edit the link at point, the link is unescaped: , | ... | ((org-in-regexp org-bracket-link-regexp 1) | ;; We do have a link at point, and we are going to edit it. | (setq remove (list (match-beginning 0) (match-end 0))) | (setq desc (if (match-end 3) (org-match-string-no-properties 3))) | (setq link (read-string Link: | (org-link-unescape | (org-match-string-no-properties 1) ` but in the other case, when we just paste the link into the minibuffer, it is not - check from the (unwind-protect ... ) on line 9088 of org.el and ff to the end of the function: the link that's read from the minibuffer is passed untouched (well, at least unescaped) to org-make-link-string on the very last line of the function and apparently the latter reescapes everything: try replacing the call (org-make-link-string link desc) on the last line of org-insert-link with (org-make-link-string (org-link-unescape link) desc) I think that'll fix it. Nick
Re: [O] Pass LaTeX exporter option prior to \documentclass
John Hendy jw.he...@gmail.com wrote:
On Thu, Nov 3, 2011 at 12:55 PM, suvayu ali fatkasuvayu+li...@gmail.com
wrote:
On Thu, Nov 3, 2011 at 18:48, John Hendy jw.he...@gmail.com wrote:
On Wed, Nov 2, 2011 at 5:30 AM, suvayu ali fatkasuvayu+li...@gmail.com
wrote:
On Wed, Nov 2, 2011 at 03:43, suvayu ali fatkasuvayu+li...@gmail.com
wrote:
You could try replacing that with the following:
pdflatex -interaction nonstopmode -output-directory %o
\pdfminorversion=4 $(cat %f)
I did some testing. The following should work.
pdflatex -interaction nonstopmode -output-directory %o
\\pdfminorversion=4 \\input{%f}
Thanks for the workaround! So, to be clear, I'd type in what you wrote
when I'm prompted for the command to use after =C-c C-e p=?
No. I don't think org prompts for the command when exporting. You
should use customize to set the variable org-latex-to-pdf-process to
the above command.
Ah, sorry. You're right. I was thinking of =C-c C-c= from the .tex file
buffer.
Thanks again! It was a fringe scenario for sure!
Alternatively, you can define a new entry in org-export-latex-classes
that does what you want - I just cribbed the existing beamer entry and
modified it a bit (I had called it beamerpdf14 at first, but apparently
numerics are not allowed):
,
| (require 'org-latex)
| (setq beamerpdf '(beamerpdf \\pdfminorversion=4\\documentclass{beamer}
org-beamer-sectioning))
| (add-to-list 'org-export-latex-classes beamerpdf t)
`
and then set
#+LATEX_CLASS: beamerpdf
in your org file.
Nick
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
I liked this suggestion. In a sense, it is similar to the inherit keyword I had suggested before, but now the keyword (the plus sign) is part of the variable name. But the reason I really liked it is because it is clear to understand. One can compare it to the += operator some languages have. That is, we can understand `:var: bar=2` as var=bar=2 and `:var+: bar=2` as var+=bar=2.` -- Darlan At Fri, 4 Nov 2011 09:02:43 +0100, Rainer M Krug r.m.k...@gmail.com wrote: On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte schulte.e...@gmail.com wrote: One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. This suggestion would get my vote. Cheers, Rainer Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse
Re: [O] [bug] Org link dialog escapes URL spaces incorrectly
Brian Wightman midlife...@wightmanfam.org wrote: On Fri, Nov 4, 2011 at 11:52 AM, Nick Dokos nicholas.do...@hp.com wrote: probably not a problem, since unescaping should be idempotent (in contrast to escaping ;-) ) but why do it twice? I am not sure I am reading this correctly - I am reading this as unescaping a url-encoded twice should give the same results as unescaping the same url-encoded string once. If that is what you are saying, I would disagree. Taking a string similar to the one provided originally: Did%2520France%2520Cause%2520the%2520Great%2520Depression.pdf would be unescaped as Did%20France%20Cause%20the%20Great%20Depression.pdf and a second unescape would generate Did France Cause the Great Depression.pdf Hopefully, I am just reading your statement wrong :-) Nope - you read it right and it (the statement, not the reading) is wrong. But I'm not sure what the implications to the code are: do we have to unescape repeatedly until there are no more % signs in there? Then the final call to org-make-link-string would do one escaping pass and that would be that? My URL fu is weak. Any help would be appreciated. Thanks, Nick
Re: [O] [bug] Org link dialog escapes URL spaces incorrectly
Nick Dokos nicholas.do...@hp.com wrote: It probably does, but that's probably not the best place to do it: it might be better to do it in the (setq link on line 9090 or thereabouts. Otherwise, in the *other* case (editing the link at point), we'll end up unescaping twice: probably not a problem, since unescaping should be idempotent (in contrast to escaping ;-) ) but why do it twice? Brian Wightman pointed out to me that the idempotent part of the statement above is definitely wrong (d'oh). The original URL that Jeff Horn posted, when unescaped once, would be completely free of % signs. But if the second (doubly-escaped) form is pasted into the minibuffer, then unescaping once would not be enough. So I presume the thing to do is to take the URL and unescape it repeatedly until it loses all escapes, and then escape it *once* before inserting it in the org buffer. Sounds icky, kludgy, dirty. The question is: 1) is it a solution? and 2) is there a better one? Nick
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Darlan Cavalcante Moreira darc...@gmail.com writes: I liked this suggestion. In a sense, it is similar to the inherit keyword I had suggested before, but now the keyword (the plus sign) is part of the variable name. Oh yes, I didn't realize that when I first posted this suggestion but it is very similar to your suggested inherit keyword, But the reason I really liked it is because it is clear to understand. One can compare it to the += operator some languages have. That is, we can understand `:var: bar=2` as var=bar=2 and `:var+: bar=2` as var+=bar=2.` Agreed, it was the limitation of possible values which I didn't like about your inherit suggestion, but this approach switches the limitation to the property name rather than the property value which is somehow more appealing. Cheers -- Eric -- Darlan At Fri, 4 Nov 2011 09:02:43 +0100, Rainer M Krug r.m.k...@gmail.com wrote: On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte schulte.e...@gmail.com wrote: One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. This suggestion would get my vote. Cheers, Rainer Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost
Re: [O] Pass LaTeX exporter option prior to \documentclass
Hi John,
On Fri, Nov 4, 2011 at 18:29, Nick Dokos nicholas.do...@hp.com wrote:
Alternatively, you can define a new entry in org-export-latex-classes
that does what you want - I just cribbed the existing beamer entry and
modified it a bit (I had called it beamerpdf14 at first, but apparently
numerics are not allowed):
,
| (require 'org-latex)
| (setq beamerpdf '(beamerpdf \\pdfminorversion=4\\documentclass{beamer}
org-beamer-sectioning))
| (add-to-list 'org-export-latex-classes beamerpdf t)
`
and then set
#+LATEX_CLASS: beamerpdf
in your org file.
For the record, I would say Nick's solution is a more flexible setup.
--
Suvayu
Open source is the future. It sets us free.
[O] Bug: org-export-as-latex fails [7.7]
Your bug report will be posted to the Org-mode mailing list.
running org-export-as-latex on the following file works in org v7.5
and fails in org v7.7 (not sure about v7.6) with the error:
org-export-latex-preprocess: Wrong type argument: stringp, nil
cut here ===
* Test
#+begin_src perl
$a=[0];
#+end_src
end file ===
Emacs : GNU Emacs 23.3.6 (sparc-sun-solaris2.10, GTK+ Version 2.8.20)
of 2011-06-13 on localhost
Package: Org-mode version 7.7
current state:
==
(setq
org-export-latex-default-class my-class
org-export-with-LaTeX-fragments nil
org-emphasis-alist '((* bold b /b) (/ italic i /i)
(_ underline span
style=\text-decoration:underline;\
/span)
(` org-code code /code)
(= org-code code /code verbatim)
(~ org-verbatim code /code verbatim)
(+ (:strike-through t) del /del))
org-export-latex-after-initial-vars-hook
'(org-beamer-after-initial-vars)
org-export-latex-listings 'minted
org-startup-align-all-tables t
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-src-fontify-natively t
org-export-latex-tables-centered nil
org-babel-load-languages '((perl . t) (dot . t) (mscgen . t) (sh . t)
(emacs-lisp . t))
org-hide-leading-stars t
org-export-html-validation-link
org-metaup-hook '(org-babel-load-in-session-maybe)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-babel-tangle-lang-exts '((perl . pl) (emacs-lisp . el))
org-export-pdf-logfiles '(tex aux idx log out toc nav
snm vrb)
org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
org-startup-with-inline-images t
org-export-latex-format-toc-function 'my-toc-default
org-latex-to-pdf-process '(PDFLATEX='pdflatex -shell-escape' texi2dvi
-p -q -o %o -c %f)
org-export-time-stamp-file nil
org-src-lang-modes '((ocaml . tuareg) (elisp . emacs-lisp)
(ditaa . artist)
(asymptote . asy) (dot . graphviz-dot)
(graphviz . graphviz-dot) (mscgen .
graphviz-dot)
(sql-src . sql-edit) (sql . sql-edit)
(sqlite . sql-edit) (plantuml . plantuml)
(calc . fundamental))
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe)
org-src-mode-hook '((lambda nil (setq require-final-newline nil))
org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-shell-link-function 'yes-or-no-p
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-startup-indented t
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-M-RET-may-split-line '((default))
org-babel-sh-var-quote-fmt $(cat BABEL_TABLE\n%s\nBABEL_TABLE\n)
outline-mode-hook '((lambda nil (require (quote outline-magic))
(define-key outline-minor-mode-map [(tab)]
(quote outline-cycle))
)
)
org-export-html-use-infojs nil
org-babel-pre-tangle-hook '(save-buffer)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-export-latex-classes '((my-class
\\documentclass{ca-article}\n
[NO-DEFAULT-PACKAGES]\n[EXTRA]
(\\section{%s} . \\section*{%s})
(\\subsection{%s} . \\subsection*{%s})
(\\subsubsection{%s} .
\\subsubsection*{%s})
(\\paragraph{%s} . \\paragraph*{%s})
(\\subparagraph{%s} .
\\subparagraph*{%s}))
(article \\documentclass[11pt]{article}
(\\section{%s} . \\section*{%s})
(\\subsection{%s} . \\subsection*{%s})
(\\subsubsection{%s} .
\\subsubsection*{%s})
(\\paragraph{%s} . \\paragraph*{%s})
(\\subparagraph{%s} .
\\subparagraph*{%s}))
(report \\documentclass[11pt]{report}
(\\part{%s} . \\part*{%s})
(\\chapter{%s} . \\chapter*{%s})
(\\section{%s} . \\section*{%s})
(\\subsection{%s} . \\subsection*{%s})
(\\subsubsection{%s} .
\\subsubsection*{%s}))
(book \\documentclass[11pt]{book}
(\\part{%s} . \\part*{%s})
(\\chapter{%s} .
[O] bug in odt export via mathml of equations containing ''
If an org file contains a latex equation with a '' in it then when it is
exported to odt it makes dodgy xml. Unzipping the odt, opening the
content.xml and doing M-x rng-first-error gives the message:
`' that is not markup must be entered as `amp;'
To reproduce, insert this:
\begin{equation}
\delta_{mn} =
\begin{cases}
1 \text{if $n=m$}\\
0 \text{if $n\nem$}
\end{cases}
\end{equation}
(which I got from here
http://www.mathtoweb.com/cgi-bin/mathtoweb_users_guide.pl , search for
'cases')
into the file math-to-web-with-plastex.org in this post:
http://permalink.gmane.org/gmane.emacs.orgmode/48815 and export as per
instructions.
There may be a similar error with equations containing '', ''.
Myles
[O] Org-mode 7.7 Broken with respect to mouse and checklists?
Hi, I have a checklist in this form: - [ ] Item One - [ ] Item Two In Org-mode 7.7, if I put my mouse inside one of the checks and press the left button, I get the following message: org-open-at-point: Wrong type argument: markerp, 471 The number changes depending upon where the checkmark is. This works fine in org-mode 7.4 and 7.6. Any clues what I'm doing wrong in 7.7? Thanks, Patrick
Re: [O] calendar date adjustments blocked
Jude DaShiell jdash...@shellworld.net writes: I needed to enter information for two dates in org-mode and went into calendar using c-c+! and got the current date as expected then hit c-b to move the date to yesterday and pointer remained on today's date. So I ended up hitting cr on today's date and editing it in the actual org file and filling the rest of my entry in after it. Then I repeated the operation for today and entered today's information. I was a bit surprised that the date was locked like that once calendar mode was entered but managed a workaround anyway. C-c ! -2 RET should be 2 days ago. HTH, Bernt
Re: [O] calendar date adjustments blocked
Jude DaShiell jdash...@shellworld.net wrote: I needed to enter information for two dates in org-mode and went into calendar using c-c+! and got the current date as expected then hit c-b to move the date to yesterday and pointer remained on today's date. So I ended up hitting cr on today's date and editing it in the actual org file and filling the rest of my entry in after it. Then I repeated the operation for today and entered today's information. I was a bit surprised that the date was locked like that once calendar mode was entered but managed a workaround anyway. I guess your problem is that the calendar is indeed popped up, but the cursor is still in the daytime prompt in the minibuffer. As Bernt points out, typing -2 at that point gets you to the right date. The calendar seems to be for inveterate mouser users, not keyboard types: even if I C-x o to the calendar window, the cursor ends up not on today's date but off to the right somewhere and I get an error message: , | Error in post-command-hook (org-read-date-display): (buffer-read-only *Calendar*) ` Not sure what's going on there: I expected that after I switched windows to the Calendar, my cursor would be on today's date. Nick
