Re: [O] *Natural* language highlighting
Alex Lane wrote:
> ...
> On a (somewhat) related note, might someone point me at the face
> description(s) used for orgmode definition lists (e.g., foo :: bar)? I
> would specifically like to make the 'foo' part of such a definition a
> bit more assertive.
>
Unfortunately, that's not a specific face. The pattern is set in
org.el:org-set-font-lock-defaults around line 5894:
,
|...
| ;; Description list items
| '("^[ \t]*[-+*][ \t]+\\(.*?[ \t]+::\\)\\([ \t]+\\|$\\)"
|1 'bold prepend)
|...
`
So you can redefine the bold face but that's probably a bad idea, since
it is going to change the appearance of a lot of things. Otherwise, you
have to change the code above to achieve what you want, by replacing
``bold'' with the face of your choice (possibly of your own devising, if
the list of faces obtained with list-faces-display does not contain one
that meets your requirements.)
Nick
Re: [O] HTML export fails with (void-variable org-version)
Bernt Hansen writes: > Thanks for the detailed explanation Achim. I hope my problem report on > this issue wasn't taken as a complaint - it wasn't intended that way -- Don't worry, problem reports are appreciated (even in the form of comaplints, which yours weren't). As I said before, I do want to support everything non-buggy that the old Makefile did. > I'll redo my make autoloads after pointing at NT Emacs (tomorrow) and > will remove emacs from Cygwin since the only reason I installed it in > the first place was to try to get make autoloads to complete. If you pull from latest Git you should get a Makefile that drops a local.mk into your lap that you only need to edit (unless you already have one). It already has a default target that includes "autoloads". It also updates the info documentation, which should work when you have makeinfo on Cygwin. If not, just put your own default target there without "info", but having a current documentation comes highly recommended. > Your efforts on cleaning up the Makefile system for org-mode are really > appreciated. I'll just add 'make autoloads' to my list of things to do > when updating my master branch in git. That should be a only temporary measure, it will eventually work as it did before — with some magic behind the curtains to DTRT(TM) instead of relying on buggy behaviour. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Org referring to Gnus mail
François Pinard writes: > Hello. > > In my Org files, I have many references to Gnus articles which are part > of mailgroups. When batch reading email with Gnus, I'm OK with the > newsreader paradigm, in which an article is almost deleted as soon as it > gets read: it will not show the next time I'll visit the group. > > However, when an article is referred through an Org link, I think I > would prefer if the paradigm did not apply. Currently, I see myself > "unreading" such articles all the time, which is a bit tedious, and > error prone as well, as I can easily forget to do it. I wonder if > someone would not imagine some trickery by which, when the reference > comes from Org, the Gnus article does not get automatically read. > > If references were always established "manually", I could take the habit > of banging each article on which there is an Org link, at the time I > establish the link. The nicety is that a ticked article does not > "become read" when visited. Hi François, I am sure there is a better answer out there, but there is another nicety of Gnus you could exploit: marks (including the "read" mark) are never populated to a Gnus group automatically on reading, but only when you do an updating command such as q or x. If you close the group with `gnus-summary-exit-no-update' (the Q key in default binding), these messages will not be marked as read. > > However, in the practical case, I have an Emacs command, launching an > external helper program, which finds all articles within all mailgroups > within the few local servers, matching a specific regexp somewhere, and > then outputs a conveniently sorted Org tree holding [[...][...]] links > to them all. As the matches transiently depend on the pattern, it would > prefer avoiding any kind of side effects on the unread articles. > > François > > P.S. I'm quite surprised by the speed of the search. Grepping through > 540 Megs of text distributed in over 1 files takes a bit less than > half a second, once the memory cache got populated. It's hard for me to > believe, and I'm unsuccessfully looking for a bug. It apparently works! So you have a command to automatically populate an Org tree from local newsgroups? Wow, sounds cool. I've long wondered if Org would make a good mailreader, and it sounds like you've determined that yes, it could :) -- Cheers, WGG
Re: [O] mail integration, advice?
On Thu, Apr 26 2012, Matt Price wrote: > I'd like to take one more shot at returning to text-based email within > emacs, mostly because I want to be able to integrate mail easily into > my org-mode workflow. The last time I tried this I used wanderlust, > and I'd be willing to give it a try again but a couple of things have > discouraged me in the past: > - wl causes emacs to freeze up when it checks or sends mail, and can > take quite a long while to complete these operations Others have given imap solutions -- I'm using POP and the mpop utility works great for this. I have it use `set-process-filter' and `set-process-sentinel' to let me know what it did once it's done. > - fast search and easy-to-manage virtual folders of some kind -- I see > mu and notmuch are very strong on both these fronts Again, for POP -- nnmairix is fast, but I've gotten strange behavior out of the virtual groups it creates, and calling it from gnus is many times slower than using it from the command line. 1.5¢ -- GNU Emacs 24.1.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-04-25 on pellet
Re: [O] defining a clocktable in a capture template with absolute timespan computed relative to today
Hi Brian, Brian van den Broek writes: > how to add 1 day to the return value of (current-time). This hard coding is out of org-mode range, #+BEGIN_SRC elisp (format-time-string "%Y-%m-%d" (time-add (current-time) (seconds-to-time (* 24 60 60 #+END_SRC #+RESULTS: : 2012-04-28 where the current-time is: #+BEGIN_SRC elisp (format-time-string "%Y-%m-%d" (current-time)) #+END_SRC #+RESULTS: : 2012-04-27 > I've been experimenting with a new means of using org to plan my day at > the outset and, at the end of it, to easily review how close I have come > to accomplishing what I planned. I'm very interested. How do you compare your plan with results? HTH, IP > Hi all, > > I've been experimenting with a new means of using org to plan my day at > the outset and, at the end of it, to easily review how close I have come > to accomplishing what I planned. For that second component, I want a > clocktable covering the day to allow for an easy review of what I have > accomplished. Since I am an extreme night-owl, I want the table to cover > 8:00 of the day to 8:00 of the next one. (Things I do at 0:300 I think of as > having been part of the previous day.) This is easy enough to accomplish > manually. Today's, for instance, is defined as > #+BEGIN: clocktable :maxlevel 4 :scope agenda :tstart "<2012-04-17 > 08:00>" :tend "<2012-04-18 Wed 08:00>" :fileskip0 > > #+END: > > I've defined a capture template to produce, in a datetree, the > boiler-plate for my daily planning and for the end of day review. As > yet, the best I have managed for the clocktable is to include (some > aspects omitted): > #+BEGIN: clocktable :tstart \"<%(format-time-string \"%Y-%m-%d\" > (current-time)) 08:00>\" :tend \"<%(format-time-string \"%Y-%m-%d\" > (current-time)) 08:00>\" :fileskip0 > > #+END: > > This still needs some fiddling to get the :tend parameter right as it > defines it as exactly the same as the :tstart. > > What I need is something that fulfils the intent of > :tend \"<%(format-time-string \"%Y-%m-%d\" (+ oneday > (current-time))) 08:00>\". > However, the docstring of (current-time) reads: > > Return the current time, as the number of seconds since 1970-01-01 00:00:00. > The time is returned as a list of three integers. The first has the > most significant 16 bits of the seconds, while the second has the > least significant 16 bits. The third integer gives the microsecond > count. > > My meagre elisp means that I will have to spend quite some time figuring > out how to add 1 day to the return value of (current-time). > > So: > > 1) Is there an org-native way that I have overlooked to define a > clock-table in a capture template that has the relative time-span that I > desire? > > 2) If not, would someone please take pity on my poor elisp and give me > the push to bring home my definition? > > Thanks and best, > > Brian vdB > > PS I suspect that this will wrap badly. Apologies if so; I hope the > intent is nonetheless clear.
[O] Org referring to Gnus mail
Hello. In my Org files, I have many references to Gnus articles which are part of mailgroups. When batch reading email with Gnus, I'm OK with the newsreader paradigm, in which an article is almost deleted as soon as it gets read: it will not show the next time I'll visit the group. However, when an article is referred through an Org link, I think I would prefer if the paradigm did not apply. Currently, I see myself "unreading" such articles all the time, which is a bit tedious, and error prone as well, as I can easily forget to do it. I wonder if someone would not imagine some trickery by which, when the reference comes from Org, the Gnus article does not get automatically read. If references were always established "manually", I could take the habit of banging each article on which there is an Org link, at the time I establish the link. The nicety is that a ticked article does not "become read" when visited. However, in the practical case, I have an Emacs command, launching an external helper program, which finds all articles within all mailgroups within the few local servers, matching a specific regexp somewhere, and then outputs a conveniently sorted Org tree holding [[...][...]] links to them all. As the matches transiently depend on the pattern, it would prefer avoiding any kind of side effects on the unread articles. François P.S. I'm quite surprised by the speed of the search. Grepping through 540 Megs of text distributed in over 1 files takes a bit less than half a second, once the memory cache got populated. It's hard for me to believe, and I'm unsuccessfully looking for a bug. It apparently works!
[O] *Natural* language highlighting
I've been using both Cyrillic and Latin characters (utf-8) in org mode and while I see quite a bit of discussion (in the archives and elsewhere) of various highlighting schemes for programming language syntax, has anyone ever heard of a way of color-coding different character sets (such as Cyrillic/Latin)? On a (somewhat) related note, might someone point me at the face description(s) used for orgmode definition lists (e.g., foo :: bar)? I would specifically like to make the 'foo' part of such a definition a bit more assertive. Cheers...
Re: [O] HTML export fails with (void-variable org-version)
Achim Gratz writes: > Bernt Hansen writes: >> I tried that... and installed emacs under Cygwin (so it can find emacs >> to run emacs -batch) and then had to fix permissions on org-install >> (since it's on a windows drive) before make autoloads worked. > > It's preferrable to use NTEmacs for this step, even though the .elc > files should be compatible. > >> I didn't spend any time trying to correct install locations in the >> makefile. I run org-mode without compiling any sources normally and >> having to do the extra make step each time I move around the source tree >> isn't going to be very enjoyable. I have no idea if I need to rerun >> this make autoloads command on a regular basis or not. > > Yes and no. As long as all the autoloaded functions continue to be in > the same load-file and their names don't change and there are no new > functions that need to be autoloaded, org-install.el effectively isn't > going to change. But that's a deception, since there is no way you > could determine if it should have been changed unless you actually > generate it anew. > > As I said, I'm still working to provide specifically for the case that > org-version.el is missing (which would normally produce an autoloaded > defconst org-version...) and injecting an org-version from looking at > the git version of the work-tree (if it finds one). That will also > encompass an (autoloaded) function (with the load-file located in > UTILITIES/ most likely) that you can call in emacs to re-generate > org-install.el, since org-install.el is absolutely not optional. > > So going forward make will not be a requirement for simply using org > either from Git or from tarball anymore. Thanks for the detailed explanation Achim. I hope my problem report on this issue wasn't taken as a complaint - it wasn't intended that way -- I just wanted to report what I perceived to be a problem and at the time I didn't have time to mess with the setup so I just reverted to a previous working state in git. I'll redo my make autoloads after pointing at NT Emacs (tomorrow) and will remove emacs from Cygwin since the only reason I installed it in the first place was to try to get make autoloads to complete. Your efforts on cleaning up the Makefile system for org-mode are really appreciated. I'll just add 'make autoloads' to my list of things to do when updating my master branch in git. Regards, Bernt
Re: [O] missing autoloads / (void-variable org-version)
Hi Sébastien, "Sebastien Vauban" writes: > You think that everything related to the Test package would have been loaded > correctly. Not the case, "obviously"... More precisely: it has been _loaded_ correctly (i.e. it is in the load path), but the functions have been _autoloaded_ from a previous package. Looking for the package from the autoloaded function will point at the first matching package in load-path, which might not be the one from which functions have been autoloaded... Yep, it took me a while to understand it, so this email is a tribute to Achim's patience :) > Are we on the same wavelength? I think we are. -- Bastien
Re: [O] mail integration, advice?
Matt Price writes: > - wl causes emacs to freeze up when it checks or sends mail, and can > take quite a long while to complete these operations I offload this by using external programs. My email flow consists of: 1. Fetch my mail from various sources with fetchmail. Usenet articles are fetched via leafnode. 2. The mail in then passed to procmail for spam proccessing with spamassassin, spilt into the appropriate groups with a procmailrc subfile generated by niko-bbdb-split.el[1], and delivered to the maildir directory using the "deliver" program from Dovecot. 3. I send my mail by passing it on the my local smtp server (postfix). 4. To easily access my mail from anywhere, I allow outside access to my local Dovecot server only through imaps. > - allow me to continue using Thunderbird as a backup for e.g. images > and highly formatted mails -- thunderbird is currently set up w/ local > copies of IMAP folders for my current mail, plus local archives served > on by dovecot that can be accessed both by thunderbird and by e.g. > wanderlust. I suggest just setting up a local imap server, such as Dovecot, for this. As a side note, I am happy with the presentation in Gnus via emacs-w3m integration for highly formatted mail (and of cause Emacs supports inline images). I can also open the mime part in a web browser From Gnus very easily. > - fast search and easy-to-manage virtual folders of some kind -- I see > mu and notmuch are very strong on both these fronts Currently I just use the Squat plugin[2] in Dovecot and search via "GG" in Gnus. Charles Footnotes: [1] http://www-verimag.imag.fr/~moy/emacs/niko-bbdb-split.el [2] http://wiki.dovecot.org/Plugins/FTS/Squat -- Running Windows on a Pentium is like having a brand new Porsche but only be able to drive backwards with the handbrake on. (Unknown source) pgpvdX2axarq3.pgp Description: PGP signature
Re: [O] missing autoloads / (void-variable org-version)
Hi Sébastien, "Sebastien Vauban" writes: > You think that everything related to the Test package would have been loaded > correctly. Not the case, "obviously"... More precisely: it has been _loaded_ correctly (i.e. it is in the load path), but the functions have been _autoloaded_ from a previous package. Looking for the package from the autoloaded function will point at the first matching package in load-path, which might not be the one from which functions have been autoloaded... Yep, it took me a while to understand it, so this email is a tribute to Achim's patience :) > Are we on the same wavelength? I think we are. -- Bastien
[O] filetags - at certain level
Would it be an easy enhancement to specify the level to apply certain filetags from the top org file meta data e.g #+FILETAGS: :crypt#2:private: In other words the more explicit equivalent would be something like * Banking ** Deutsche Bank Credit Card:crypt:visa: ** Maldives Platinum Card :crypt:visa: ** Barclays EC :crypt:ec: Why? So that only the second level entry contents are encrypted by default and not their titles : thus enabling tag search for the second levels. Or third or whatever. As it is applying a "saftey first" top level filetag of :crypt: means nothing below banking(first level) can be seem by the tag search. Thoughts? Or maybe its already possible?
Re: [O] missing autoloads / (void-variable org-version)
Achim Gratz writes: > Bastien writes: >> There is a fix that makes the new Makefile compatible with everyone's >> configuration *without* requiring to add the version number directly in >> the org.el file. I'm discussing it with Achim and will commit it as >> soon as possible. > > Towards that end, I can test Emacs23 and Emacs24 on Linux. Anyone still > using XEmacs and willing to check that everything keeps working there? Michael Sperber is our XEmacs fairy around, hopefully he we be able to test the patch. -- Bastien
Re: [O] mail integration, advice?
Matt, >> On Thu, 26 Apr 2012 09:47:40 -0400, Matt Price said: > So, I'm wondering what solutions other org users have settled on. I use gnus, offline imap, dovecot, notmuch, msmtp, bbdb3. And org-mode capture including links to emails works fine. The end result is very good and stable through updates (I am using Arch Linux too) but I have to say though it did take a LOT of configurating. Everything works well now apart from wrapping, see below: > My current hopes for this: - allow me to continue using Thunderbird > as a backup for e.g. images and highly formatted mails -- > thunderbird is currently set up w/ local copies of IMAP folders for > my current mail, plus local archives served on by dovecot that can > be accessed both by thunderbird and by e.g. wanderlust. - fast > search and easy-to-manage virtual folders of some kind -- I see mu > and notmuch are very strong on both these fronts - easy, stable > harvesting of email-based data through org-capture (if possible, > this should allow me to archive a message and still be able to find > it when I follow an org message link) - would be nice if QED Myles
Re: [O] do sh source blocks ignore args? [7.8.09]
Org-mode version 7.8.09
How could this be?
I ran it in a separate, minimally configured Emacs and got the good
behavior, so org-version must be lying somehow or else not all of the
functions were redefined when I upgraded. I thought a reload
uncompiled would take care of this. I'll restart emacs and try it
again. Thanks for the sanity check.
On Thu, Apr 26, 2012 at 1:59 PM, Eric Schulte wrote:
> Neil Best writes:
>
>> Can sh source block take arguments? I get nothing.
>>
>> #+NAME: test(foo="bar")
>> #+BEGIN_SRC sh :session :results output verbatim replace
>> echo "1. foo is $foo"
>> echo "2. foo is ${foo}"
>> #+END_SRC
>>
>> #+RESULTS:
>> : 1. foo is
>> : 2. foo is
>>
>>
>> . . . but this is fine:
>>
>> #+NAME: test2
>> #+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
>> replace
>> echo "1. foo is $foo"
>> echo "2. foo is ${foo}"
>> #+END_SRC
>>
>> #+RESULTS:
>> : 1. foo is bar
>> : 2. foo is bar
>>
>> When I tried this:
>>
>> #+CALL: test("baz")
>>
>> I get "reference 'test' not found in this buffer" -- what does this
>> mean? I got a similar message when I tried to define a simple call
>> using an R fragment that has a session associated with it. Evaluating
>> the code block with the default argument works fine, but a #+CALL:
>> construct fails. Maybe this is a separate issue.
>>
>> I trolled the web for relevant examples or reports but found none. My
>> setup is pretty much out-of-the-box. I am on Ubuntu Oneiric so sh is
>> a symlink to dash. I was not aware of dash until now so I don't know
>> what the implications of that are.
>>
>> This example may be overly trivial. My ultimate goal is to generate
>> shell scripts as function of the argument and tangle them out
>> something like this:
>>
>> #+BEGIN_SRC sh :tangle someArg.sh
>> <>
>> #+END_SRC
>>
>> So the results of the "function" will be lines of script code with
>> variables already interpolated using echo and a heredoc. Note that
>> test2 will not allow me to paramterize this, AFAIK. I'll have to
>> write each tangle block by hand but there's a small number of them.
>> If there is a more clever way I am certainly interested, but it seems
>> irrelevant until I understand what is happening above. Thanks. I am
>> very intrigued by LP possibilities using Org after messing with Sweave
>> for a year+, so please bear with me as I cut my teeth.
>>
>
> Hi Neil,
>
> Are you using the latest version of Org-mode? I ask because all of your
> examples work as expected on my system, specifically I get the
> following...
>
> Best,
>
> #+NAME: test(foo="bar")
> #+BEGIN_SRC sh :session :results output verbatim replace
> echo "1. foo is $foo"
> echo "2. foo is ${foo}"
> #+END_SRC
>
> #+RESULTS: test
> : 1. foo is bar
> : 2. foo is bar
>
> . . . but this is fine:
>
> #+NAME: test2
> #+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
> replace
> echo "1. foo is $foo"
> echo "2. foo is ${foo}"
> #+END_SRC
>
> #+RESULTS: test2
> : 1. foo is bar
> : 2. foo is bar
>
> #+RESULTS:
> : 1. foo is bar
> : 2. foo is bar
>
> When I tried this:
>
> #+CALL: test("baz")
>
> #+RESULTS: test("baz")
> : 1. foo is baz
> : 2. foo is baz
>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
Re: [O] do sh source blocks ignore args? [7.8.09]
Neil Best writes:
> Can sh source block take arguments? I get nothing.
>
> #+NAME: test(foo="bar")
> #+BEGIN_SRC sh :session :results output verbatim replace
> echo "1. foo is $foo"
> echo "2. foo is ${foo}"
> #+END_SRC
>
> #+RESULTS:
> : 1. foo is
> : 2. foo is
>
>
> . . . but this is fine:
>
> #+NAME: test2
> #+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
> replace
> echo "1. foo is $foo"
> echo "2. foo is ${foo}"
> #+END_SRC
>
> #+RESULTS:
> : 1. foo is bar
> : 2. foo is bar
>
> When I tried this:
>
> #+CALL: test("baz")
>
> I get "reference 'test' not found in this buffer" -- what does this
> mean? I got a similar message when I tried to define a simple call
> using an R fragment that has a session associated with it. Evaluating
> the code block with the default argument works fine, but a #+CALL:
> construct fails. Maybe this is a separate issue.
>
> I trolled the web for relevant examples or reports but found none. My
> setup is pretty much out-of-the-box. I am on Ubuntu Oneiric so sh is
> a symlink to dash. I was not aware of dash until now so I don't know
> what the implications of that are.
>
> This example may be overly trivial. My ultimate goal is to generate
> shell scripts as function of the argument and tangle them out
> something like this:
>
> #+BEGIN_SRC sh :tangle someArg.sh
> <>
> #+END_SRC
>
> So the results of the "function" will be lines of script code with
> variables already interpolated using echo and a heredoc. Note that
> test2 will not allow me to paramterize this, AFAIK. I'll have to
> write each tangle block by hand but there's a small number of them.
> If there is a more clever way I am certainly interested, but it seems
> irrelevant until I understand what is happening above. Thanks. I am
> very intrigued by LP possibilities using Org after messing with Sweave
> for a year+, so please bear with me as I cut my teeth.
>
Hi Neil,
Are you using the latest version of Org-mode? I ask because all of your
examples work as expected on my system, specifically I get the
following...
Best,
#+NAME: test(foo="bar")
#+BEGIN_SRC sh :session :results output verbatim replace
echo "1. foo is $foo"
echo "2. foo is ${foo}"
#+END_SRC
#+RESULTS: test
: 1. foo is bar
: 2. foo is bar
. . . but this is fine:
#+NAME: test2
#+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
replace
echo "1. foo is $foo"
echo "2. foo is ${foo}"
#+END_SRC
#+RESULTS: test2
: 1. foo is bar
: 2. foo is bar
#+RESULTS:
: 1. foo is bar
: 2. foo is bar
When I tried this:
#+CALL: test("baz")
#+RESULTS: test("baz")
: 1. foo is baz
: 2. foo is baz
--
Eric Schulte
http://cs.unm.edu/~eschulte/
[O] do sh source blocks ignore args? [7.8.09]
Can sh source block take arguments? I get nothing.
#+NAME: test(foo="bar")
#+BEGIN_SRC sh :session :results output verbatim replace
echo "1. foo is $foo"
echo "2. foo is ${foo}"
#+END_SRC
#+RESULTS:
: 1. foo is
: 2. foo is
. . . but this is fine:
#+NAME: test2
#+BEGIN_SRC sh :var foo="bar" :session :results output verbatim
replace
echo "1. foo is $foo"
echo "2. foo is ${foo}"
#+END_SRC
#+RESULTS:
: 1. foo is bar
: 2. foo is bar
When I tried this:
#+CALL: test("baz")
I get "reference 'test' not found in this buffer" -- what does this
mean? I got a similar message when I tried to define a simple call
using an R fragment that has a session associated with it. Evaluating
the code block with the default argument works fine, but a #+CALL:
construct fails. Maybe this is a separate issue.
I trolled the web for relevant examples or reports but found none. My
setup is pretty much out-of-the-box. I am on Ubuntu Oneiric so sh is
a symlink to dash. I was not aware of dash until now so I don't know
what the implications of that are.
This example may be overly trivial. My ultimate goal is to generate
shell scripts as function of the argument and tangle them out
something like this:
#+BEGIN_SRC sh :tangle someArg.sh
<>
#+END_SRC
So the results of the "function" will be lines of script code with
variables already interpolated using echo and a heredoc. Note that
test2 will not allow me to paramterize this, AFAIK. I'll have to
write each tangle block by hand but there's a small number of them.
If there is a more clever way I am certainly interested, but it seems
irrelevant until I understand what is happening above. Thanks. I am
very intrigued by LP possibilities using Org after messing with Sweave
for a year+, so please bear with me as I cut my teeth.
Re: [O] mail integration, advice?
On Thu, 26 Apr 2012 09:47:40 -0400, Matt Price wrote: > I'd like to take one more shot at returning to text-based email within > emacs, mostly because I want to be able to integrate mail easily into > my org-mode workflow. The last time I tried this I used wanderlust, > and I'd be willing to give it a try again but a couple of things have > discouraged me in the past: > - wl causes emacs to freeze up when it checks or sends mail, and can > take quite a long while to complete these operations I fetch emails with offlineimap - it seems to use a lot of bandwith/time/cpu and I heard that mbsync might be better - nevertheless it does it's job. The emails are placed into a maildir and indexed and tagged with notmuch via a post sync hook. I'm very happy with emacs + org-mode + notmuch, creating tasks from email that link back to the email being one of the small but great things. > - wl seems to have gone quasi-dormant, with very little activity on > the mailing list and no recent releases; it also relies on two other > packages, FLIM and APEL, with similarly dormant mailing lists > > So, I'm wondering what solutions other org users have settled on. My > current hopes for this: > - allow me to continue using Thunderbird as a backup for e.g. images > and highly formatted mails -- thunderbird is currently set up w/ local > copies of IMAP folders for my current mail, plus local archives served > on by dovecot that can be accessed both by thunderbird and by e.g. > wanderlust. you could index the thunderbird folders with notmuch, but I don't know how it will behave if you move or delete messages. > - fast search and easy-to-manage virtual folders of some kind -- I see > mu and notmuch are very strong on both these fronts notmuch searches are very fast, but the database takes disk space. Indexing in recent versions is very very quick. mail: 7.4GB notmuch db: 3.6GB > - easy, stable harvesting of email-based data through org-capture (if > possible, this should allow me to archive a message and still be able > to find it when I follow an org message link) notmuch solely works with tags: something is in your inbox, if it has the inbox tag. If notmuch starts to support moving messages to folder and giving them implicit tags, the link would still be through notmuch and not to a specific file. Maybe notmuch supports this already, I did not have the time to investigate. > - would be nice if configuration didn't require TONS of lisp code, a I > am a very slow coder and these kinds of configuration tasks can be > very daunting for me. close to zero configuration needed and full "GUI" support through emacs customize. > - shouldn't slow down my workflow too much -- I should be able to very > quickly check my email then return to an org buffer to continue > writing. It actually sped up my workflow massively and was together with org-mode the number one reason to switch to emacs, after very very long years of using vi derivates. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpenA2eORpH6.pgp Description: PGP signature
Re: [O] Ever used org-mode contrib packages?
On Wed, Apr 11 2012, François Allisson wrote: > I'm curious to know what you are using from org-contrib... - org-notify -- Peter
Re: [O] missing autoloads / (void-variable org-version)
Hi Achim, Achim Gratz wrote: > Sebastien Vauban writes: >> Here, I would have thought that invoking the function `text-aux' would open >> the "production" Lisp file (that is, the one in Emacs code base) as you use >> Emacs loaddefs.el associations, no? > > It could be set up that way, but isn't. You wouldn't be able to move an > installed emacs tree if that were the case, and it could quite likely > break in other mysterious ways. I think you did not understand what I meant, or the opposite. Whatever, this presentation is not the most important thing. What you're trying to achieve *is*. First things first... To come back to what I understood from your text: 1. you have `test.el' in, let's say, `c:/Program Files/Emacs-24.0/lisp/test-mode' 2. the autoload definition for the function `test-aux' is in `c:/Program Files/Emacs-24.0/lisp' 3. you have latest Test package (dev version) in, let's say, `c:/home/sva/src/test-mode', with 2 files in there: + `test.el' + `test-aux.el' 4. you add `c:/home/sva/src/test-mode' *in front of* your `load-path' list 5. you, then, require `test.el' in your Emacs startup file; it loads the dev version (that is, `c:/home/sva/src/test-mode/test.el') 6. you, then, invoke the command `test-aux'. As the autoload says that, for getting the definition of that function, you need to load the file `test-aux.el', Emacs searches for that file, and finds the first occurrence in version `c:/home/sva/src/test-mode/test-aux.el' Here, due to a too quick reflexion, I thought that Emacs would load the base version in `c:/Program Files/Emacs-24.0/lisp/test-mode/test-aux.el'. But that's _not_ true, as: - only file names are given in `loaddefs.el', not full paths - the dev version directory has been placed first in `load-path'. So, I was wrong about my comment... Sorry for the noise. However, a problem that has bitten me twice already is that, in the above case, I would have this in my Emacs startup file: #+begin_src emacs-lisp (require 'xyz-package) ;; this one requires `test.el' but you don't see/know it ... ... ... (add-to-list 'load-path "c:/home/sva/src/test-mode") ;; before use of Test package (require 'test) ;; no-op in this case (test-aux) #+end_src You end up in mixed versions of the different functions. Typically the case where Org version looks like: Org-mode version 7.7 (release_7.8.09-400-g4a0e5b) But, when having a look at the value of `load-path', everything seems correct: you dev version is in front of your Emacs core version. You think that everything related to the Test package would have been loaded correctly. Not the case, "obviously"... Are we on the same wavelength? >> I've experienced enough couple of hours lost in the past, searching for >> problems due to mixed versions loaded, to know what the correct answer is. > > ...so, I count that as a "yes, fix it please"? Yep! I consider important that you fix things which you consider as flaws or broken pieces. Best regards, Seb -- Sebastien Vauban
Re: [O] missing autoloads / (void-variable org-version)
Bastien writes: > There is a fix that makes the new Makefile compatible with everyone's > configuration *without* requiring to add the version number directly in > the org.el file. I'm discussing it with Achim and will commit it as > soon as possible. Towards that end, I can test Emacs23 and Emacs24 on Linux. Anyone still using XEmacs and willing to check that everything keeps working there? It's pretty difficult to even check the documentation for it when you don't have it installed... and there are certainly differences in some areas we'd need to poke around in that even I know. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Fast linking to files in private git repos through a hyperlink
I imagine git allows a lot of opportunities for more features that we would want in such a link. Perhaps a more general, flexible, lispy keyword-style syntax would be useful here? Or handle with different link types and shunt off to a git call? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Fast linking to files in private git repos through a hyperlink
Thanks for your suggestion Bastien, but unfortunately it does not directly map to the shortcut that I implemented in my package. In my *old* syntax: git:repo::file.txt file.txt is a search pattern for a *file* with in the symbolic repo "repo" which maps to a real repo through the hash variable my-org-repos. The whole idea was that I wanted to be able to use the symbolic name as a shortcut. In addition file.txt is not the path of a file in the repo, but a search pattern for a file in the repo. In case of duplicates the user is prompted to interactively resolve the file. In addition I would also like to add a search pattern for a string in the file. My problem is how to merge this syntax with the org-git-link.el which uses the syntax git:/home/user/repo/data/results.png::nobelprize where /home/.../results.png is the name of the path to a file and nobelprize is the name of a tag. Both my linking and the org-git-linking are two different equally valid use cases. My problem is how to merge both these use cases under a single syntax. Regards, Dov On Thu, Apr 26, 2012 at 17:00, Bastien wrote: > Hi Dov, > > Dov Grobgeld writes: > > > Thanks for the link. I wasn't aware of that package. I see that I > > have a conflict in syntax as I used double colon for indicating the > > git repo while org-git-link.el used double colon for search pattern. > > The double colon is standard in Org for indicating the search pattern, > please use it this way too. > > > Thus to join the packages I need to change the syntax. Which of the > > following would make more sense: > > > >git:@repo:file-in-repo::pattern-in-file > >git://repo/file-in-repo::pattern-in-file > > > > or perhaps some other syntax? Suggestions? > > git:[user@?][repo-server]:[git-repo-itself]::[search-pattern] > > When user is set, the repo-server URL won't have a protocol > (git will be used by default as a protocol.) > > When user is not set, the repo-server may contain git:// or > http:// as the protocol. > > But I didn't test your packing, so I'm maybe shooting in the > dark for this syntax suggestion. > > HTH, > > -- > Bastien >
Re: [O] mail integration, advice?
Rasmus writes: >> (if possible, this should allow me to archive a message and still be >> able to find it when I follow an org message link) > > You can capture gnus mails through org-capture. I don't know how > robust the links are. The links are saved by combining the group and Message-Id of the mail. So if Matt means "move a message to some archive group" with archiving a message, the links will be broken. But there's `gnus-summary-article-move-hook' that could be used to track article movements and update links. Bye, Tassilo
Re: [O] error on opening org-file with #+startup: indent
Bastien gnu.org> writes: > > fkunze gmail.com> writes: > > > Augment the installation description > > (http://orgmode.org/manual/Installation.html#Installation) with a short > > description for windows users (that avoids the use of make). > > I'm not using Windows myself, but I would welcome a patch that clarifies > the installation process for Windows. > > Anyone? > Hi Bastien, At the risk of redundancy (as I posted this paragraph earlier) the people at the python sphinx documentation project have a similar problem (of producing a "make" for windows) and it might be possible to rapidly develop a make.bat file for org-mode installations by making modifications of their "make.bat" source file: https://trac.jmodelica.org/assimulo/browser/trunk/doc/sphinx/make.bat I am too far removed from the intricacies of mapping the unix make options to something that will work on windows - to produce something of real value in a reasonable time period. But I do have a friend who might be able to rapidly develop an appropriate mapping. Let me see if I can interest him in satisfying your request.
Re: [O] missing autoloads / (void-variable org-version)
Hi all, thanks Achim for this lengthy post, it's definitely worth reading for anyone who got confused by autoloading stuff once in his life (I did, who didn't?) Now, I should have warned the mailing list about possible breakage in people's configuration, I apologize for this. There is a fix that makes the new Makefile compatible with everyone's configuration *without* requiring to add the version number directly in the org.el file. I'm discussing it with Achim and will commit it as soon as possible. "Breaking" a broken configuration is definitely not a bug, especially when this comes with a conceptually clean approach -- which is precisely the point of Achim's work. Still, a missing org-version should not prevent the whole Org spaceship to take off... so, let's bare with us a little bit. Thanks! -- Bastien
[O] thanks
Hi guys, I just wanted to thank you all for the great work!I'm a theoretical physicist and I regularly use org-mode for almost every aspect of my research.All the best,Domenico Orlando-- Domenico Orlando, CERN Fellow Theory division phone: +41 22 767 29 59
Re: [O] mail integration, advice?
Matt Price writes: > I'd like to take one more shot at returning to text-based email within > emacs, mostly because I want to be able to integrate mail easily into > my org-mode workflow. It's worth it. > The last time I tried this I used wanderlust, > and I'd be willing to give it a try again but a couple of things have > discouraged me in the past: I used wl but switched to Gnus. > - wl causes emacs to freeze up when it checks or sends mail, and can > take quite a long while to complete these operations I know of no solution to this. You could run a dedicated Gnus process if it bothers you. > - wl seems to have gone quasi-dormant, with very little activity on > the mailing list and no recent releases; it also relies on two other > packages, FLIM and APEL, with similarly dormant mailing lists Arch updates wl often. Latest package is three months old. https://www.archlinux.org/packages/community/any/wanderlust/ > - allow me to continue using Thunderbird as a backup for e.g. images > and highly formatted mails -- thunderbird is currently set up w/ local > copies of IMAP folders for my current mail, plus local archives served > on by dovecot that can be accessed both by thunderbird and by e.g. > wanderlust. Message-mode handles txt mails well. There is some org extension for html mails (although I don't like html mails). IMAP should be fine. You can run it local if you want. I do offlineimap + dovecot. > - fast search and easy-to-manage virtual folders of some kind -- I see > mu and notmuch are very strong on both these fronts notmuch and mu4emacs are probably also easier to set up. > - easy, stable harvesting of email-based data through org-capture Use bbdb3. > (if possible, this should allow me to archive a message and still be > able to find it when I follow an org message link) You can capture gnus mails through org-capture. I don't know how robust the links are. > - would be nice if configuration didn't require TONS of lisp code, a I > am a very slow coder and these kinds of configuration tasks can be > very daunting for me. I have tons of list configuration for Gnus. . . But half of it is for weird stuff such as random signature, random `avatar', several SMTP etc. > - shouldn't slow down my workflow too much -- I should be able to very > quickly check my email then return to an org buffer to continue > writing. I have F9 bring up the Gnus Group buffer. G for update. Elegant auto-fetching of new mails from foreign imap is something I have not solved yet. -- Enought with the bla bla!
Re: [O] missing autoloads / (void-variable org-version)
Martyn Jago writes: > As an aside, I haven't used MS windows for some two years (using OS X > and Linux), but this will change shortly as my next project will require > a working Windows system with MSys. I could certainly document the setup > of Org-mode including functioning tests etc. on a line-by-line basis if > it will help. This simply works with minimal setup which I already posted here. If you want to go with MSys, consider using the MSys-Git netinstall version, since it comes with all the development tools you need. The standalone Git for Windows doesn't have make and some other stuff you need for the documentation. If you're serious about working on Windows you should probably just install Cygwin. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] mail integration, advice?
Tassilo Horn writes: > If you talk to an IMAP or Gmane nntp server (remote or a local dovecot), > you can simply hit `G G' on a group to search it without having to > configure anything (in recent Gnus versions). Almost all IMAP servers > index at least to/from/subject for fast searches, and some also have > fulltext search plugins (e.g., dovecot has one). Yeah, the one "problem" I have with Gnus is that it does so damn much, I have trouble remembering it all. But seriously, good to know, and thanks for saving me some work.
Re: [O] missing autoloads / (void-variable org-version)
Sebastien Vauban writes: > Here, I would have thought that invoking the function `text-aux' would open > the "production" Lisp file (that is, the one in Emacs code base) as you use > Emacs loaddefs.el associations, no? It could be set up that way, but isn't. You wouldn't be able to move an installed emacs tree if that were the case, and it could quite likely break in other mysterious ways. > I've experienced enough couple of hours lost in the past, searching for > problems due to mixed versions loaded, to know what the correct answer is. ...so, I count that as a "yes, fix it please"? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] mail integration, advice?
Carson Chittom writes: >> - fast search and easy-to-manage virtual folders of some kind -- I >> see mu and notmuch are very strong on both these fronts > > I'm looking to set up mairix, which Gnus supports, but I haven't yet. > Mairix itself though just needs mail in Maildir or mbox formats, from > what I understand. If you talk to an IMAP or Gmane nntp server (remote or a local dovecot), you can simply hit `G G' on a group to search it without having to configure anything (in recent Gnus versions). Almost all IMAP servers index at least to/from/subject for fast searches, and some also have fulltext search plugins (e.g., dovecot has one). Bye, Tassilo
Re: [O] [babel] hide inline source code blocks by results
Eric Fraga writes:
> Eric Schulte writes:
>
>> Currently inline blocks like don't associate themselves with their
>> results, they are only expected to be evaluated on export, so the
>> functionality you suggest below would require first changing how results
>> are associated with inline code blocks.
>>
>> Another option would be to hide everything but the body of the block,
>> but this may be more confusing than it is worth.
>
> Eric,
>
> I do like what Torsten suggested a lot. I wonder if a halfway solution
> would be possible. Define a babel: link type which includes the src_xxx
> code and let the description part of the link be whatever the author
> wants it to be. I wouldn't mind not knowing the result of the code
> execution as I don't know that at the moment anyway.
>
> So, something like this would be nice:
>
> ... and the result is [[babel:src_octave{3*x+5}][f(x)]] which
> demonstrates ...
>
> which would look like
>
> ... and the result is f(x) which demonstrates ...
>
> (with f(x) highlighted as a link).
>
> Could something like this be possible?
>
> And, to take this further, could the highlighting differ depending on
> link type? I've not explored this latter aspect so maybe it's already
> possible...
>
I think both this and Torsten's original idea would both be nice
options. Preferably the final solution would subsume either use case.
Unfortunately either implementation would require a fairly significant
amount of work on the inline source block system, work which I
unfortunately do not have time for at the moment (although I'm happy to
help if anyone else wants to jump into the code).
Thanks,
>
> thanks,
> eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
[O] Bug: org-latex-to-pdf-process with bibtex fails to produce bibtex (workaround included) [7.8.03]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
Dear org-hackers,
When I use org-export-as-pdf with the option to use bibtex in-between
(for reftex-mode), bibtex fails to produce the bibliography.
The non-working config is as follows:
'(org-latex-to-pdf-process (quote ("pdflatex -interaction nonstopmode
-output-directory %o %f" "bibtex %b" "pdflatex -interaction nonstopmode
-output-directory %o %f" "pdflatex -interaction nonstopmode
-output-directory %o %f")))
I could trace it down to this:
bibtex /abspath/to/file-without-ext # == %b
bibtex: Not writing to
/abspath/to/file-without-ext.blg (openout_any =
p).
I couldn't open file name
`/abspath/to/file-without-ext.blg'
To fix it, I just had to make sure that bibtex only gets the filename:
'(org-latex-to-pdf-process (quote ("pdflatex -interaction nonstopmode
-output-directory %o %f" "bibtex $(basename %b)" "pdflatex -interaction
nonstopmode -output-directory %o %f" "pdflatex -interaction nonstopmode
-output-directory %o %f")))
Best wishes and happy hacking!,
Arne
Emacs : GNU Emacs 23.4.2 (x86_64-pc-linux-gnu, GTK+ Version 2.24.8)
of 2012-04-10 on fluss
Package: Org-mode version 7.8.03
Re: [O] [PATCH] Support hour in repeated task cookie
Hi, Bastien Thanks for the patch and I am sorry for this late reply (especially because I pushed maintainers to review my patch before...). Anyway, I tried the head of master (580add2f4148fea949a4db5550577911ee6d756e) and it works fine for me. But I couldn't reproduce this behavior: > Note that timestamps need to be well formatted. If there is > a +3d repeat cookie and the original timestamp doesn have any > indication for the hour, it will produce an error. (BTW, you mean +3h, right?) There is no change in the SCHEDULE time stamp, but I've got state change log and LAST_REPEAT in PROPERTIES. Note that I have `(setq org-log-into-drawer t)' in my configuration. Resulting tree was something like this (I changed the state to DONE three times): * TODO Test SCHEDULED: <2012-04-26 Thu +3h> :LOGBOOK: - State "DONE" from "TODO"[2012-04-26 Thu 16:16] - State "DONE" from "TODO"[2012-04-26 Thu 16:16] - State "DONE" from "TODO"[2012-04-26 Thu 16:16] :END: :PROPERTIES: :LAST_REPEAT: [2012-04-26 Thu 16:16] :END: Regarding not using constant for "dwmy". > I didn't replace "dwmy" by a constant though, this is not expected > to change anymore. I think somebody may want to have minute cookie. And in that case, repeating the same task is tiresome. I didn't put minute in my patch simply because I didn't know what letter I should use. I guess no one wants second or century though. So maybe we should decide what letter to use for minute and change "dwmy" again, if you don't like the constant solution? -- Takafumi
Re: [O] mail integration, advice?
Matt Price writes: > I'd like to take one more shot at returning to text-based email within > emacs, mostly because I want to be able to integrate mail easily into > my org-mode workflow. The last time I tried this I used wanderlust, > and I'd be willing to give it a try again but a couple of things have > discouraged me in the past: I'm in a somewhat similar situation (although in my case it's actually the reverse: I want to be able to integrate org-mode into my mail workflow). > - wl causes emacs to freeze up when it checks or sends mail, and can > take quite a long while to complete these operations I'm using Gnus, not Wanderlust, but it has the same problem, of course (my understanding is that it's actually Emacs which has the problem). In addition, I check my mail by logging in (via SSH) to my personal machine at home, which has a low-bandwidth DSL connection, so any slowness is magnified. I've dealt with it by simply running a local IMAP server--Dovecot, in my case, though I hear lots of people have good results using just offlineimap--and using fetchmail to pull from my ISP's mailserver. My project for the weekend is to set up Dovecot's Sieve support (Pigeonhole) to mirror my previous filtering rules. > - wl seems to have gone quasi-dormant, with very little activity on > the mailing list and no recent releases; it also relies on two other > packages, FLIM and APEL, with similarly dormant mailing lists Gnus is currently under heavy development and only requires a recent (22, 23, 24) Emacs. Not trying to "convert" you, but you did bring it up. :) > - fast search and easy-to-manage virtual folders of some kind -- I see > mu and notmuch are very strong on both these fronts I'm looking to set up mairix, which Gnus supports, but I haven't yet. Mairix itself though just needs mail in Maildir or mbox formats, from what I understand. I hope that was helpful--probably not, though. :)
Re: [O] Ever used org-mode contrib packages?
On 12-Apr-11, at 3:22 PM, François Allisson wrote: > I'm curious to know what you are using from org-contrib... I use org-babel, org-drill, and org-mac-link-grabber extensively. -Anthony
Re: [O] Fast linking to files in private git repos through a hyperlink
Hi Dov, Dov Grobgeld writes: > Thanks for the link. I wasn't aware of that package. I see that I > have a conflict in syntax as I used double colon for indicating the > git repo while org-git-link.el used double colon for search pattern. The double colon is standard in Org for indicating the search pattern, please use it this way too. > Thus to join the packages I need to change the syntax. Which of the > following would make more sense: > > git:@repo:file-in-repo::pattern-in-file > git://repo/file-in-repo::pattern-in-file > > or perhaps some other syntax? Suggestions? git:[user@?][repo-server]:[git-repo-itself]::[search-pattern] When user is set, the repo-server URL won't have a protocol (git will be used by default as a protocol.) When user is not set, the repo-server may contain git:// or http:// as the protocol. But I didn't test your packing, so I'm maybe shooting in the dark for this syntax suggestion. HTH, -- Bastien
Re: [O] Small grammar tweaks in export sections of org.texi
Hi Brian, Brian van den Broek writes: > a) the limit is cumulative over all patches, It makes sense. > b) trivial changes like replacing many instances of a > name do not count, but multiple such sorts of changes "can" and c) the > standard they presently endorse is >15 lines. (Sadly, the document I > linked to is a model of neither clarity nor precision.) Yes -- that's actually what's on http://orgmode.org/worg/org-contribute.html >> 1. try to figure out what really prevents you from assigning your >> copyright to FSF (unless your job contract says "everything you write >> in your free time belongs to us", I don't see a real problem here, but >> of course I don't have all the cards in hands to judge appropriately.) > > I don't think my employer (I teach Philosophy at the College-level) > has a basis to claim ownership of copyright on my work product, but I > also seem to have misplaced my law degree :-) I thus cannot > confidently say that it is false that I "have an employer who *might* > have a basis" to claim ownership of my changes. > > I've written the relevant gnu.org address seeking clarification as to > whether my good faith belief suffices in my circumstances. Okay let us know. You might get a faster reply by Cc'ing me as the maintainer. Also, perhaps your College administration will be faster that GNU ones -- but chances are that both will be slow anyway. In the meantime, don't hesitate to report problems informally on the list! Thanks, -- Bastien
[O] mail integration, advice?
I'd like to take one more shot at returning to text-based email within emacs, mostly because I want to be able to integrate mail easily into my org-mode workflow. The last time I tried this I used wanderlust, and I'd be willing to give it a try again but a couple of things have discouraged me in the past: - wl causes emacs to freeze up when it checks or sends mail, and can take quite a long while to complete these operations - wl seems to have gone quasi-dormant, with very little activity on the mailing list and no recent releases; it also relies on two other packages, FLIM and APEL, with similarly dormant mailing lists So, I'm wondering what solutions other org users have settled on. My current hopes for this: - allow me to continue using Thunderbird as a backup for e.g. images and highly formatted mails -- thunderbird is currently set up w/ local copies of IMAP folders for my current mail, plus local archives served on by dovecot that can be accessed both by thunderbird and by e.g. wanderlust. - fast search and easy-to-manage virtual folders of some kind -- I see mu and notmuch are very strong on both these fronts - easy, stable harvesting of email-based data through org-capture (if possible, this should allow me to archive a message and still be able to find it when I follow an org message link) - would be nice if configuration didn't require TONS of lisp code, a I am a very slow coder and these kinds of configuration tasks can be very daunting for me. - shouldn't slow down my workflow too much -- I should be able to very quickly check my email then return to an org buffer to continue writing. Thanks very much for your suggestions! best, matt
Re: [O] Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
Hi Eric, Eric Abrahamsen writes: > if I revisited nested todos, I would just write it on top of > org-element, rather than the existing org-agenda code. Eventually! Great. Let's keep the future open then :) -- Bastien
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
Toby Cubitt writes: > On Thu, Apr 26, 2012 at 10:59:50AM +0200, Bastien wrote: >> Hi Matt, >> >> Matt Lundin writes: >> >> > Note: It seems that adding the optional argument KEEPDATE is necessary >> > for parsing to work. With the following line instead of the one above >> > org-read-date works as expected: >> > >> > (org-eval-in-calendar '(setq cursor-type nil) t) >> >> that's right -- I pushed this fix to master. Thanks for reporting this >> and for detailing the solution! > > Thanks for the fix! > > What exactly does KEEPDATE argument do? The `org-eval-in-calendar' > docstring doesn't mention it anywhere, which is probably why I missed it > in my patch. Looking at the code, it seems that the part about storing > the cursor date in org-ans2 only happens for a non-nil KEEPDATE? When keepdate is nil (which is the default), org-ans2 is updated wrt the cursor date. At the time we set the cursor-type, we don't want to override org-ans2, we want to stick to the value already set. > I'd post an update to improve the `org-eval-in-calendar' docstring, but I > don't feel like I really understand what the KEEPDATE argument does well > enough. I just fixed the docstring like this: "Eval FORM in the calendar window and return to current window. When KEEPDATE is non-nil, update `org-ans2' from the cursor date, otherwise stick to the current value of `org-ans2'." Thanks! -- Bastien
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
On Thu, Apr 26, 2012 at 10:59:50AM +0200, Bastien wrote: > Hi Matt, > > Matt Lundin writes: > > > Note: It seems that adding the optional argument KEEPDATE is necessary > > for parsing to work. With the following line instead of the one above > > org-read-date works as expected: > > > > (org-eval-in-calendar '(setq cursor-type nil) t) > > that's right -- I pushed this fix to master. Thanks for reporting this > and for detailing the solution! Thanks for the fix! What exactly does KEEPDATE argument do? The `org-eval-in-calendar' docstring doesn't mention it anywhere, which is probably why I missed it in my patch. Looking at the code, it seems that the part about storing the cursor date in org-ans2 only happens for a non-nil KEEPDATE? I'd post an update to improve the `org-eval-in-calendar' docstring, but I don't feel like I really understand what the KEEPDATE argument does well enough. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [bug] new exporter fails on read only files
Hi Eric, Eric Fraga writes: > Specifically, I have added > >(require 'org-export) >(require 'org-e-latex) > > to my org customisation. Then, while visiting a read only file, I try > >M-x org-export-dispatch RET p Mhh.. I can't reproduce this error with latest Org. > and I get the error: > > , > | org-refresh-category-properties: Buffer is read-only: # > ` Maybe you have a hook which call this function? In any case, as the other place where `org-refresh-category-properties' is called is `org-prepare-agenda-buffers' and those buffers might be read-only (for some obscure reason), I pushed a fix that make sure `org-refresh-category-properties' can modify the buffer correctly. Please let me know if this fixes your problem. -- Bastien
[O] [bug] new exporter fails on read only files
Hello all, >From one of the recent threads (on producing latex files for ACM publications), I was finally motivated to try the new export engine. I have run into a small problem: org-export-dispatch fails if the file is read only. I often have read only files as I use RCS as my version control system for one-off standalone files (as opposed to git or mercurial for larger projects). Specifically, I have added (require 'org-export) (require 'org-e-latex) to my org customisation. Then, while visiting a read only file, I try M-x org-export-dispatch RET p and I get the error: , | org-refresh-category-properties: Buffer is read-only: # ` This doesn't happen if I use the old exporter (C-c C-e p). Also, the error does not appear if I try the new export engine on a writable file. Toggling debug-on-error doesn't actually put me in the debugger when the error occurs, by the way. I *think* am running an up to date org (from an hour or so ago) but the org-version information (auto-generated for my signature) seems confused... but maybe that's a problem for another day? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.09.392.ge0222)
Re: [O] Org tasks from gnus
Rémi Vanicat writes:
> Kyle Sexton writes:
>
>> Does anyone know a way to automatically create/link org-tasks from Gnus
>> messages? My current workflow is to just start a new capture and type
>> in or paste some of the relevant info, but if org could link to the
>> message that would be ideal.
>
> I've the following recipe in my org-capture-template:
>
> ("m" "mailnote" entry (file+headline "~/org/notes.org" "Notes")
> "** From: %:from Subject: %:subject\n %a" :kill-buffer t)
>
> So when I do `C-c r m` it create a note with a link to the relevant gnus
> message. Look at http://orgmode.org/manual/Template-expansion.html for
> other %:something.
Thanks for this. Very useful. I didn't know about the %:from
etc. keywords.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.09.392.ge0222)
Re: [O] missing autoloads / (void-variable org-version)
Hi Achim Achim Gratz writes: > Since my Makefile branch was merged I've been getting flak for breaking > certain setups. Now, the change didn't actually break them, but I did > make (perhaps foolishly) a deliberate decision to make that particular > breakage fatal rather than silent. It would be very easy to continue to > paper over the breakage and pretend things are working when they're not. > What irritates me greatly is that quite a few of the people that insist > on this "solution" are the ones who would have to deal with the > Heisenbugs thus introduced. So let me explain once more what is broken: > [...] Thanks for this post - it has certainly helped me see the `rock' and the `hard place'. As an aside, I haven't used MS windows for some two years (using OS X and Linux), but this will change shortly as my next project will require a working Windows system with MSys. I could certainly document the setup of Org-mode including functioning tests etc. on a line-by-line basis if it will help. Best, Martyn > > Regards, > Achim.
Re: [O] missing autoloads / (void-variable org-version)
> Since my Makefile branch was merged I've been getting flak for breaking > certain setups. Now, the change didn't actually break them, but I did > make (perhaps foolishly) a deliberate decision to make that particular > breakage fatal rather than silent. It would be very easy to continue to > paper over the breakage and pretend things are working when they're not. > What irritates me greatly is that quite a few of the people that insist > on this "solution" are the ones who would have to deal with the > Heisenbugs thus introduced. So let me explain once more what is broken: > Hmm. I was biten by the makefile change but hopefully my report didn't count as "flak". I have absolutely no problem with any reasonable change in the makefile. But your description of the situation before and after the makefile change is not entirely correct. Before: May be I had a broken setup and didn't know. Nevertheless it worked. After: May be conceptually your new makefile improved the build process. But now my setup was broken. ;-) And here comes the moment when you just wanted to do some routine work, namely publish some notes for the upcoming lecture, normally a one minute job, well set-up and tested. And all you get is some error. Time is ticking away, next org-mode scheduled APPT in 5 min. We all know this. My guess: It was too easy to miss that action was required on a user's side. May be a hint that make targets changed and that under some circumstances make update could fail and a hint with some exclamation marks that batch exporting now requires --load org-install.el and not only --load org.el would have reduced mail traffic a lot. If there was such a note at least I missed it. Definitely keep up your work and improve the build process! I'm happy to change my scripts if I know I need to and better still if I understand why I should! (Thx for your explanation!) Detlef
Re: [O] Disable links in Latex export
On Thu, Apr 26, 2012 at 3:51 AM, Eric Fraga wrote:
> Nick Dokos writes:
>
>
> [...]
>
>> If all you care about is the *appearance*, rather than the existence of
>> links, however, you can use hyperref package options to influence
>> that. For example
>>
>> \usepackage[pdfborder={0,0,0}]{hyperref}
>>
>> will get rid of the red boxes around the links in the TOC: they are
>> still links, they are just not that obvious any more. You can do that
>> by customizing the org-export-latex-default-packages-alist variable:
>> just add the above option (without the square brackets) to the hyperref
>> package entry.
>
> adding the line
>
> #+latex_header: \hypersetup{pdfborder={0,0,0}}
>
> in the org document should be sufficient?
>
> In practice, I actually do:
>
> #+latex_header: \hypersetup{colorlinks=true}
And red isn't my cup of tea, so I use:
#+LATEX_HEADER: \hypersetup{colorlinks=true,urlcolor=blue}
>
> which still colours the links but gets rid of the ugly boxes.
>
> --
> : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
> : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
>
>
Re: [O] org-mode and google calendar
> https://github.com/kiwanami/emacs-calfw Thank you for this hint. org-mode was mentioned in a german linux magazine article with topic calfw - should help to popularize org-mode. http://www.linux-magazin.de/NEWS/Emacs-Calfw-1.0-zeigt-Google-und-Org-Kalender
Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?
Hi James,
James Harkins wrote:
> At Thu, 26 Apr 2012 17:44:56 +0930,
> Eric Fraga wrote:
>> > But I still have the issue with it
>> > that the user has to adapt the org-file structure to suit beamer's
>> > requirements. Org-mode is all about reflecting the content in a way
>> > that makes sense FIRST to humans, and only secondarily to exporting
>> > engines.
>>
>> I agree. However, the problems arise when exporting because of
>> fundamentally different structures between org and the export
>> target. This is why we have the various kludges (if people can forgive
>> me for calling them this) like ATTR_HTML and ATTR_LATEX. There is no
>> easy or elegant mechanism in org for satisfying all the different export
>> target requirements that are fundamentally inconsistent with org's
>> outline heritage.
>
> I understand. An elegant solution would take some mulling over (especially
> considering that I've only recently started using the export features, and my
> knowledge of LaTeX is superficial at best). In the meantime, I can live with
> the current situation.
>
> That the headline title is used for the color specification is probably not
> such an unbearable thing in practice. How many color boxes are there likely to
> be on one slide? (Meaning, if you're tempted to load up a slide with so many
> color boxes that you get confused about the content, maybe the content needs
> to be restructured.) If it's the only color box on the slide, quite likely you
> can infer its content from the frame title or other headings nearby.
>
> It just struck me as a loose end, and I'm glad I asked about it, because I
> have a better understanding of the issues now.
>
>> For this particular case, it could be that the beamercolorbox
>> environment could be made to expect a specific PROPERTY, much like the
>> column environment does. The question would then be: what should the
>> headline be used for as beamercolorbox has no real text content
>> argument.
>
> There are other beamer tags that don't use the headline text, namely quote and
> quotation. According to the beamer user guide, there's no place for the
> headline:
>
> \begin{quote}
> environment contents
> \end{quote}
>
> Compared to
>
> \begin{block}{block title}
> environment contents
> \end{block}
>
> So, there is already a situation where you have to put some dummy text into
> the headline that won't appear.
And, in Org-Beamer, you have the explicit tag `b_ignore' as well, to ignore
the entry title, using the contents only.
> Maybe there could be special handling for title-less environments, so that
> the headline would become the environment contents and colorbox could take
> its color from a property...
I don't find that a particularly attractive option, since you would end up
with very long headlines (often more than 80 characters) and you would not be
able to have multiline (or multiparagraph) contents.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] missing autoloads / (void-variable org-version)
Hi Achim, Achim Gratz wrote: > Since my Makefile branch was merged I've been getting flak for breaking > certain setups. Now, the change didn't actually break them, but I did > make (perhaps foolishly) a deliberate decision to make that particular > breakage fatal rather than silent. It would be very easy to continue to > paper over the breakage and pretend things are working when they're not. > What irritates me greatly is that quite a few of the people that insist > on this "solution" are the ones who would have to deal with the > Heisenbugs thus introduced. So let me explain once more what is broken: Did not know that term... Thanks. http://en.wikipedia.org/wiki/Heisenbug > Consider a core emacs library "test", consisting of the main "test.el" > and auxiliary functions in "test-aux.el". The main entry points are in > "test.el" and thus you'd "(require 'test)" in your .emacs to activate > the package. The auxiliary functions are not needed in "test.el", so to > make them available to the user or whatever function that needs to call > them, these entry points are autoloaded (let's say the only function > there is "test-aux"). When this package gets installed into emacs, the > autoload forms will be extracted into "loaddefs.el" in the main lisp > directory. You can then call "(test-aux)" without having to explicitly > load "test-aux.el", since the autoload form has registered that > association and will load "test-aux.el" automatically when encountering > the first use of the function test-aux. > > Now the development version of this same package gets installed locally. > The load-path is altered so that emacs finds the development version > first. Thus "(require 'test)" will load the development version. If > you now try to "(test-aux)", what happens? Autoload still has all the > associations from "loaddefs.el" and thus tries to load "test-aux.el", > which will end up finding the file in the development version. So all is > well, right? Here, I would have thought that invoking the function `text-aux' would open the "production" Lisp file (that is, the one in Emacs code base) as you use Emacs loaddefs.el associations, no? > Development progresses and as "test.el" grows larger some functions are > moved to "test-extra.el". Also, "test-aux.el" is split into > "test-aux1.el", while the function test-aux (yes, the same name as the > old, but with different arguments) is moved to "test-aux2.el". The > functions in "test-extra.el" become unavailable since autoload doesn't > know about them — unless you explicitely load "test-aux.el" of course. > Also, the calls to "(test-aux)" flip-flop between calling the old and > new test-aux: if that call is made before a load of "test-aux2.el", > emacs will look for it in "test-aux.el" and only find that file in its > own install directory. If you happened to have loaded "test-aux2.el" > (maybe due to a "(require 'test-aux2)" in "test-extra.el"), then the new > definition of "(test-aux)" will be used. So you will have irritated > users and developers alike and bugs that don't reproduce (or only with > certain versions of emacs that happen to have specific versions of > library test integrated). > > The real solution of course is to re-generate the autoloads file for the > development version and explicitely load it, say "(require > 'test-install)". > > That still leaves an open flank if you delete both a function and it's > associated source file from the development version: if someone then > uses "(test-deleted-function)", the autoload definition in Emacs will > happily find the stale source it has installed since it is not shadowed > anymore by the same file in the development version. I've no idea yet > if that is fixable without touching the actual installation and how > difficult it would be, but that's a minor worry at this point. > > > If you've made it here, please weigh in on whether you want to have > things correctly fixed or simply papered over. Either one is fine with > me... I've experienced enough couple of hours lost in the past, searching for problems due to mixed versions loaded, to know what the correct answer is. Often, such problems are even not detectable in such a case: 1. some function loads an Org function (without you being aware), hence the Emacs Org version. 2. you update your load-path to point to Org latest dev version (.. but not at the very top of your Emacs init file). 3. you load other Org components. 4. you have problems. 5. you don't notice them by inspecting `load-path' variable: your Org dev directory is in front of Emacs Org directory, letting you think everything is correct! Best regards, Seb -- Sebastien Vauban
Re: [O] orgstuct++ does not lurk silently in the shadow
Hi Eric, Eric Fraga writes: > Thanks for this. This behaviour has annoyed me for years now. Me too... > I've > never gotten around to figuring out why I got this behaviour because I > get caught up with writing the email and forget by the time I finish... > > I hope somebody can indeed fix this as it sounds quite straightforward > (for better elisp programmers than I...). This should be fixed now in master. Can you confirm? There is one remaining use-case I didn't fix: the case where you use M-q on the first line of the message (things are messed up then.) I don't know how to fix this, but this is a rather border-line case, as simply typing and using auto-fill does the right thing. Thanks for insisting on this! -- Bastien
Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?
At Thu, 26 Apr 2012 17:44:56 +0930,
Eric Fraga wrote:
> > But I still have the issue with it
> > that the user has to adapt the org-file structure to suit beamer's
> > requirements. Org-mode is all about reflecting the content in a way
> > that makes sense FIRST to humans, and only secondarily to exporting
> > engines.
>
> I agree. However, the problems arise when exporting because of
> fundamentally different structures between org and the export
> target. This is why we have the various kludges (if people can forgive
> me for calling them this) like ATTR_HTML and ATTR_LATEX. There is no
> easy or elegant mechanism in org for satisfying all the different export
> target requirements that are fundamentally inconsistent with org's
> outline heritage.
I understand. An elegant solution would take some mulling over (especially
considering that I've only recently started using the export features, and my
knowledge of LaTeX is superficial at best). In the meantime, I can live with
the current situation.
That the headline title is used for the color specification is probably not
such an unbearable thing in practice. How many color boxes are there likely to
be on one slide? (Meaning, if you're tempted to load up a slide with so many
color boxes that you get confused about the content, maybe the content needs to
be restructured.) If it's the only color box on the slide, quite likely you can
infer its content from the frame title or other headings nearby.
It just struck me as a loose end, and I'm glad I asked about it, because I have
a better understanding of the issues now.
> For this particular case, it could be that the beamercolorbox
> environment could be made to expect a specific PROPERTY, much like the
> column environment does. The question would then be: what should the
> headline be used for as beamercolorbox has no real text content
> argument.
There are other beamer tags that don't use the headline text, namely quote and
quotation. According to the beamer user guide, there's no place for the
headline:
\begin{quote}
environment contents
\end{quote}
Compared to
\begin{block}{block title}
environment contents
\end{block}
So, there is already a situation where you have to put some dummy text into the
headline that won't appear. Maybe there could be special handling for
title-less environments, so that the headline would become the environment
contents and colorbox could take its color from a property...
> I would guess that if you could suggest a consistent and more elegant
> solution, it would be considered favourably and maybe somebody would
> take it up and implement it. No promises, however!
... but the elegance of that approach would be debatable, I suppose.
James
--
James Harkins /// dewdrop world
jamshar...@dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
[O] "Bad" interaction between flyspell and org-mode with latest Emacs
Hello,
#+TITLE: Example with org-mode and flyspell on.
#+AUTHOR: Vladimir Lomov
* Org-mode src blocks and flyspell
I faced with strange problem with Emacs and org-mode.
In my real example I use src blocks and run =C-c '= to
edit them in native mode (shell).
If I enter into native mode, put new line and immediately run =C-c '= to
return to org document Emacs hangs and consume all available memory (RAM and
SWAP).
Curiously that such behavior see only with revno 108012.
In echo area I see message:
#+BEGIN_QUOTE
Error in post-command-hook (flyspell-post-command-hook): (error "Marker does
not point anywhere")
#+END_QUOTE
This is extract from my document:
#+BEGIN_SRC sh :exports code
_num=${1:=_num}
_num=$(( _num%5 ))
#+END_SRC
I enter into block, run =C-c '=, add new line between lines and run immediately
=C-c '= again.
If I open the file again in Emacs and run =M-x flyspell-mode= (in echo
area I see 'flyspell disable') and do the same — I again get hang and
memory consumption.
If I commented the line in mine .emacs file:
(add-hook 'org-mode-hook 'flyspell-mode)
and tried again — all works fine.
Is this known behavior or new "bug"?
** Info
Emacs: build from BZR (rev. 108012+) vs GTK3;
org-mode: packaged from git and installed in my system (Archlinux).
P.S. I reported this here because don't know how to trigger similar
behavior without org-mode.
---
WBR, Vladimir Lomov
--
If you notice that a person is deceiving you, they must not be
deceiving you very well.
Re: [O] bug#11249: 24.1.50; Overlay with face property causes calendar buffer to scroll
Hi Matt, Matt Lundin writes: > Note: It seems that adding the optional argument KEEPDATE is necessary > for parsing to work. With the following line instead of the one above > org-read-date works as expected: > > (org-eval-in-calendar '(setq cursor-type nil) t) that's right -- I pushed this fix to master. Thanks for reporting this and for detailing the solution! -- Bastien
Re: [O] Ever used org-mode contrib packages?
On Wed, Apr 11, 2012 at 21:22, François Allisson wrote: > I'm curious > to know what you are using from org-contrib... The only one I use currently is org-mime and even then only infrequently. However, this thread has spurred me on to have a look at org-collector as this could prove quite useful to me! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] Disable links in Latex export
Nick Dokos writes:
[...]
> If all you care about is the *appearance*, rather than the existence of
> links, however, you can use hyperref package options to influence
> that. For example
>
> \usepackage[pdfborder={0,0,0}]{hyperref}
>
> will get rid of the red boxes around the links in the TOC: they are
> still links, they are just not that obvious any more. You can do that
> by customizing the org-export-latex-default-packages-alist variable:
> just add the above option (without the square brackets) to the hyperref
> package entry.
adding the line
#+latex_header: \hypersetup{pdfborder={0,0,0}}
in the org document should be sufficient?
In practice, I actually do:
#+latex_header: \hypersetup{colorlinks=true}
which still colours the links but gets rid of the ugly boxes.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] [babel] hide inline source code blocks by results
Eric Schulte writes:
> Currently inline blocks like don't associate themselves with their
> results, they are only expected to be evaluated on export, so the
> functionality you suggest below would require first changing how results
> are associated with inline code blocks.
>
> Another option would be to hide everything but the body of the block,
> but this may be more confusing than it is worth.
Eric,
I do like what Torsten suggested a lot. I wonder if a halfway solution
would be possible. Define a babel: link type which includes the src_xxx
code and let the description part of the link be whatever the author
wants it to be. I wouldn't mind not knowing the result of the code
execution as I don't know that at the moment anyway.
So, something like this would be nice:
... and the result is [[babel:src_octave{3*x+5}][f(x)]] which
demonstrates ...
which would look like
... and the result is f(x) which demonstrates ...
(with f(x) highlighted as a link).
Could something like this be possible?
And, to take this further, could the highlighting differ depending on
link type? I've not explored this latter aspect so maybe it's already
possible...
thanks,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] Exporting to ACM format using new LaTeX exporter
* Thomas S. Dye wrote: > Karl Voit writes: > >> https://github.com/novoid/orgmode-ACM-template >> > Hi Karl, Hi! > IIUC, you'd like to configure Org-mode to export a LaTeX file that is > functionally equivalent to sigproc-sp.tex. Yes. If it is possible, I want to have an equivalent PDF and an equivalent TeX as well. > If this is the case, it might be best to change the name of > orgmode.org to sigproc-sp.org or something similar. It has to be something similar. Otherwise the sigproc-sp.tex gets overwritten by the exporter. > If the goal is to support both exporters, perhaps > sigproc-sp-old.org and sigproc-sp-new.org? Good idea. I'll change it. > In my view, it is best to encapsulate as much of the Org-mode > configuration as possible in an init.el file. That way, users of the > Org-mode template can launch with emacs -Q etc. and not have to worry > about their own customizations that might conflict with the > configuration. An example is here: https://github.com/tsdye/LKFS.git. > Perhaps two initialization files would be needed: init-new.el and > init-old.el? I was hoping that it is possible to encapsulate everything in the Org-mode file instead. «#+name: setup» looked very promising to me for that purpose ... (but so far I could not achieve any impact with it) >> With the new exporter, I was not able to compile the Org-mode file >> at all. Since the old exporter had troubles using this >> "per-file-class" I do have a feeling that this might be the cause >> for the error message with the new exporter too. > > I'll have a look at this and send you patches off list. Great! -- Karl Voit
Re: [O] Updating BibTex file
Julian Burgos writes: > Dear list, > > How can I made org mode / reftex to recognize changes in my BibTex > file? Here is the scenario. I have my default BibTex file defined > with the reftex-default-bibliography variable. While working on my > org mode document I am adding references and everything is working > fine. The problem occurs when I edit my BibTex file to add new > references (using JabRef), but the new references do not show up when > I call 'reftex-citation. > Any ideas? > Thanks, > > Julian Don't know whether you got an answer to this but googling "update reftex when bibliography file changes" gives a number of useful links. The first one is actually org related: http://tincman.wordpress.com/2011/01/04/research-paper-management-with-emacs-org-mode-and-reftex/ and mentions the need to auto-revert the bibliography file. The second google result says the same thing: https://josephhall.org/nqb2/index.php/reftex-1 HTH, eric PS - I have auto-revert set globally so I would have noticed a problem but, in any case, I do all my bibtex editing in Emacs ;-) -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] Exporting to ACM format using new LaTeX exporter
* Nicolas Goaziou wrote: > Hello, Hi Nicolas! > Karl Voit writes: > >> * Thomas S. Dye wrote: >>> >> Yea, that might be appropriate. So I set up a github repos: >> >> https://github.com/novoid/orgmode-ACM-template >> >> With the new exporter, I was not able to compile the Org-mode file >> at all. Since the old exporter had troubles using this >> "per-file-class" I do have a feeling that this might be the cause >> for the error message with the new exporter too. >> >> Maybe someone more familiar with the (new) LaTeX exporter can send >> me some patches ... > > I don't understand what you are trying to achieve. Would you mind > summarizing it for someone too lazy to browse docs? Sure: when I want to hand in a paper for a conference which demands LaTeX documents that fulfill the requirements of the ACM template, I want to have to possibility to use Org-mode with its LaTeX export method in order to get PDF output which will be accepted by the conference. Most of the time, only the PDF have to look like the template result, some times it is required to hand in also the TeX sources of the paper. > Note that `org-splice-latex-header' belongs to neither the legacy > exporter nor the new one: it's an org.el function. Thus your problem may > lie elsewhere. Oh gosh. I guess I have to strip down my Org-mode file and start all over with a minimal version trying to expand until the error occures. -- Karl Voit
Re: [O] org-mode and google calendar
Khoroshyy Petro writes: > Just wanted to bring to your attention this mode. > https://github.com/kiwanami/emacs-calfw Yes -- this is a great add-on, already advertized here. It would be nice to document this on http://orgmode.org/worg/ with a page displaying nice screenshots and explaining the setup. -- Bastien
Re: [O] Google Summer of Code -- 3 Org projects for our first participation!
Hi Rasmus, Rasmus writes: > This could be huge. > > Would the `final' code be part of Org or Git-upstream? It will land in the UTILITIES/ directory of Org distribution and be available for download on orgmode.org, with docs on Worg. It will certainly be tested then used in the Worg git repo. And Github users who maintain a README using Org will surely appreciate such a tool. > I am guessing the latter for robustness. It might be a good candidate for the git contrib directory, let's see. -- Bastien
Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?
James Harkins writes:
> At Wed, 25 Apr 2012 18:09:18 +0800,
> James Harkins wrote:
>> > Whether it should be a feature request or not is debatable. The syntax
>> > is, at present, fairly straightforward in that the headline text becomes
>
>> > the argument to the environment defined.
>>
>> I think "the headline text becomes the argument..." is the opposite of
>> straightforward. :-)
>
> OK, wait, I get it:
>
> \begin{alertblock}{HEADLINE TEXT HERE}
>
> \begin{beamercolorbox}{HEADLINE TEXT HERE}
>
> OK, it's a consistent translation.
Yes.
> But I still have the issue with it
> that the user has to adapt the org-file structure to suit beamer's
> requirements. Org-mode is all about reflecting the content in a way
> that makes sense FIRST to humans, and only secondarily to exporting
> engines.
I agree. However, the problems arise when exporting because of
fundamentally different structures between org and the export
target. This is why we have the various kludges (if people can forgive
me for calling them this) like ATTR_HTML and ATTR_LATEX. There is no
easy or elegant mechanism in org for satisfying all the different export
target requirements that are fundamentally inconsistent with org's
outline heritage.
For this particular case, it could be that the beamercolorbox
environment could be made to expect a specific PROPERTY, much like the
column environment does. The question would then be: what should the
headline be used for as beamercolorbox has no real text content
argument.
I would guess that if you could suggest a consistent and more elegant
solution, it would be considered favourably and maybe somebody would
take it up and implement it. No promises, however!
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)
Re: [O] Google Summer of Code -- 3 Org projects for our first participation!
Hi Neil, Neil Smithline writes: > I've run into this problem dealing with the weak presentation of Org Mode > files on Github. Github uses the Ruby gem org-ruby > (https://github.com/bdewey/org-ruby) to convert .org files to HTML. I've > added a feature or two to org-ruby but really feel that trying to > completely re-implement Org Mode in a Ruby gem is a losing battle. What will help org-ruby (and github's support of org files) is to stabilize the syntax of .org files as much as possible. We are currently working in this direction. org-ruby's main job is to convert .org files into HTML or textile files. > If I understand the project correctly, a working iOrg could be used to > support Github's rendering of .org files. Github could just drop the use of > org-ruby and use iOrg as an external converter for formatting .org files. As I understand it, iOrg will convert .org files to HTML using the internal Org's HTML exporter. I don't see how github could use such a setup to produce HTML files from Org (unless github runs an Emacs batch query for exporting HTML... which seems very unlikely - and wrong by design anyway. Let's see how iOrg evolves but let's stick to the bugpile for now. If the list can specifically help about org-ruby issues, let's help! All best, > PS: And the answer is "Yes. I am aware that vehemently suggesting a project > is equivalent to offering to help with it." :-D Good :) -- Bastien
Re: [O] Google Summer of Code -- 3 Org projects for our first participation!
Neil Smithline writes: Hi Neil, > This is way cool! Recently I have been deeply irritated by the lack of > a functional server for Emacs Org Mode. > > I've run into this problem dealing with the weak presentation of Org > Mode files on Github. Github uses the Ruby gem org-ruby > (https://github.com/bdewey/org-ruby) to convert .org files to HTML. > I've added a feature or two to org-ruby but really feel that trying to > completely re-implement Org Mode in a Ruby gem is a losing battle. > > If I understand the project correctly, a working iOrg could be used to > support Github's rendering of .org files. Github could just drop the > use of org-ruby and use iOrg as an external converter for formatting > .org files. > > At the risk of being flamed to a cinder, I'll say that I think that > using iOrg to support .org files on Github would be a better pilot > project than Bugpile. I figured out too that the best way to watch org files on github is raw mode, so I think this is a very interesting and useful proposal. But its a bit late for this year ;) I like the bugpile project, and as I understood it, the bugtracker might actually be used for Org-mode development if it fits the needs of the Org-mode hackers. Since this years application was such an success with 3 projects accepted, Org-mode might well try it again in 2013. What do you think about putting your proposal on the ideas page for GSoC 2013 (which I could rapidly push to Worg) with you as potential mentor/co-mentor? Then it would not get lost, and interested students could apply next year (if you can cope with githubs rendering of org files so long). And there would be much more time to outline and coordinate the project. > Besides my personal interest in better Github support for .org, I > think that the Github project will be generally useful. > > Also, from the tone of postings, it sounds like the Bugpile project is > not well specified. Being that Thorsten only has a summer to do the > work, I think it will be hard to create a Bugpile specification and > implementation and an iOrg specification and implementation in just > one summer. > > As Github already has a specification for external markup converters > (see https://github.com/github/markup), there is no need for writing > any spec. For the first release of iOrg (ie: this summer's work), the > iOrg implementation can be simplified to providing .org support for > Github. > > If things go well, I imagine that Thorsten would be very happy to > finish the summer with his iOrg a part of Github. Definitely a very interesting idea, but I'm already quite 'invested in the bugpile project, and imagine I finish the summer as the author of a bugtracker actually used by a quite big and dynamic GNU project like Org-mode. > Just my two cents, > > Neil > > PS: And the answer is "Yes. I am aware that vehemently suggesting a > project is equivalent to offering to help with it." :-D > > I can help with the .org/Github side of the project though I'm sure > others know more about the implementation of Org Mode than me. If > needed, I could also help manage interactions between Thorsten and > Github as I'm sure that Github will have some requirements before they > accept a pull request into their repository. > > As far as Emacs internals, it's been 25 years since I last looked at > the C source for Emacs so there must be better folk than I. In any > case, any Emacs internal work that must be done for iOrg existed prior > to my suggestion. In other words, it ain't my problem ;-) > > > Neil Smithline > http://www.neilsmithline.com > Proud GNU Emacs user since 1986, v. 18.24. > > > On 4/24 04:12 , Thorsten wrote: >> Ian Barton writes: >> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and Org-mode (Thorsten) The Bugpile project has two goals: 1. Develop a bugtracker (called Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a dVCS. 2. As part of the engineering process, abstract out a web-framework (called iOrg) based on these GNU Emacs technologies. A web-framework written in Elisp, with Org files used for database functionality, is a new approach that enables interactive web applications built on top of GNU Emacs. Bugpile is an example application, but useful in itself. >>> >>> Great news! >>> >>> For the dim witted (me) can you explain if Bugpile is meant to be a >>> bug tracker specifically for tracking bugs in Emacs and org, or can it >>> be used as a generic bug tracker for any project. >> >> Thats a very interesting question, since there are two somehow >> conflicting goals involved. >> >> The original project idea was to extend Org-mode for a more interactive >> kind of web-programming, i.e. having buttons and forms on your webpages >> and a kind of database in the background that stores changing state, and >> some logic that reacts to user action (instead of just publishing
Re: [O] error on opening org-file with #+startup: indent
fkunze writes: > Augment the installation description > (http://orgmode.org/manual/Installation.html#Installation) with a short > description for windows users (that avoids the use of make). I'm not using Windows myself, but I would welcome a patch that clarifies the installation process for Windows. Anyone? -- Bastien
