[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 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 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.
Re: [O] Video showing Jambunathan's ODT exporter
Herbert Sitz writes: > Last week I finally got around to testing the export to ODT that Jambunathan's > made available. Here's a 3 minute video showing how it works (calling odt > export from a document open in VimOrganizer): > http://vimeo.com/31564708 > > This is some seriously cool functionality for Org that deserves wider > exposure. > Jambunathan's done a great job. > > 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. > > I've seen comments about an ODT import that I haven't had a chance to look > into yet. > > Cheers, > > Herb Wow. The translation into ODT looks terrific. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Video showing Jambunathan's ODT exporter
Herbert Sitz writes: > Here's a 3 minute video showing how it works (calling odt export from > a document open in VimOrganizer): http://vimeo.com/31564708 Thanks, it is a nice video. You should add it to the Worg. > This is some seriously cool functionality for Org that deserves wider > exposure. Jambunathan's done a great job. Very much so. –Rasmus -- Sent from my Emacs
Re: [O] New version of VimOrganizer, an Org-mode clone in Vim
Michael Brand 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 ) In any case, for several people who contacted me about editing Org documents, and who had no preference for Vim over Emacs, I of course recommended that they go with Emacs. That's a no brainer. I use Viper/Vimpulse myself when in Emacs, and while nice, I certainly would not say it gives me the best of both worlds. It gives me Emacs, which is great, along with a useful but somewhat kludgy-feeling emulation of a decent chunk of Vim stuff. Good enough for some people trying to make the switch to Emacs. Not good enough for many, who have tried to make the switch only to turn back to Vim. You may be aware that the Org project itself is one of the major reasons people try to switch from Vim to Emacs. I was one of those people who tried and didn't like working in Emacs, despite using Viper/Vimpulse. Even now when I use Org-mode I mostly operate it using the menu system, not with the key-chord-combinations. One neat idea, I think, would be for someone to extend Viper/Vimpulse/(or Evil) with keybindings that provide a usable Vim-type modal interface to Org-mode's features. That could be nice. Regards, Herb
Re: [O] Best way to set up Org mode with MobileOrg over Dropbox
Hi Nikolai,
> As I can hardly be the only person with two computers, a mobile, and a
> desire to keep my org-agenda-files in sync between these three
> computers, I’ll pose this question here: How do you have this set up?
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.
When I change computers I run
[[http://www.neilvandyke.org/revbufs/revbufs.el][revbufs]] and can thus
quite seamlessly switch computers and just work on.
I know, tracking of text changes in 5 min intervals is obsessive. But
it eases agenda clocking reviews tremendously. I use git log for
displaying changes during an entry in the agenda.
I do not use MobileOrg because, when I last checked, the Android app
was not able to handle all my org files (it would need some fiddling
on what exactly I want mobile) and seemed to lack functionality
compared to the iphones. Maybe I will give it another shot shortly.
I guess when you have synced org files across all your emacs instances,
pushing and pulling to mobileorg from any at (nearly) all times is possible.
I am glad to share the code, but it needs some cleanups and some stuff
is first emacs-lisp steps, clumsy and irresponsible.
Best,
Gregor
Re: [O] New version of VimOrganizer, an Org-mode clone in Vim
Hi Herb On Thu, Nov 3, 2011 at 01:31, Herbert Sitz wrote: > I'd be glad to hear any feedback, comments, suggestions. . . My intention is the opposite of undermining your work in any way and I find it a good thing that users who prefer Vim can handle Org files too. But for completeness and because it is not well known let me suggest to point out here > An intro to some of the stuff in the new version is here: > https://github.com/hsitz/VimOrganizer/blob/master/intro.txt 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
Re: [O] [PATCH]: New Add defun org-mode-or-derived-mode-p
Hi, all, On the last few days I've been working on a major mode derived from org-mode. While I was at it, I've encoutered some difficulties related to those reported by the OP (Stefan). Specifically: in a lot of places, org-mode will check if it's the current major-mode and, if it's not, will refuse to perform some important task. But this poses a problem: a derived mode will always fail the test (eq major-mode 'org-mode) So, as long as org-mode relies on this test to perform some tasks, a derived mode will have non-functional pieces and bugs. Before this patch, all the checking was centralized in the defsubst `org-mode-p'. While I was developing my mode, I just changed it to (defsubst org-mode-p () (derived-mode-p 'org-mode)) Of course, this was just a temporary workaround, but I was actually planning on submitting a patch that implemented the (already discussed) `org-mode-or-derived-mode-p' alternative, replacing all calls to `org-mode-p' with calls to it. But then comes this patch, which removes `org-mode-p' altogether. So, now, there are several instances of the always-failing test on the code. Clearly, this is a big problem for anyone writing derived modes (there doesn't seem to be a lot of people doing that, but still). So, finally, here's my question: would it be possible to change all the (eq major-mode 'org-mode) tests and replace them with (derived-mode-p 'org-mode)? Is there any reason not to do this? That's effectively what happened when I changed the defsubst and I haven't noticed any problems. After all, org-mode will continue to always pass that test -- it's just that the derived modes will start to pass it too. If no ones' against it, I think I could create the patch. I haven't signed the FSF papers, but this change falls neatly into the "repetitive" category. Cheers, -- Cássio Koshikumo At Sat, 22 Oct 2011 11:31:21 +0200, Bastien wrote: > > Hi Tassilo, > > Tassilo Horn writes: > > > Ups, I've slightly misread your suggestion. Currently, there is only > > one place in org-src.el that check for being a mode derived from > > org-mode or org-mode itself. The second is useless, because > > (derived-mode-p 'org-mode) is true for org-mode, too. > > > > But as I've said, I've misread your suggestion and made a patch that > > completely erases org-mode-p and all its calls. Feel free to apply or > > discard it. :-) > > I applied this patch -- thanks for it. > > IMHO another reason for using (eq major-mode 'org-mode) instead of > (org-mode-p) is that new contributors are likely to use this more > explicit (though longer) expression before they find out that a > defsubst is available for that. > > -- > Bastien > >
[O] enhancements for org-agenda-to-appt
Hello, Before enhancing org-agenda-to-appt (and some other parts) to fit my needs, I would like to get some feedback for my ideas: - General opinions about the ideas. - Hints about already existing usable code. - Hints how to implement the ideas with the least effort. The general idea is, to get notified when a task has to be done, without any need to open the agenda. Default settings for the notifications can be overwritten for each task (by settings in the timestamp and/or additional properties). Here the details, in the order of priority: 1.) Warning period should be taken from timestamp That means, that the warntime must be passed to appt-add. 2.) Warning period in hours and minutes "-3h" for 3 hours or "-10M" for 10 minutes should be possible. 3.) Notification must continue when timestamp is past Perhaps, the notification should be even more aggressive, when a task is overdue. 4.) Easy modification of timestamps Often I get notified, that a task has to be done now, but the most obvious and easiest solution for me is: just do it tomorrow! Thus, when point is on a deadline line, M-right should advance the time by 1d, C-right by 1h, or similar. Decrementing with M-left and C-left should be possible too, but will surely be used less often... ;) 5.) org-check-deadlines must consider hours and minutes It should be possible, to show only overdue deadlines, even if they are overdue since 5 minutes. 6.) Timestamps with hours and minutes When adding deadlines or schedules, there should be also the time, not only the date. 7.) Switch from "todo" to "done" by clicking on the notification window When using `notifications-notify' this should be possible with the `:on-action' parameter. 8.) Configurable notification types For example: - email - notifications-notify - emacs-window (like the default in appt.el) - custom function 9.) Configurable notification period How often the notification function must be called (once per day, once per minute, etc...) 10.) Configurable notification duration This applies only for emacs-window and notifications-notify: how long must the notification be visible. 11.) Crescendo notifications Imagine, deadline is in 10 days. So a silent notification once or twice per day, saying it's time to begin to work, could be nice. But when time is getting shorter, only one hour left, bells will ring and the whole screen will blink red and green... TIA for any feedback! -- Peter
Re: [O] bug: org-mouse broken
Hi Nicolas On Thu, Nov 3, 2011 at 21:43, Nicolas Goaziou wrote: > I have pushed a fix in master. Thanks for reporting this. Resolved, thanks. Michael
Re: [O] bug: org-mouse broken
Hello, Michael Brand writes: > Git bisect finds it as the reason of a fontification issue of > headings with the keyword COMMENT or QUOTE: > - the face falls back from org-special-keyword to org-level- > - hidestars does not hide any more > > #+begin_src org > ,#+STARTUP: odd showall hidestars > ,* section > ,*** COMMENT subsection > ,*** QUOTE subsection > ,*** TODO subsection > #+end_src I have pushed a fix in master. Thanks for reporting this. Regards, -- Nicolas Goaziou
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Nicolas Goaziou writes: > Eric Schulte writes: > 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. > > Well, certainly, from a "Press TAB on #+begin_ line", they have exactly > the same meaning, and could as well be labelled #+begin_SOMETHING. But, > > - If I consider fontification, "Src blocks" differ from "Example > blocks", which differ from everything else. > > - If I consider `org-edit-special', C-c ' will bring you to a buffer > with a special mode in "Src blocks", fundamental mode in "Example > blocks" and "Verse blocks". > > - If I consider lists, you can have them in "Quote blocks", but not in > "Export blocks" or "Verse blocks", for example. > > - If I consider indentation, it will be ignored for "Example blocks" > (and should do the same for "Verse blocks"), could do something > entirely different on "Src blocks", and will indent normally, > i.e. "Quote blocks". > > - If I consider recursion, you can have "Quote blocks" inside "Center > blocks", but not inside "Export blocks". > > - If I consider options on the "begin_" line, "Example blocks" accept > them, but not "Center blocks". > > - If I consider entities, you can have them in "Verse blocks" but not > in "Example blocks" > > - If I consider export, obviously, they will all be treated very > differently. > > And I'm pretty sure I'm forgetting some other case. So, yes, from the > moon, they're pretty much indistinguishable ;) From an Org point of > view, they have 8 different meanings and, as such, need to be parsed > differently. At least, I've had to proceed that way when I wrote an Org > parser. > Point made :), I concede a huge difference between block types. I'm ultimately happy that the begin_property approach has not moved forward. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
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.
Best -- Eric
Eric Schulte 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 keywords like that.
>>
>> I would suggest this rule: #+begin_ is always for _content_
>> while #+keyword is always for internals that are removed when
>> exporting. #+text, #+html, #+LaTeX a
Re: [O] Video showing Jambunathan's ODT exporter
On 11/3/11 8:57 PM, Herbert Sitz wrote: This is some seriously cool functionality for Org that deserves wider exposure. Jambunathan's done a great job. +1 Christian
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Eric Schulte writes: >>> 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. Well, certainly, from a "Press TAB on #+begin_ line", they have exactly the same meaning, and could as well be labelled #+begin_SOMETHING. But, - If I consider fontification, "Src blocks" differ from "Example blocks", which differ from everything else. - If I consider `org-edit-special', C-c ' will bring you to a buffer with a special mode in "Src blocks", fundamental mode in "Example blocks" and "Verse blocks". - If I consider lists, you can have them in "Quote blocks", but not in "Export blocks" or "Verse blocks", for example. - If I consider indentation, it will be ignored for "Example blocks" (and should do the same for "Verse blocks"), could do something entirely different on "Src blocks", and will indent normally, i.e. "Quote blocks". - If I consider recursion, you can have "Quote blocks" inside "Center blocks", but not inside "Export blocks". - If I consider options on the "begin_" line, "Example blocks" accept them, but not "Center blocks". - If I consider entities, you can have them in "Verse blocks" but not in "Example blocks" - If I consider export, obviously, they will all be treated very differently. And I'm pretty sure I'm forgetting some other case. So, yes, from the moon, they're pretty much indistinguishable ;) From an Org point of view, they have 8 different meanings and, as such, need to be parsed differently. At least, I've had to proceed that way when I wrote an Org parser. Regards, -- Nicolas Goaziou
[O] Video showing Jambunathan's ODT exporter
Last week I finally got around to testing the export to ODT that Jambunathan's made available. Here's a 3 minute video showing how it works (calling odt export from a document open in VimOrganizer): http://vimeo.com/31564708 This is some seriously cool functionality for Org that deserves wider exposure. Jambunathan's done a great job. 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. I've seen comments about an ODT import that I haven't had a chance to look into yet. Cheers, Herb
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
While I still think `org-accumulated-properties-alist' is the most powerful solution -- as it is the only solution which allows a subtree property block to extend rather than overwrite a file-wide property. I've been thinking a little bit more about these issues and I'm returning to a previous suggestion... Do we still think that using #+KEYWORD+: lines is an ugly way to specify multi-line values for keywords. I think this has the advantages of simplicity, intuitiveness (its use is obvious once you see it), and generality (i.e., this could be used to allow multi-line tblfm lines). Just another thought -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Best way to set up Org mode with MobileOrg over Dropbox
Hi! I would like to use Org mode with MobileOrg over Dropbox and have all my org-agenda-files synced between all my computers, that is, my home computer, my work computer, and my mobile. Currently, as I understand MobileOrg and org-mobile-push/-pull, MobileOrg is only really designed to sync between one computer and your mobile. I have checked the manuals and the internets, but to no avail. As I can hardly be the only person with two computers, a mobile, and a desire to keep my org-agenda-files in sync between these three computers, I’ll pose this question here: How do you have this set up? Thanks!
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
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") --
Re: [O] How to format really long #+ lines
Perhaps this thread should be merged with the About commit named "Allow multi-line properties to be specified in property blocks" thread? Best -- Eric Robert McIntyre writes: > In my literate org projects at http://aurellem.com/, I often have to > use very long lines such as: > > #+description: Capture video from a JMonkeyEngine3 Application with > Xuggle, and use gstreamer to compress the video to upload to YouTube. > > #+begin_src clojure :noweb yes :tangle ../src/pokemon/types.clj :var > pokemon-table-gen-one=pokemon-table-gen-one :var > pokemon-table-gen-two=pokemon-table-gen-two :exports none > > They wrap off the end of my screen and are hard to edit. > > Is there a way to use multiple lines to achieve the same effect? I > couldn't find anything in the org manual. > > sincerely, > --Robert McIntyre > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] custom IDs not exported
Jambunathan K wrote: > > > Not sure I follow completely, but I will continue trying to cajole others > > to provide the actual patches and limit myself to providing guidance if > > necessary. > > Thanks for *not* submitting a patch. > > What I meant was - there is a process in place and Emacs project + FSF > are quite earnest as far as sticking to their own guns. > > [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? LWN covered it some time ago. AFAIK, it has been resolved. Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
>> > >> > In order to prevent confusion or needless argument: the path I >> >think we should back off of is the committing of these changes to >> >master - I think the work should be done in a branch and cooked >> >thoroughly before merging it to master. >> > >> > > Partly agree here - I was bitten by the changes, and have suspended work on > one project until this issue stabilizes - I do not want to change my files > after each change. > Hi Rainer, In a previous thread in which you were included I suggested a solution which works now and will continue to work in the future no matter how this issue is resolved. That solution is to use a multi-line file local variable [1] to customize the org-babel-default-header-args variable. I should have made a bigger deal of this solution when I posted it the first time, my apologies. In general I think we do a good job of not breaking functionality without on this master branch, and I think that introducing a multitude of branches would only serve to add confusion, reduce org-wide cooperation, and ultimately only delay rather than somehow remove them. Best -- Eric Footnotes: [1] to see the info page evaluate (info "(elisp)File Local Variables") -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] custom IDs not exported
> Not sure I follow completely, but I will continue trying to cajole others > to provide the actual patches and limit myself to providing guidance if > necessary. Thanks for *not* submitting a patch. What I meant was - there is a process in place and Emacs project + FSF are quite earnest as far as sticking to their own guns. [Context Switch] An interesting read (Euphemism for *totally* OT) http://news.ycombinator.com/item?id=2820986 Also google - Emacs violates GPL. Jambunathan K. --
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
> > But allowing a top-level :PROPERTIES: drawer with properties > whose scope is the entire file looks like a good idea to me. > I don't see what this would add, how would this solve the need for multi-line properties, and how would it differ from IMO being uglier than a series of #+PROPERTY: lines. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
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 keywords like that.
>
> I would suggest this rule: #+begin_ is always for _content_
> while #+keyword is always for internals that are removed when
> exporting. #+text, #+html, #+LaTeX are a few exception I can
> think of.
>
> Best,
--
Eric Schulte
http://cs.unm.edu/~eschulte/
[O] Plastex + MathToWeb (was Re: [odt] regression in using an equation sourced via latex_header)
Myles English writes:
>>> On Wed, 02 Nov 2011 21:38:42 +, Myles English said:
>
>>> On Wed, 02 Nov 2011 00:44:57 +0530, Jambunathan K said:
> >>> 2. mathml - You need to register your command file with -ncf
> >>> argument.
> >>>
> >>> For example, if I put the mystyle.tex in the same directory as
> >>> exported .org file and add the -ncf argument to the converter as
> >>> below
> >>>
> >>> #+begin_src emacs-lisp (setq org-latex-to-mathml-convert-command
> >>> "java -jar %j -ncf mystyle.tex -unicode -force -df %o %I ")
> >>> #+end_src
> >>>
>
> >> ncf option is documented here:
> >>
> http://www.mathtoweb.com/cgi-bin/mathtoweb_users_guide.pl#Using_newcommand_and_renewcommand
>
> > I have narrowed the problem I am having down to newcommands that
> > build on other newcommands, like so ...
>
> > If I have this in my style file:
>
> > \newcommand{\pressure}{p}
> > \newcommand{\capillaryPressure}{\pressure_{c}}
>
> This can work if the style file appears twice in the mathml command:
>
> #+begin_src emacs-lisp
> (setq org-latex-to-mathml-convert-command
> "java -jar %j -ncf mystyle.sty,mystyle.sty -unicode -force -df %o
> %I ")
> #+end_src
Where from you pulled this trick. Unless it is documented somewehere you
are most likely relying on an unintentional side-effect.
After some googling, I see that there is promising solution using
plastex. The solution is documented in the below file. The customary odt
file is attached as a proof-of-concept.
#+TITLE: How to circumvent ncf limitation of MathToWeb with Plastex?
#+AUTHOR:Jambunathan K
#+EMAIL: kjambunat...@gmail.com
#+DATE: 2011-11-01 Tue
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE: en
#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:
#+LINK_HOME:
#+XSLT:
#+LATEX_HEADER: \usepackage{jambu}
* Summary
This document outlines ways to circumvent limitations of "-ncf"
option in MathToWeb. See this [[http://lists.gnu.org/archive/html/emacs-orgmode/2011-11/msg00017.html][discussion thread]] for understanding of
the limitations.
* Settings
Leave the converter command at it's default value - which doesn't
use =-ncf= option.
#+begin_src emacs-lisp
(setq org-latex-to-mathml-convert-command
"java -jar %j -unicode -force -df %o %I ")
#+end_src
* mysttyle.tex
In the definitions below, one =newcommand= uses one another
=newcommand=. The below defintions goes in to user specified stlyes
file =mystyle.tex=.
#+begin_src tex
\newcommand{\pressure}{p}
\newcommand{\capillaryPressure}{\pressure_{c}}
#+end_src
* LaTeX Equation
The latex equation below relies on above newcommand definitions to
be available.
#+begin_src org
,#+LABEL: Equation:cp
,\begin{equation}
,\capillaryPressure=0
,\end{equation}
#+end_src
#+LABEL: Equation:cp
\begin{equation}
\capillaryPressure=0
\end{equation}
* Flatten equations with Plastex
Use [[http://wiki.lyx.org/LaTeX/ExpandNewcommands][plastex]] to flatten out the above equation.
The snippet below is a variation of script in the afore-mentioned
link and takes input from stdin and spews out flattened equation to
stdout.
Copy the below script to =fixup.py=.
#+srcname: fixup.py
#+begin_src python
#!/usr/bin/python
# _*_ coding: UTF-8 _*_
import sys
from plasTeX.TeX import TeX
doc = TeX(file=sys.stdin).parse()
# The processed document is contained in the string doc.source
# Print to file
# f = open('PlastexProcessed.tex', 'w')
sys.stdout.write(doc.source.encode('utf-8'))
# f.close()
#+end_src
* Hack Org with a defadvice
"sneak-in" custom processing in to org core by installing the advice
below.
#+begin_src emacs-lisp
(defadvice org-format-latex-as-mathml
(before my-org-format-latex-as-mathml activate)
"Prepend mystyle.tex to latex-frag.
Pass it through to \"plastex\". Use the flattened equation - which has
ZERO DEPENDENCIES on user's newcommand definitions - as input to MathToWeb."
(ad-set-arg 0 (and (ad-get-arg 0)
(with-temp-buffer
(insert-file-contents "mystyle.tex")
(goto-char (point-max))
(newline)
(insert (ad-get-arg 0))
(shell-command-on-region
(point-min) (point-max)
"./fixup.py" nil t
(get-buffer-create "*plastex-errors*"))
(buffer-string)
#+end_src
* Export
Export this file to ODT and see that above LaTeX equation is
satisfactorily converted to MathML by MathToWeb.
* Disabling above advice
You can disable the above advice anytime by doing this.
#+begin_src emacs-lisp
(ad-disable-advice 'org-format-latex-as-mathml 'before
Re: [O] custom IDs not exported
Jambunathan K 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? > If one cannot sum up the lines of changes one has submitted one should > err on the conservative side and not submit a patch. > > I wouldn't record this dissent note if Org were a one-off project. It is > part of a much greater project - a project which gives primacy not to > *convenience* but to a certain *principle*. > > If Nick or someone else checks in some change, someone raises a red flag > and questions the copyright (or whatver) the said code will be pulled > out from Emacs inconveniencing a whole bunch of users. More importantly > it will be shameful for Emacs project. > > We may not do great deeds ourselves but we can do our bit to lend a hand > to someone that stands for something. > Not sure I follow completely, but I will continue trying to cajole others to provide the actual patches and limit myself to providing guidance if necessary. Nick
Re: [O] Pass LaTeX exporter option prior to \documentclass
On Thu, Nov 3, 2011 at 12:55 PM, suvayu ali wrote:
> On Thu, Nov 3, 2011 at 18:48, John Hendy wrote:
>> On Wed, Nov 2, 2011 at 5:30 AM, suvayu ali
>> wrote:
>>> On Wed, Nov 2, 2011 at 03:43, suvayu ali
>>> 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!
John
> GL
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
Re: [O] bug: org-mouse broken
Hi Nicolas Thanks for applying commit dfcb6faef11a2439b56b18a6289803361d402130 Author: Nicolas Goaziou Date: Thu Aug 25 01:58:29 2011 +0200 Provide more consistent regexps for headlines Git bisect finds it as the reason of a fontification issue of headings with the keyword COMMENT or QUOTE: - the face falls back from org-special-keyword to org-level- - hidestars does not hide any more #+begin_src org ,#+STARTUP: odd showall hidestars ,* section ,*** COMMENT subsection ,*** QUOTE subsection ,*** TODO subsection #+end_src Michael
Re: [O] [OT] s/mime / mail encryption
Thank you for sharing your experiences guys, I only started thinking about this recently, when I had to send some documents to a banker. The issue is that I'm sure most bankers are not internet-savvy, they might not even know how to download something from a website (the alternative would be to put the docs in a SSL-protected URL with http basic auth). So in order to complete the transaction I had to send the documents via email anyway. Noth - M On Wed, Nov 2, 2011 at 7:48 PM, Bastien wrote: > Marcelo de Moraes Serpa writes: > > > Do you guys ever encrypt your emails? > > FWIW, I do sometimes (one or two times in a month.) > > -- > Bastien >
Re: [O] Pass LaTeX exporter option prior to \documentclass
On Thu, Nov 3, 2011 at 18:48, John Hendy wrote:
> On Wed, Nov 2, 2011 at 5:30 AM, suvayu ali
> wrote:
>> On Wed, Nov 2, 2011 at 03:43, suvayu ali 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.
GL
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Pass LaTeX exporter option prior to \documentclass
On Wed, Nov 2, 2011 at 5:30 AM, suvayu ali wrote:
> On Wed, Nov 2, 2011 at 03:43, suvayu ali 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=?
John
>
> Using tex commands is probably better than shell expansion.
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
Re: [O] bug#9695: allowed date range
Hi Carsten On Thu, Oct 13, 2011 at 10:27, Carsten Dominik wrote: > I am attaching a patch which will make time stamps without a day name > like <2011-10-12> work correctly. Furthermore, pressing C-c C-c on > a time stamp will fill in or fix the day name. > > However, I am not sure if this patch is complete, or if it > has side effects. So it would be good if a few people could > apply it and test it during their daily work for a few weeks, > and then report problems in this thread. I wonder how C-c C-c with a prefix (supported are one to three C-u) on a time stamp in a table field is expected to behave. In my opinion it should not only adjust the day name but like before also evaluate the table formula which it does not now. If the user does not expect and check the missing logs of the table calculation update he might wrongly assume that it happened and assume that there has been just no change. Michael
Re: [O] custom IDs not exported
> 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. If one cannot sum up the lines of changes one has submitted one should err on the conservative side and not submit a patch. I wouldn't record this dissent note if Org were a one-off project. It is part of a much greater project - a project which gives primacy not to *convenience* but to a certain *principle*. If Nick or someone else checks in some change, someone raises a red flag and questions the copyright (or whatver) the said code will be pulled out from Emacs inconveniencing a whole bunch of users. More importantly it will be shameful for Emacs project. We may not do great deeds ourselves but we can do our bit to lend a hand to someone that stands for something. Jambunathan K. --
[O] org-taskjuggler export problems
Hi,
I am trying to export a simple project plan from org to taskjuggler
through org-taskjuggler.el. I cannot get the behavour I expect and
need do some manual tweaks to get the taskjuggler file working. The
questions are as follows, whereafter the test org-file that I attempt
export and finally the tweaked taskjuggler file that I was expecting to
see from the 'org-export-as-taskjuggler'. What am I doing wrong?
1) The 'end' date specified in the ':taskjuggler_project' base is ignored and
the default 280d is used. Because the project duration is long this
throws an error. The 'start' date however seems properly picked up.
2) The 'task_id' fields are not exported properly.
3) The 'precedes' property is not exported at all
Taskjuggler version is 2.4.3 org version is 7.7.
Thanks,
J
# ORG testfile follows--
#+STARTUP: hidestars
#+STARTUP: outline
* Assessment findings (electrical)
:taskjuggler_project:
:PROPERTIES:
:start:2011-06-01
:end: 2014-06-01
:COLUMNS: %23ITEM(Task) %task_id %precedes %start %5Effort
:END:
** Tasks
*** Task A
:PROPERTIES:
:task_id: task_A
:precedes: mils_A
:Effort: 10d
:END:
*** Task B
:PROPERTIES:
:task_id: task_B
:precedes: mils_B
:Effort: 10d
:END:
*** Task C
:PROPERTIES:
:task_id: task_C
:precedes: mils_B
:Effort: 10d
:END:
** Milestones
*** Milestone A
:PROPERTIES:
:task_id: mils_A
:start:2012-01-01
:END:
*** Milestone B
:PROPERTIES:
:task_id: mils_B
:start:2013-01-01
:END:
# Tweaked taskjuggler file follows--
project assessment "Assessment findings (electrical)" "1.0" 2011-06-01
+2800d {
}
shift s40 "Part time shift" {
workinghours wed, thu, fri off
}
resource jim "jim" {
}
task assessment "Assessment findings (electrical)" {
purge allocations
allocate jim
start 2011-06-01
end 2014-06-01
task tasks "Tasks" {
task task_a "Task A" {
effort 80.0h
precedes !!milestones.mils_a
}
task task_b "Task B" {
effort 80.0h
precedes !!milestones.mils_b
}
task task_c "Task C" {
effort 80.0h
precedes !!milestones.mils_b
}
}
task milestones "Milestones" {
task mils_a "Milestone A" {
milestone
start 2012-01-01
}
task mils_b "Milestone B" {
milestone
start 2013-01-01
}
}
}
taskreport "Gantt Chart" {
headline "Project Gantt Chart"
columns hierarchindex, name, start, end, effort, duration, completed,
chart
timeformat "%Y-%m-%d"
hideresource 1
loadunit shortauto
}
resourcereport "Resource Graph" {
headline "Resource Allocation Graph"
columns no, name, utilization, freeload, chart
loadunit shortauto
sorttasks startup
hidetask ~isleaf()
}
--
Johnny
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Christian Moe wrote: > On 11/3/11 2:26 AM, Bastien wrote: > > Hi Nicolas, > > > > Nicolas Goaziou writes: > (...) > >> 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 > > Correct me if I'm wrong, but the purpose of #+BIND is to specify a > file local variable, isn't it? The manual gives one example of how to > modify export settings with it. > It's actually more restricted than that: during preprocessing, the function org-install-letbind adds the bindings as file-locals *during export*. > With Babel blocks, there should be clarity what variables are to be > passed to the block as arguments, and what variables should not. > Currently this is completely clear: Only variables named in a `var' > property or header argument are passed. > > Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's > for Babel and when it's not. Say we make Babel use BIND values, and > someone has this setup: > > #+BIND: org-export-latex-low-levels itemize > #+BIND: foo 1 > #+BIND: bar 2 > > Then this: > > #+BEGIN_SRC emacs-lisp > (+ foo bar) > #+END_SRC > > would tangle to something like: > > (let ((org-export-latex-low-levels (guote itemize)) >(foo (quote 1)) >(bar (quote 2))) > (+ foo bar)) > > -- which was not the intention. > I agree - the bind namespace and the code block variable name space should be separate. BIND was iirc Carsten's throwing up his hands when people were asking for more and more options to be settable from within the file: he built a general (if not particularly convenient) mechanism to allow people to do just that. Nick > Yours, > Christian >
Re: [O] [odt] regression in using an equation sourced via latex_header
>> On Wed, 02 Nov 2011 21:38:42 +, Myles English said:
>> On Wed, 02 Nov 2011 00:44:57 +0530, Jambunathan K said:
>>> 2. mathml - You need to register your command file with -ncf
>>> argument.
>>>
>>> For example, if I put the mystyle.tex in the same directory as
>>> exported .org file and add the -ncf argument to the converter as
>>> below
>>>
>>> #+begin_src emacs-lisp (setq org-latex-to-mathml-convert-command
>>> "java -jar %j -ncf mystyle.tex -unicode -force -df %o %I ")
>>> #+end_src
>>>
>> ncf option is documented here:
>>
http://www.mathtoweb.com/cgi-bin/mathtoweb_users_guide.pl#Using_newcommand_and_renewcommand
> I have narrowed the problem I am having down to newcommands that
> build on other newcommands, like so ...
> If I have this in my style file:
> \newcommand{\pressure}{p}
> \newcommand{\capillaryPressure}{\pressure_{c}}
This can work if the style file appears twice in the mathml command:
#+begin_src emacs-lisp
(setq org-latex-to-mathml-convert-command
"java -jar %j -ncf mystyle.sty,mystyle.sty -unicode -force -df %o
%I ")
#+end_src
Myles
Re: [O] custom IDs not exported
Bastien wrote: > Hi Nick, > > Nick Dokos writes: > > > With this information, do you think you could get a patch together? > > I hope Sten will be able to provide a patch! > > > Let me know if you have questions. > > Thanks for the detailed analysis. > > > Footnotes: > > > > [fn:1] For legal reasons, I cannot fix it myself. > > Com'on Nick, you're not allowed to make patches longers than 20 lines, > which makes it a nice challenge to fix these kind of issues in less than > 20 lines :D > 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? I > > [fn:2] As an aside, note the inconsistency in the function names. Bastien, > >is this worth fixing? > > It's always worth fixing such things. Depends on how much time it costs > to the persons who undertake the fix... Patch welcome! > OK, I'll take a look at all the exporters and go with the more popular format. Nick > Thanks, > > -- > Bastien >
Re: [O] org-mobile-push problem
> Sorry, I didn't get into too much detail here because I had the
> feeling that the problem might have been cause by me not being able
> to use the package manager correctly rather than the package manager
> itself. But if it could help others, of course, I'm sharing the
> details as far as I understand them.
>
> I'm using Aquamacs (for Mac OS):
>
> GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
> of 2011-10-25 on braeburn.aquamacs.org - Aquamacs Distribution 2.4
> Copyright (C) 2011 Free Software Foundation, Inc.
>
> When I run "package-list-packages", I get the message "Failed to
> download `Org-mode' archive." (didn't note that before), but it still
> offered the latest version of Org nevertheless.
Do
M-x customize-variable RET package-archives RET
and delete the following "Org-mode" archive from the list:
--8<---cut here---start->8---
(add-to-list 'package-archives
'("Org-mode" . "http://orgmode.org/pkg/daily/";))
--8<---cut here---end--->8---
Additionally, you can also look at ~/.emacs.d/elpa/archives/ subdir and
recursively delete the directory corresponding to "Org-mode" archive.
> I could install it from there and Org appeared to be updated to
> version 7.7, but somehow the macro "org-eval-in-environment" was only
> found after reloading Org uncompiled after every restart of
> Emacs.
> This could be repeated infinitely, i.e., I always got this error
> message when running "package-list-packages" and it always offered me
> to install Org. Now I downloaded the tar-file manually and installed
> it with "package-install-file". Now "org-eval-in-environment" is found
> normally. After "package-list-files" I still get the message "Failed
> to download `Org-mode' archive.", but it shows Org as installed and
> does no longer offer to install it.
>
> I hope that was more helpful. If you need more information, I will be
> happy to try to provide it.
I am trying to isolate the root cause of the issue here. Hope you can
help me locate the root cause.
Try the following procedure:
1. Store the org-*.tar that you have downloaded in some safe place.
2. rm -rf ~/.emacs.d/elpa/org-* {BE CAREFUL HERE, YOU ARE DELETING
STUFF}
- In this step you are deleting your org installed through elpa.
3. Check your .emacs - Does it make have (require 'org-install)? If it
has this entry remove that line or comment out that line.
4. Restart emacs
5. M-x locate-library RET org RET
6. Note the directory reported.
- If it looks like it is coming from your default Emacs installation
directory then proceed to step 7.
- If it looks like it is one of the directories added by you, delete
that directory from either load-path or simply delete it from the
disk. (To be safe, instead of deleting you can just rename or move
the directory somewhere else). Goto step 4.
7. Note the version of Org with M-x org-version RET. Now do a M-x
package-install-file RET
8. Restart Emacs
9. Now. Do you still run in to the original org-macs issue that you
reported?
Extra information for me:
10. What does C-h v package-enable-at-startup RET report?
> Bastian
>
>
--
Re: [O] org-mobile-push problem
Am 03.11.2011 um 12:03 schrieb Jambunathan K: >> It says "Org-mode version 7.7". However, I feel that there was >> something strange with my installation. I checked my files in my Emacs >> folder and everything seemed really messed up, so I just reinstalled >> org from the latest build and now it works! I had tried that before >> automatically with the package manager but now I used the package >> manager to install it from the file. I think that is where the strange >> installation came from originally. > > It is not clear to me what you are saying here: > > Did the package manager solve your problem or it didn't solve your > problem? > > What version of emacs are you using? There were two previous instances > where people had issues with org-macs.el not being available when > certain files were compiled. > > I have a feeling that it is not the problem with the people as such but > how package manager goes about compiling the files. > > So any information you provide here will help improve the situation for > other folks. > -- Sorry, I didn't get into too much detail here because I had the feeling that the problem might have been cause by me not being able to use the package manager correctly rather than the package manager itself. But if it could help others, of course, I'm sharing the details as far as I understand them. I'm using Aquamacs (for Mac OS): GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-10-25 on braeburn.aquamacs.org - Aquamacs Distribution 2.4 Copyright (C) 2011 Free Software Foundation, Inc. When I run "package-list-packages", I get the message "Failed to download `Org-mode' archive." (didn't note that before), but it still offered the latest version of Org nevertheless. I could install it from there and Org appeared to be updated to version 7.7, but somehow the macro "org-eval-in-environment" was only found after reloading Org uncompiled after every restart of Emacs. This could be repeated infinitely, i.e., I always got this error message when running "package-list-packages" and it always offered me to install Org. Now I downloaded the tar-file manually and installed it with "package-install-file". Now "org-eval-in-environment" is found normally. After "package-list-files" I still get the message "Failed to download `Org-mode' archive.", but it shows Org as installed and does no longer offer to install it. I hope that was more helpful. If you need more information, I will be happy to try to provide it. Bastian
Re: [O] dynamic block for columnview: indent and TBLFM
There is another issue with export (to HTML) that I found out only now to be related with indentation: The example below exports like expected but when all lines below project are indented (by two spaces) then the lines BEGIN and END are also exported. * project #+BEGIN: columnview :maxlevel 3 :id ddb38905-fcbb-473b-99ef | Task| Days | |-+--| | *** Total of Effort |1 | | * feature |1 | #+END: Michael
Re: [O] org-mobile-push problem
> It says "Org-mode version 7.7". However, I feel that there was > something strange with my installation. I checked my files in my Emacs > folder and everything seemed really messed up, so I just reinstalled > org from the latest build and now it works! I had tried that before > automatically with the package manager but now I used the package > manager to install it from the file. I think that is where the strange > installation came from originally. It is not clear to me what you are saying here: Did the package manager solve your problem or it didn't solve your problem? What version of emacs are you using? There were two previous instances where people had issues with org-macs.el not being available when certain files were compiled. I have a feeling that it is not the problem with the people as such but how package manager goes about compiling the files. So any information you provide here will help improve the situation for other folks. --
[O] Status of changes - how to convert the following
Hi
Sorry - I mentioned it already, but I have lost track of how things are
standing at the moment.
I am using Org-mode version 7.7 (release_7.7.512.g4d2a), and get, based on
the following arguments, after tangling, a file which begins with:
##
[[file:~/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/trunc/R/Analysis_sensitivity.org::*Initialise%2520Analysis%2520(initializeAnalysis())][Initialise-Analysis-\(initializeAnalysis\(\)\):1]]
RESULTSDIR <-
"/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/"
ANALYSISDIR <-
"/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/"
Shouldn't #+BABEL: be deprecated now?
In that line:
I have the following in my org file:
#+TITLE: Analysis Sensitivity Analysis --- Analysis_sensitivity.org
#+AUTHOR:Rainer M Krug
#+EMAIL: m...@home.de
#+DATE: 2010-09-14 Tue
#+DESCRIPTION:
#+KEYWORDS:
:CONFIG:
#+LANGUAGE: en
#+DRAWERS: HIDDEN PROPERTIES STATE CONFIG BABEL OUTPUT LATEX
#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:
http://orgmode.org/org-info.js
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:
#+LINK_HOME:
#+XSLT:
#+ATTR_LaTeX: width=30em
#+STARTUP: nohideblocks
#+OPTIONS: ^:{}
:END:
:LATEX:
#+LATEX_HEADER: \usepackage{rotfloat}
#+LATEX_HEADER: \definecolor{light-gray}{gray}{0.9}
#+LATEX_HEADER: \lstset{%
#+LATEX_HEADER: basicstyle=\ttfamily\tiny, % the font that is
used for the code
#+LATEX_HEADER: tabsize=4, % sets default tabsize
to 4 spaces
#+LATEX_HEADER: numbers=left,% where to put the
line numbers
#+LATEX_HEADER: numberstyle=\tiny, % line number font size
#+LATEX_HEADER: stepnumber=0,% step between two
line numbers
#+LATEX_HEADER: breaklines=true, %!! don't break long
lines of code
#+LATEX_HEADER: showtabs=false, % show tabs within
strings adding particular underscores
#+LATEX_HEADER: showspaces=false,% show spaces adding
particular underscores
#+LATEX_HEADER: showstringspaces=false, % underline spaces
within strings
#+LATEX_HEADER: keywordstyle=\color{blue},
#+LATEX_HEADER: identifierstyle=\color{black},
#+LATEX_HEADER: stringstyle=\color{green},
#+LATEX_HEADER: commentstyle=\color{red},
#+LATEX_HEADER: backgroundcolor=\color{light-gray}, % sets the
background color
#+LATEX_HEADER: columns=fullflexible,
#+LATEX_HEADER: basewidth={0.5em,0.4em},
#+LATEX_HEADER: captionpos=b,% sets the caption
position to `bottom'
#+LATEX_HEADER: extendedchars=false %!?? workaround for
when the listed file is in UTF-8
#+LATEX_HEADER: }
#+LATEX_HEADER: \usepackage[landscape, top=1cm, bottom=1cm, left=1cm,
right=1cm]{geometry}
#+ATTR_LaTeX: width=10cm
#+BIND: org-export-latex-image-default-option "width=0.35\\textwidth"
:END:
:BABEL:
#+BABEL: :session *R*
#+BABEL: :results output
#+BABEL: :exports code
#+BABEL: :comments yes
#+BABEL: :tangle Analysis_sensitivity.R
#+BABEL: :var
RESULTSDIR="/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/"
#+BABEL: :var
ANALYSISDIR="/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/"
#+BABEL: :var RESULTSDIR="/home/rkrug/sim/nsa/trunc/results/"
#+BABEL: :var ANALYSISDIR="/home/rkrug/sim/nsa/SA/"
:END:
where the indented lines are "disabled".
Assuming that #+BABEL is deprecated, how do I have to change it so that it
is working? The lines with #+BABEL: are affected, and the single lines have
to be changed to #+PROPERTY: - right?
But what is about the :var statements, which are now in two lines, and
which I would prefer to stay in separate lines?
Thanks,
Rainer
--
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
Re: [O] org-mobile-push problem
Am 03.11.2011 um 01:36 schrieb Nick Dokos: > i...@bastianebeling.org wrote: > >> >> Am 03.11.2011 um 00:28 schrieb Nick Dokos: >> >>> i...@bastianebeling.org wrote: >>> > when I run org-mobile-push: > > byte-code: Invalid function: org-eval-in-environment >>> org-eval-in-environment is a macro defined in org-macs.el and macros >>> sometimes cause problems with compiled code unless some care is taken. >>> With uncompiled code, you just have to make sure that the macro >>> definition is loaded, before you do the org-mobile-push: just add >>> >>> (require 'org-macs) >>> >>> after you load org in your .emacs (or wherever). >>> >>> Afaict, it is not called directly from org-mobile-push, but the agenda >>> code does call it (and does not require it), so maybe the solution is >>> that the (require 'org-macs) should be added to org-agenda.el; you might >>> try it and see whether it resolves the problem for you, but I'll let >>> David Maus or Achim Gratz or some other macro guru have the final word. >>> >>> Nick >> >> Thank you! Unfortunately, adding (require 'org-macs) to my .emacs >> and/or to my org-agenda.el didn't help. (I checked and the macro isn't >> defined in my org-macs.el nor does it appear in any other file on my >> computer.) >> > > What does M-x org-version RET say? It says "Org-mode version 7.7". However, I feel that there was something strange with my installation. I checked my files in my Emacs folder and everything seemed really messed up, so I just reinstalled org from the latest build and now it works! I had tried that before automatically with the package manager but now I used the package manager to install it from the file. I think that is where the strange installation came from originally. Nik, I hope you get it fixed as well. Nick and David, thanks for your help! Bastian
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
On 11/3/11 2:42 AM, Bastien wrote: But allowing a top-level :PROPERTIES: drawer with properties whose scope is the entire file looks like a good idea to me. How other would feel about this? Not sure if this is already clear, but just in case: The functionality is already there. PROPERTY lines set buffer-wide properties. This works now: #+TITLE: My foobar file #+PROPERTY: foo 1 #+PROPERTY: bar 2 #+PROPERTY: baz 3 Replacing it with a top-level property drawer before the outline would make another bit of syntax redundant, and it would sometimes save a bit of typing (if there are many buffer-wide properties tobe set): #+TITLE: My foobar file :PROPERTIES: :foo: 1 :bar: 2 :baz: 3 :END: I have come to expect that any file-wide settings are in #+... lines and that any property drawers are associated with outline entries. I don't know how important it is to maintain those expectations. Yours, Christian
Re: [O] New version of VimOrganizer, an Org-mode clone in Vim
Thorsten writes: sorry, incomplete sentence, wrong keystroke ... > nice, I announced this on the picolisp newsgroup, since this new > org-babel language is more vim based, and VimOrganizer might help to ...spread the news about orgmode and org-babel in the picolisp community. cheers -- Thorsten
Re: [O] New version of VimOrganizer, an Org-mode clone in Vim
Herbert Sitz writes: > I just formally pushed up a new version of VimOrganizer, an Org clone in Vim. nice, I announced this on the picolisp newsgroup, since this new org-babel language is more vim based, and VimOrganizer might help to -- Thorsten
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
On 11/3/11 2:26 AM, Bastien wrote: Hi Nicolas, Nicolas Goaziou writes: (...) 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 Correct me if I'm wrong, but the purpose of #+BIND is to specify a file local variable, isn't it? The manual gives one example of how to modify export settings with it. With Babel blocks, there should be clarity what variables are to be passed to the block as arguments, and what variables should not. Currently this is completely clear: Only variables named in a `var' property or header argument are passed. Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's for Babel and when it's not. Say we make Babel use BIND values, and someone has this setup: #+BIND: org-export-latex-low-levels itemize #+BIND: foo 1 #+BIND: bar 2 Then this: #+BEGIN_SRC emacs-lisp (+ foo bar) #+END_SRC would tangle to something like: (let ((org-export-latex-low-levels (guote itemize)) (foo (quote 1)) (bar (quote 2))) (+ foo bar)) -- which was not the intention. Yours, Christian
Re: [O] New version of VimOrganizer, an Org-mode clone in Vim
Hmmm... nice! Maybe it helps to bring finally peace between Vi and Emacs users. I will forward it to my Vi-friends:) Torsten On Nov 3, 2011 9:31 AM, "Herbert Sitz" wrote: > I just formally pushed up a new version of VimOrganizer, an Org clone in > Vim. > > This version is much closer to being a true alternative to using Org-mode > in > Emacs. I say alternative to "using Org-mode in Emacs", because > VimOrganizer in > large part operate as a front end to Org-mode by making calls to a running > Emacs > server. All of the export functionality is done this way, as is access to > stuff > like Org-babel, spreadsheet evaluation, live blocks like clocktables, > column > blocks, etc. > > I'd be glad to hear any feedback, comments, suggestions. . . > > An intro to some of the stuff in the new version is here: > https://github.com/hsitz/VimOrganizer/blob/master/intro.txt > > Git page is here: > https://github.com/hsitz/VimOrganizer > > And the page on Vim's website is here: > http://www.vim.org/scripts/script.php?script_id=3342 > > I will try to get some videos of the new functionality in next day or two. > One > main thing I'm happy about is I extended my patch of Vim to allow separate > highlighting of TODO items on folded headings. Previously my patch enabled > level-dependent fold highlighting, but always showed TODOs in same color > as the > folded heading. Much nicer to have everything collapsed and still have the > TODOs pop out at you. > > Thanks to everybody on here who's provided help for my (sometimes silly) > questions about Org-mode and how it works. I'm starting to really > appreciate > elisp, so who knows what the future holds. . . > > Regards, > > Herb > > > >
