Re: [O] org-html-postamble-format and #+DATE: specification in 8.0pre
Nicolas Goaziou writes:
> I didn't try to reproduce the problem, but specifying a format time
> string as a DATE value is not possible anymore. You still can provide
> a timestamp and tweak `org-export-date-timestamp-format' (or BIND it) to
> format it.
I have a more serious issue: it seems that '%d' is no longer taken into
account. To reproduce, try exporting the following:
#+BEGIN_SRC org
# -*- org-export-allow-bind-keywords: t -*-
#+TITLE: Testing the date
#+BIND: org-html-postamble-format (("en" "Test %d %a"))
Hello World
#+END_SRC
Alan
Re: [O] Bug: SETUPFILE directive not working [8.0-pre (release_8.0-pre-10873-gafb59b @ /home/mrb/dev/emacs/packages/org-mode/lisp/)]
Hi Marcel,
Marcel van der Boom writes:
> C-c C-c on that line says "Local setup has been refreshed" but at least
> some of the settings do not get applied. Notably i have several lines
> in that 'settings.org' file like this:
>
> #+TAGS: { buy(b) sell(s) } build(u) fix(f) clean(n)
>
> or
>
> #+TAGS: call(c) check(e) mail(m) read(r) write(w) learn(l)
This should now be fixed in master. Thanks for reporting this
with all the details.
--
Bastien
Re: [O] avoid subscripting text
Hello, Mike McLean wrote: > On Apr 3, 2013, at 9:30 PM, Gary Oberbrunner wrote: > >> I use LaTeX export all the time, but almost always with words with >> underscores in them (data from external tables, variable names and so on). >> So I never want _ to turn into a subscript. Just one data point, but that's >> how I use it. > > I have to echo this use case. I have variable names and what not with > underscores in the name about 100 times as much as I have a need for a > subscript. Do you mean that the option ^:nil is not working for you, or not enough? Best regards, Seb -- Sebastien Vauban
[O] Referring to files (was: looking for advice on where/how to store org realted files (attachments/images etc))
* Itai kloog wrote: > > Hi all Hi! > I take alot of screenshots and attach alot of PDF's/ scrips to my notes. I > would love to hear back from the community on how people organize these " > realted" org files. Take a look at http://orgmode.org/org.html#Attachments - it's «the Org-mode way» of attaching files to a node. However, I generally use a different kind of approach. Files like screenshots I name similar to «2013-01-14T10.01 Screenshot - calfw week view sketch.png», thus including an ISO 8601 date/time-stamp. With Memacs [1] I do use a module that generates an Org-mode index of all files that start with such a timestamp [2]. This way, I can refer to any file: [[tsfile:2013-01-14T10.01 Screenshot...]] This custom link (tsfile) takes me to the corresponding Org-mode/Memacs buffer which has the link to the file. So, it's an indirect link but this way, I do not care in which directory the (unique) file is located. This is handy especially when the folder is not the same on different machines you are using. Or when you like to move files (after finishing a project or similar). HTH 1. https://github.com/novoid/Memacs 2. https://github.com/novoid/Memacs/blob/master/docs/memacs_filenametimestamps.org -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
[O] Commit 'cf5e96c8e1be5d0f9df2d98415f3ee16df9408f0' introduces texi syntax error
Hello,
as topic states, I attached small patch.
---
WBR, Vladimir Lomov
--
For some reason a glaze passes over people's faces when you say
"Canada". Maybe we should invade South Dakota or something.
-- Sandra Gotlieb, wife of the Canadian ambassador to the U.S.
diff --git a/doc/org.texi b/doc/org.texi
index 3ce5c61..547ce3d 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14188,11 +14188,11 @@ argument.
#+header: :file /tmp/it.png
#+begin_src dot :post attr_wrap(width="5cm", data=*this*) :results drawer
- digraph{
+ digraph@{
a -> b;
b -> c;
c -> a;
- }
+ @}
#+end_src
#+RESULTS:
Re: [O] Agenda for 14 days, but still starting on Sat
Subhan Tindall writes:
> Try this:
> ("z" "test" ((agenda "test" ((org-agenda-start-on-weekday 6)
> (org-agenda-start-day "0")
> (org-agenda-span 14)
Yes, that's it.
Nota bene: the reason why `org-agenda-start-day' should be a string is
that you can use relative times like "+3d".
--
Bastien
Re: [O] Bug?: org-babel-load-file not autoloaded in Emacs 24.3
Hi Jonathan, Jonathan Leech-Pepin writes: > I currently have the vast majority of my .emacs configuration in .org > files that rely on =org-babel-load-file=. > > Before updating to Emacs 24.3 I could rely on autoloads to complete > the initialization. After updating today I get the following error: > > =Symbol's function definition is void: org-babel-load-file= > > Is it intentional that org-babel-load-file is no longer autoloaded > and that > either (require 'org) or (require 'org-loaddefs) is needed to use it > when > starting emacs? This is now fixed, thanks a lot for reporting this. Best, -- Bastien
Re: [O] Commit 'cf5e96c8e1be5d0f9df2d98415f3ee16df9408f0' introduces texi syntax error
Vladimir Lomov writes: > as topic states, I attached small patch. Applied, thanks! -- Bastien
[O] [PATCH] bugfix Was: [PATCH] Was: How to apply multiple TBLFM rules?
Hi Bastien, Thanks for looking at these patches. Could you also apply this bugfix patch for them? Thanks in advance. Bastien writes: > Ippei FURUHASHI writes: > >> This patch enables user to applies a temporal TBLFM line where you are in. >> It is useful when you switch a formula to another. >> I hope you liked this. > > I do! I've applied the patches (with some minor changes) on my local > branch, it will be available when I push it later today. I saw it on master branch. Your changes are welcome, because comments became easier to review. Best, IP >From 24a18f1ffdc38dfd297960d9b06a12f35a256e82 Mon Sep 17 00:00:00 2001 From: Ippei FURUHASHI Date: Fri, 5 Apr 2013 16:07:00 +0900 Subject: [PATCH] org-table.el: Fix a bug of leaving the inserted TBLFM line * org-table.el (org-calc-current-TBLFM): Ensure to remove the currently inserted TBLFM line, when calling `org-table-recalculate' returns an error and the processing stops. * testing/lisp/test-org-table.el: Add test. Bug description When you hit =C-c C-c= at the line of "#+TBLFM: $2=$1*2::$2=$1**2" in | 1 | | | 2 | | #+TBLFM: $2=$1*1 #+TBLFM: $2=$1*2::$2=$1**2 you got: | 1 | | | 2 | | #+TBLFM: $2=$1*2::$2=$1**2 #+TBLFM: $2=$1*1 #+TBLFM: $2=$1*2::$2=$1**2 with the error message of: user-error: Double definition `$2=' in TBLFM line, please fix by hand In this case, you expected: | 1 | | | 2 | | #+TBLFM: $2=$1*1 #+TBLFM: $2=$1*2::$2=$1**2 --- lisp/org-table.el |7 --- testing/lisp/test-org-table.el | 25 + 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index ccd1735..460d249 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -3190,10 +3190,11 @@ (defun org-calc-current-TBLFM (&optional arg) (beginning-of-line 0); move to the inserted line (skip-chars-backward " \r\n\t") (if (org-at-table-p) - (org-call-with-arg 'org-table-recalculate (or arg t))) + (unwind-protect + (org-call-with-arg 'org-table-recalculate (or arg t)) - ;; Delete the formula inserted temporarily - (delete-region s e + ;; delete the formula inserted temporarily + (delete-region s e)) (defun org-TBLFM-begin () "Find the beginning of the TBLFM lines and return its position. diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el index dda8561..01adf52 100644 --- a/testing/lisp/test-org-table.el +++ b/testing/lisp/test-org-table.el @@ -929,6 +929,31 @@ (defconst references/target-special " (should (string= got expect) +(ert-deftest test-org-table/org-calc-current-TBLFM-when-stop-because-of-error () + "org-calc-current-TBLFM should preserve the input as it was." + (org-test-with-temp-text-in-file + " +| 1 | 1 | +| 2 | 2 | +#+TBLFM: $2=$1*1 +#+TBLFM: $2=$1*2::$2=$1*2 +#+TBLFM: $2=$1*3 +" +(let ((expect " +| 1 | 1 | +| 2 | 2 | +#+TBLFM: $2=$1*1 +#+TBLFM: $2=$1*2::$2=$1*2 +#+TBLFM: $2=$1*3 +")) + (goto-char (point-min)) + (forward-line 4) + (should-error (org-calc-current-TBLFM)) + (setq got (buffer-string)) + (message "%s" got) + (should (string= got + expect) + (provide 'test-org-table) ;;; test-org-table.el ends here -- 1.7.9.msysgit.0
Re: [O] Bug: SETUPFILE directive not working [8.0-pre (release_8.0-pre-10873-gafb59b @ /home/mrb/dev/emacs/packages/org-mode/lisp/)]
On vr 05-apr-2013 09:20 Bastien wrote: > This should now be fixed in master. Thanks for reporting this > with all the details. Cool, thanks! This was the last hurdle for me before upgrading. marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Bastien writes: >> It took me about one hour (my Gnus programming is rather rusty) for >> adding a Gnus command opening many tabs at once, in a graphical >> browser, for all articles I retain in Gnus for reading. > That looks nice, is your hack public somewhere? No, but here it is, usage instructions follow. (defun fp-gnus-summary-open-links (arg) "Open links in a browser for processable articles, like for Hacker News." (interactive "P") (let ((articles (gnus-summary-work-articles arg))) (save-excursion (while articles (setq article (pop articles)) (gnus-summary-goto-article article) (gnus-summary-show-article t) (save-excursion (pop-to-buffer gnus-article-buffer) (re-search-forward "Link") (browse-url (match-string 1))) (gnus-summary-remove-process-mark article (gnus-summary-position-point)) (defun my-gnus-summary-mode-hook () (define-key gnus-summary-mode-map "\C-cnl" 'fp-gnus-summary-open-links) ;; ... ) (add-hook 'gnus-summary-mode-hook 'my-gnus-summary-mode-hook) The function selects articles according to the process/mark convention, and I want it to fail whenever an article does not have a "Link" button (that's why I do not catch the error if "re-search" fails). So, I use it this way. In an RSS summary buffer, I use C-k to "read" without opening any subject I want to skip. Once done, I use "x M P A C-c n l" to remove all article I C-k'ed, add a process mark on everything else, then transfer marked articles into a graphical browser, one tab per article. Transferred articles also get "read" in the summary buffer. I also use this bit of Emacs Lisp code in ~/.emacs, which is related: ;; Chrome (really xdg-open) ;; (defun browse-url-xdg-open (url &optional new-window) "Ask the default browser to load URL. Default to the URL around or before point." (interactive (browse-url-interactive-arg "URL: ")) (shell-command (concat "xdg-open " (shell-quote-argument (browse-url-encode-url url) (setq browse-url-browser-function 'browse-url-xdg-open) François
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Suvayu Ali writes: > For me it is the other way around. I want to couple with Emacs more > closely, but Gnus prevents me from doing so. A few gripes follow. > 1. Emacs is single threaded, so a network interruption while reading my >email over IMAP means my emacs server is stuck! It would be so appealing if Emacs was really using threading for its windows. Tom Tromey seems to be making a very courageous attempt at it, but is still hitting various problems and walls. I wonder if he will succeed at the end. In my case, Emacs is indeed stuck for a few seconds, not enough to bother me significantly. I read that some people combine fetchmail, procmail and other tools so Emacs does not IMAP itself; I just did not want to dive into all the locking and synchronization issues implied by such tools. > 2. Oh that's easy to solve, use maildirs (sync with OfflineIMAP). That >does not work well because Gnus uses its own flags (an example where >Gnus actually breaks standards)! There are some hacks around that >out in the wild, so let's let it slide. > 3. Gnus stores some meta information/cache for maildirs in a .nnmaildir >folder *inside* the maildir directory tree! > maildir > ├── .nnmaildir > ├── cur > ├── new > └── tmp >I do not know how, but this supposed meta information or cache takes >about 2/3 of disk space as the original maildir! Obviously that is a >problem for large mailboxes. I never really studies IMAP, and use it rather naively, so I take your word about Gnus not being straight about it. Sorry to hear that. I've not been bitten yet, or maybe I'm just too naive to know. However, I remember that I often had to read Gnus structures in external, non-Emacs programs, and it is indeed a challenge each time. I merely try to not do that anymore! :-) > I use mutt-kz (mutt with notmuch integration) and emacsclient. With > support for linking using org-notmuch, I couldn't be happier. Thanks for the hints, which I save, could be useful one day, who knows! :-) When I left Emacs for other lands, years ago, I decided for Mutt and used it for many years (before switching to others, and finally Thunderbird). With many stunts (a bit too much of them should I say), I could get Mutt to do about anything I wanted (but never had such success with Thunderbird). Back to Gnus, and configuring it as little as I can, I have the impression of recovering some simplicity on the user side. Moreover, Org nicely plays with Gnus (or almost). François
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Hey François, On Fri, Apr 05, 2013 at 07:18:56AM -0400, François Pinard wrote: > Suvayu Ali writes: > > > For me it is the other way around. I want to couple with Emacs more > > closely, but Gnus prevents me from doing so. A few gripes follow. > > > 1. Emacs is single threaded, so a network interruption while reading my > >email over IMAP means my emacs server is stuck! > > It would be so appealing if Emacs was really using threading for its > windows. Tom Tromey seems to be making a very courageous attempt at it, > but is still hitting various problems and walls. I wonder if he will > succeed at the end. I'm dying for Emacs to be multi-threaded in the future. Email is just one task affected by this. My biggest problem is using tramp over unreliable connections. e.g. I want to edit my remote org files with the latest and greatest of org on my laptop! I often have to work on remote machines behind internal gateways (that's 3 ssh hops away!). I do save my notes/tasks in org files there, but cannot edit them optimally because emacs on these nodes is some crappy old version. > > 2. Oh that's easy to solve, use maildirs (sync with OfflineIMAP). That > >does not work well because Gnus uses its own flags (an example where > >Gnus actually breaks standards)! There are some hacks around that > >out in the wild, so let's let it slide. > > 3. Gnus stores some meta information/cache for maildirs in a .nnmaildir > >folder *inside* the maildir directory tree! > > maildir > > ├── .nnmaildir > > ├── cur > > ├── new > > └── tmp > >I do not know how, but this supposed meta information or cache takes > >about 2/3 of disk space as the original maildir! Obviously that is a > >problem for large mailboxes. > > I never really studies IMAP, and use it rather naively, so I take your > word about Gnus not being straight about it. Sorry to hear that. I've > not been bitten yet, or maybe I'm just too naive to know. Ah I think you misunderstood me. My solution above was to move from IMAP to Maildir so the reliance on a live network connection is gone. Gnus screws it up when dealing with _Maildir_ flags. Now back to work and more on topic threads. ;) Cheers, -- Suvayu Open source is the future. It sets us free.
[O] Highlighting bug with org-agenda-set-restriction-lock
Hi, The highlighting has changed for this functionality. I finally updated to master (1200+ commits) yesterday and when I use C-c C-x < the entire subtree is now highlighted in bright yellow on my Windows Emacs. GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO Org-mode version 7.9.2 (release_7.9.2-2030-g29a75d @ d:/bin/org-mode/lisp/) This used to highlight only the first heading of the subtree. Highlighting the entire subtree is _very_ distracting and makes working in the org file on the narrowed subtree difficult (for me). I can fix this by changing the face and completely removing the highlight but I'd prefer the old functionality if that is possible. I also noticed that the main heading is now also highlighted in the agenda which is okay I guess but also different from how this used to work :) I haven't tried this on my Linux system at home yet. Will do that this weekend. Thanks, Bernt
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
Bernt Hansen writes: > I also noticed that the main heading is now also highlighted in the > agenda which is okay I guess but also different from how this used to > work :) This is unrelated - it's highlighted because it is my current clocking task. :) Thanks, Bernt
Re: [O] org-html-postamble-format and #+DATE: specification in 8.0pre
On 05.04.2013 03:17, Alan Schmitt wrote:
I have a more serious issue: it seems that '%d' is no longer taken
into
account. To reproduce, try exporting the following:
#+BEGIN_SRC org
# -*- org-export-allow-bind-keywords: t -*-
#+TITLE: Testing the date
#+BIND: org-html-postamble-format (("en" "Test %d %a"))
Hello World
#+END_SRC
Try the DATE header argument. Also, if you only want to bind the
postamble for the current
buffer in only one language, you can bypass the postamble-format alist:
,
| #+TITLE: Test postamble
| #+DATE: {{{modification-time( %Y-%m-%d)}}}
| #+BIND: org-html-postamble "By %a on %d"
|
| * File was updated on {{{modification-time( %Y-%m-%d)}}}
| - the header date is: {{{date()}}}
`
Re: [O] org-html-postamble-format and #+DATE: specification in 8.0pre
On 04.04.2013 17:36, Dieter Wilhelm wrote:
Nicolas Goaziou writes:
Alan Schmitt writes:
Dieter Wilhelm writes:
but now I can't specify a date in the form
#+DATE: "%Y-%m-%d"
Formerly an empty specification meant the current date, but now in
the
preamble the date remains empty.
I'm having the same issue. Did you find a way around it?
I didn't try to reproduce the problem, but specifying a format time
string as a DATE value is not possible anymore. You still can
provide
a timestamp and tweak `org-export-date-timestamp-format' (or BIND
it) to
format it.
Sorry I don't get it completely.
I'd like to have as the DATE value the current change time of the
file.
You mean that I should set this with the Emacs timestamp facility?
Like:
#+DATE: Time-stamp: " "
No, but you can use the modification-time() macro:
,
| #+TITLE: Test date handling
| #+DATE: {{{modification-time(%Y-%m-%d)}}}
| #+OPTIONS: toc:nil
|
| * File was updated on {{{modification-time(%Y-%m-%dT%H:%M)}}}
| - the header date is: {{{date()}}}
| - the current time is {{{time(%Y-%m-%dT%H:%M)}}}
`
Which will export (in ascii):
,
|
|
|TEST DATE HANDLING
|
| Rick Frankel
|
|
|
|2013-04-05
|
|
|
|
|
| File was updated on 2013-04-05T09:41
|
|
| - the header date is: 2013-04-05
| - the current time is 2013-04-05T09:46
`
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
On 5 apr. 2013, at 15:12, Bernt Hansen wrote: > Hi, > > The highlighting has changed for this functionality. I finally updated > to master (1200+ commits) yesterday and when I use C-c C-x < the entire > subtree is now highlighted in bright yellow on my Windows Emacs. > > GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO > > Org-mode version 7.9.2 (release_7.9.2-2030-g29a75d @ > d:/bin/org-mode/lisp/) > > This used to highlight only the first heading of the subtree. > Highlighting the entire subtree is _very_ distracting and makes working > in the org file on the narrowed subtree difficult (for me). > > I can fix this by changing the face and completely removing the > highlight but I'd prefer the old functionality if that is possible. This is causes by this commit: commit aa0e0068de109eef2ac7897c4659d545b351de01 Author: Bastien Guerry Date: Sat Feb 16 23:09:57 2013 +0100 org-agenda.el (org-agenda-set-restriction-lock): Put the overlay until the e * org-agenda.el (org-agenda-set-restriction-lock): Put the overlay until the end of the subtree, not the end of the headline. When the agenda restriction is on, user expect agenda views to check every entry in the subtree. If a user add an entry outside of the overlay without noticing it, this entry will not be checked and the user will wonder why. Put the end of the overlay at the end of the subtree so that the user always knows if the entries she is adding are within the current restriction. We might need to find a less instrusive overlay color, though. So Bastien felt that the entire subtree should have an overlay, but maybe a softer color. I would also prefer the highlight just to be on the headline as it used to be. Bastien, how do you feel about reverting this change? I see why you did it, but it is not so practical after all if you want to work in this mode for extended time. - Carsten > > I also noticed that the main heading is now also highlighted in the > agenda which is okay I guess but also different from how this used to > work :) > > I haven't tried this on my Linux system at home yet. Will do that this > weekend. > > Thanks, > Bernt >
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
On 5 apr. 2013, at 16:12, Carsten Dominik wrote: > > On 5 apr. 2013, at 15:12, Bernt Hansen wrote: > >> Hi, >> >> The highlighting has changed for this functionality. I finally updated >> to master (1200+ commits) yesterday and when I use C-c C-x < the entire >> subtree is now highlighted in bright yellow on my Windows Emacs. >> >> GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO >> >> Org-mode version 7.9.2 (release_7.9.2-2030-g29a75d @ >> d:/bin/org-mode/lisp/) >> >> This used to highlight only the first heading of the subtree. >> Highlighting the entire subtree is _very_ distracting and makes working >> in the org file on the narrowed subtree difficult (for me). >> >> I can fix this by changing the face and completely removing the >> highlight but I'd prefer the old functionality if that is possible. > > This is causes by this commit: > > commit aa0e0068de109eef2ac7897c4659d545b351de01 > Author: Bastien Guerry > Date: Sat Feb 16 23:09:57 2013 +0100 > >org-agenda.el (org-agenda-set-restriction-lock): Put the overlay until the > e > >* org-agenda.el (org-agenda-set-restriction-lock): Put the >overlay until the end of the subtree, not the end of the >headline. > >When the agenda restriction is on, user expect agenda views to check >every entry in the subtree. If a user add an entry outside of the >overlay without noticing it, this entry will not be checked and the >user will wonder why. Put the end of the overlay at the end of the >subtree so that the user always knows if the entries she is adding >are within the current restriction. > >We might need to find a less instrusive overlay color, though. > > > So Bastien felt that the entire subtree should have an overlay, but > maybe a softer color. I would also prefer the highlight just to be > on the headline as it used to be. > > Bastien, how do you feel about reverting this change? I see why > you did it, but it is not so practical after all if you want to > work in this mode for extended time. I now also see that the patch did not achieve what the purpose of it was. The problem is not the end of the overlay, but the position of the org-agenda-restriction-end marker. Indeed, if you add tasks after this marker, they will not be included in the search. There is not good work-around for this I can think of, so it is a problem we will have to live with. - Carsten
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
On 5 apr. 2013, at 16:23, Carsten Dominik wrote: > > On 5 apr. 2013, at 16:12, Carsten Dominik wrote: > >> >> On 5 apr. 2013, at 15:12, Bernt Hansen wrote: >> >>> Hi, >>> >>> The highlighting has changed for this functionality. I finally updated >>> to master (1200+ commits) yesterday and when I use C-c C-x < the entire >>> subtree is now highlighted in bright yellow on my Windows Emacs. >>> >>> GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO >>> >>> Org-mode version 7.9.2 (release_7.9.2-2030-g29a75d @ >>> d:/bin/org-mode/lisp/) >>> >>> This used to highlight only the first heading of the subtree. >>> Highlighting the entire subtree is _very_ distracting and makes working >>> in the org file on the narrowed subtree difficult (for me). >>> >>> I can fix this by changing the face and completely removing the >>> highlight but I'd prefer the old functionality if that is possible. >> >> This is causes by this commit: >> >> commit aa0e0068de109eef2ac7897c4659d545b351de01 >> Author: Bastien Guerry >> Date: Sat Feb 16 23:09:57 2013 +0100 >> >> org-agenda.el (org-agenda-set-restriction-lock): Put the overlay until the >> e >> >> * org-agenda.el (org-agenda-set-restriction-lock): Put the >> overlay until the end of the subtree, not the end of the >> headline. >> >> When the agenda restriction is on, user expect agenda views to check >> every entry in the subtree. If a user add an entry outside of the >> overlay without noticing it, this entry will not be checked and the >> user will wonder why. Put the end of the overlay at the end of the >> subtree so that the user always knows if the entries she is adding >> are within the current restriction. >> >> We might need to find a less instrusive overlay color, though. >> >> >> So Bastien felt that the entire subtree should have an overlay, but >> maybe a softer color. I would also prefer the highlight just to be >> on the headline as it used to be. >> >> Bastien, how do you feel about reverting this change? I see why >> you did it, but it is not so practical after all if you want to >> work in this mode for extended time. > > > I now also see that the patch did not achieve what the purpose of it was. > The problem is not the end of the overlay, but the position of the > org-agenda-restriction-end marker. Indeed, if you add tasks after this > marker, they will not be included in the search. There is not good > work-around for this I can think of, so it is a problem we will have to live > with. I am fixing this - please let me know if I should revert my fix... Bernt, should be working in master. - Carsten
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
Carsten Dominik writes: > I now also see that the patch did not achieve what the purpose of it > was. The problem is not the end of the overlay, but the position of > the org-agenda-restriction-end marker. Indeed, if you add tasks after > this marker, they will not be included in the search. There is not > good work-around for this I can think of, so it is a problem we will > have to live with. > > - Carsten I would prefer the original highlighting behaviour as well. I normally narrow the buffer to the subtree as well when working on it -- and the entire narrowed buffer is bright gaudy yellow currently :). My workaround for the adding items to the ends is to remark the subtree restriction. I have added speed keys P, F, W, and N in my setup for narrow to project, narrow to file, widen, and narrow to subtree respectively. I normally narrow to project with P (on any task in the project narrows the current buffer to the project. In the agenda P sets the restriction lock on the project -- so if I've added anything new at the end of the project I can just hit P on any task in the agenda and the restriction lock is reset appropriately including all of the (new) tasks in the project. (My definition of a project is any todo keyword task that has at least one subtask with a todo keyword.) Regards, Bernt
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
On 5 apr. 2013, at 16:46, Bernt Hansen wrote: > Carsten Dominik writes: > >> I now also see that the patch did not achieve what the purpose of it >> was. The problem is not the end of the overlay, but the position of >> the org-agenda-restriction-end marker. Indeed, if you add tasks after >> this marker, they will not be included in the search. There is not >> good work-around for this I can think of, so it is a problem we will >> have to live with. >> >> - Carsten > > I would prefer the original highlighting behaviour as well. > I normally narrow the buffer to the subtree as well when working on it > -- and the entire narrowed buffer is bright gaudy yellow currently :). > > My workaround for the adding items to the ends is to remark the subtree > restriction. I have added speed keys P, F, W, and N in my setup for > narrow to project, narrow to file, widen, and narrow to subtree > respectively. > > I normally narrow to project with P (on any task in the project narrows > the current buffer to the project. In the agenda P sets the restriction > lock on the project -- so if I've added anything new at the end of the > project I can just hit P on any task in the agenda and the restriction > lock is reset appropriately including all of the (new) tasks in the > project. (My definition of a project is any todo keyword task that has > at least one subtask with a todo keyword.) Well, that kind of a work-around, yes. I meant something like telling the marker to insert any new text in front of it, but there is now good way. I like the speed keys! - Carsten
Re: [O] What Happened to org-export-html-extension?
On 03/04/13 12:26, Bastien wrote: Hi Ian, Ian Barton writes: Thanks for the clear explanation. Using my own function works, but this does seem to be a regression. Defining your own extension is useful e.g. if you want to emit .php files. Indeed. I fixed this regression, and using either :html-extension in publication projects or (setq org-html-extension "php") globally will work now. Thanks for reporting this, And thanks for fixing it! Ian.
Re: [O] Org-mode as a metalanguage: calling SQL "functions"
What I'd really like in the org-mode doc somewhere (or on worg?) is the babel syntax broken out like a traditional programming language, by which I mean describe the syntax[es] for *defining* a function in one place (including all the ways to define args and their default values), and describe the syntax[es] for *calling* a function in a separate section (including how to pass args). If the variable semantics vary by language (as they do), just say so (e.g. when defining a SQL function, vars are substituted into the body by prefixing the names with $, but in python they are local vars in non-session mode and global vars in session mode and so on. Maybe this doc section shouldn't try to enumerate all those languages, but just redirect to the proper worg babel language page for details on arg handling. I think all this info is already there in one place or another, but IMHO it's not organized in such a way that a newbie can start to use org-mode as a metaprogramming language without lots of false starts and reading the source (like I did). On Thu, Apr 4, 2013 at 4:10 PM, Sebastien Vauban wrote: > Eric, > > Eric Schulte wrote: > > "Sebastien Vauban" writes: > >> Eric Schulte wrote: > > At this point I'm not sure if the documentation or the code should be > > amended. I've personally never liked the args-in-block-name syntax, > but > > I don't recall if we formally decided to abandon it, or if it has > simply > > been broken in a recent commit. > > I am not sure if I have any say here, but I agree that the args in > name notation looks not as good and might be considered for > abolishment. > >>> > >>> Great, I agree wholeheartedly and I'll update the documentation > >>> accordingly (and take a look at lob-ingest to ensure it no longer uses > >>> this var-in-name style). > >> > >> I confirm that, following a discussion we had, you had decided to drop > the > >> alternate syntax, a couple of months ago (more than 2 ;-)). > > > > Great, so I'm not imagining things. Thanks Seb. > > For the sake of clarity, it all began (in September 2011) with the fact it > was > more difficult to trap errors such as missing default value, in the > functional-syntax style. See > http://article.gmane.org/gmane.emacs.orgmode/46888. > > This also lead, a couple of weeks later (October 2011), to questionning the > multiple keywords used for code blocks, such as #+source: and #+srcname:. > See > http://article.gmane.org/gmane.emacs.orgmode/48399. > > Best regards, > Seb > > -- > Sebastien Vauban > > > -- Gary
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
Carsten Dominik writes: > I am fixing this - please let me know if I should revert my fix... > > Bernt, should be working in master. Works much better! Thanks!! Bernt
Re: [O] I have terminated my assignment
Vikas Rawal writes: >> >> You also stated that the main reason for your current behavior >> >> is to delay Org 8.0, to create chaos and to annoy me. >> > >> > Yes. >> > >> >> I would suggest that further emails from Jambunathan be ignored. The >> more effort expended "reasoning" with him, the more time wasted by >> members of the Org-mode community who are valuable contributors. > > +1 > > Vikas Could someone please just ban Jambunathan from the list? These emails are not productive and are wasting everyone's time. If Jambunathan wants to discuss policy stuff with the FSF, he can do that; there's no reason to do it here on-list. However, what Jambunathan has said very explicitly is: I want to troll this list and waste everyone's time. And he said it very explicitly here: Jambunathan K writes: > Someone - it may not be you yourself - from within the community would > have paid the price for annoying me. I will try hard to extract a > price. Please stop letting him waste our time and community energy. There's no reason to keep the troll well fed by allowing him to continue these emails on-list. Thanks, - Christopher Allan Webber.
Re: [O] Org as a static site generator
Ian Barton writes: > On 01/04/13 13:08, Vincent Beffara wrote: > >> Yes, I mean, I know which html you need for that, simply within o-blog you >> need to manage between relative paths, absolute paths, canonical paths and >> so on in the template, to match the right section, - mainly it should be a >> matter of let-ing the right variable to the right value at the right point >> in the template and catching it when generating the toc, but I never took >> the time to get it right ... >>> I've also just found this, which uses Org only as a markup tool and >>> Jekyll to generate the site: >>> >>> http://orgmode.org/worg/org-tutorials/org-jekyll.html >> I had a look at the too, but it felt just a little bit too convoluted >> compared to managing everything from Org. Besides, it seems to lose >> fontification of code snippets and the like? >> >> /v >> > As the original author of that page, I agree that using Jekyll is > convoluted, but it gives you much more control. However I now use > Pelican: https://pelican.readthedocs.org/en/3.1.1/ > > There are a few reasons for this. Pelican is written in Python, which I > find easier to hack on. It is more flexible than Jekyll, which I found > hard to get to work the way I wanted with categories and tags. > > I wrote a yaml importer for Pelican so I could use my old jekyll posts. > However, Pelican understands Markdown, which I think the new exporter > supports. > > So my work flow now is Emacs-> export as html -> run Jekyll > > Ian. Heya Ian, I've been planning to switch my blog over to pelican. It's cool to hear you say this. Is there any special elisp you use for the export, including converting things like the title, etc? Thanks! - Chris
[O] SETUPFILE: file open failure hardly noticeable
Hi all I had to experience that a #+SETUPFILE: pointing to a nonexisting file results in not more than two times a (message) "Cannot read file [...]" in the messages buffer which I didn't notice in the first place. Only when I noticed that my custom todo keywords configuration was missing I started to realize what happened. (The minibuffer replaces those messages already after opening the file and I never examine the Messages buffer at that time without reason.) In the Org source code I found noerror for the two corresponding calls of org-file-contents. I tried to make the load failure more prominent but have to give up for the moment: When changing the (message) to (error) or when adding a (ding) to the (message), in my case both trigger new problems like hooks not called and messed up org-emphasis or fontify. And the (error) is noticeable only hardly again because it seems to me like catched by "File mode specification error", a behavior by design which I don't understand. Is there any opinion or help on how to improve this? Michael
Re: [O] Org-mode as a metalanguage: calling SQL "functions"
Hi Gary, I agree. Gary Oberbrunner writes: > What I'd really like in the org-mode doc somewhere (or on worg?) is the > babel syntax broken out like a traditional programming language, by which I > mean describe the syntax[es] for *defining* a function in one place > (including all the ways to define args and their default values), I believe this information is currently split between the following two manual pages. (info "(org)Structure of code blocks") (info "(org)var") > and describe the syntax[es] for *calling* a function in a separate > section (including how to pass args). This should be fairly completely addressed in the following manual page. (info "(org)Evaluating code blocks") > If the variable semantics vary by language (as they do), just say so > (e.g. when defining a SQL function, vars are substituted into the body > by prefixing the names with $, but in python they are local vars in > non-session mode and global vars in session mode and so on. Maybe > this doc section shouldn't try to enumerate all those languages, but > just redirect to the proper worg babel language page for details on > arg handling. > Yea, this could be a simple note, e.g., "the method by which variables are applied to code blocks are language-specific and determined by the semantics of the programming language of the code block, see ...". > > I think all this info is already there in one place or another, but IMHO > it's not organized in such a way that a newbie can start to use org-mode as > a metaprogramming language without lots of false starts and reading the > source (like I did). > I agree. I think this information would be best included as a new page in the manual under the working with source code section. It could link to, and be linked from the pages I reference above. I don't think it'd be overly difficult to write, and shouldn't be more than a page or two of prose, and as you say it would be very helpful for beginners. Alternately this could be a page on Worg, but I think it is important enough to be included in the manual. Would you want to take a first pass at such an addition? If not I can, but it may be a while before I get to it. Cheers, p.s. These two publications could help; a journal article on code blocks in Org-mode [1] and a shorter magazine piece on the same [2]. They both deal with meta-programming in Org-mode documents. > > > > On Thu, Apr 4, 2013 at 4:10 PM, Sebastien Vauban > wrote: > >> Eric, >> >> Eric Schulte wrote: >> > "Sebastien Vauban" writes: >> >> Eric Schulte wrote: >> > At this point I'm not sure if the documentation or the code should be >> > amended. I've personally never liked the args-in-block-name syntax, >> but >> > I don't recall if we formally decided to abandon it, or if it has >> simply >> > been broken in a recent commit. >> >> I am not sure if I have any say here, but I agree that the args in >> name notation looks not as good and might be considered for >> abolishment. >> >>> >> >>> Great, I agree wholeheartedly and I'll update the documentation >> >>> accordingly (and take a look at lob-ingest to ensure it no longer uses >> >>> this var-in-name style). >> >> >> >> I confirm that, following a discussion we had, you had decided to drop >> the >> >> alternate syntax, a couple of months ago (more than 2 ;-)). >> > >> > Great, so I'm not imagining things. Thanks Seb. >> >> For the sake of clarity, it all began (in September 2011) with the fact it >> was >> more difficult to trap errors such as missing default value, in the >> functional-syntax style. See >> http://article.gmane.org/gmane.emacs.orgmode/46888. >> >> This also lead, a couple of weeks later (October 2011), to questionning the >> multiple keywords used for code blocks, such as #+source: and #+srcname:. >> See >> http://article.gmane.org/gmane.emacs.orgmode/48399. >> >> Best regards, >> Seb >> >> -- >> Sebastien Vauban >> >> >> Footnotes: [1] http://www.jstatsoft.org/v46/i03 [2] http://cs.unm.edu/~eschulte/data/CISE-13-3-SciProg.pdf -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Commit 'cf5e96c8e1be5d0f9df2d98415f3ee16df9408f0' introduces texi syntax error
Vladimir Lomov writes: > Hello, > as topic states, I attached small patch. > > --- > WBR, Vladimir Lomov Confirmed - I ran into this yesterday and not knowing the texi syntax just deleted the brackets locally so I could get my updated info documentation :) Regards, Bernt
[O] New Exporter BUG/Change in behaviour
Hi Nicolas, I finally updated to the latest master branch at work yesterday to move to the new exporter and found the following change I don't know how to deal with. My org file has #+OPTIONS: tasks:todo This globally skips DONE tasks in my exports when I export the entire file in both the old and new exporter. If I select a task with C-c @ that is DONE (or any done state) and try to export that in the new exporter I get nothing (except an empty table of contents) -- even if the Org buffer is narrowed to only that task. The old exporter would export this anyway but it seems the new exporter is honouring the global #+OPTIONS: task:todo even when it is outside the currently narrowed buffer range. There is no local property that I am aware of to say export all todo states. I have to list them individually which isn't user-friendly so I can't reverse the global setting with a local property in my task/subtree. Having to add a property for my exports for email just to get it to override global options really isn't user-friendly since the options per file are different and the user has to know exactly what to undo (and future changes to the global options makes this a moving target) Is this a bug? My current workaround is to delete the global #+OPTIONS line (but that doesn't feel right since I have to add it back to export what is left to do for the entire file when sharing it with others). I regularly export small subtrees (with C-c @) to copy ASCII / HTML export results to emails so the old exporter behaviour was much more predictable in the results I would get when using C-c @. So far the move to the next exporter has been very easy. Great job! Regards, Bernt
Re: [O] [PATCH] Using org babel for generating ASCII art using PlantUML
Hi Mats, sorry for the late reply. Mats Kindahl writes: > I find the PlantUML support very useful to generate diagrams when > presenting designs, but unfortunately, I quite frequently have to send > simple descriptions requiring ASCII only. Since PlantUML support > generation of ASCII-art diagrams, I updated the org babel PlantUML > support to generate ASCII art in place when no :file parameter is > provided. This could be useful, yes, but we cannot apply this patch until you sign the FSF copyright assignment, as ob-plantuml.el is part of Org's core which is part of Emacs. If you want to sign the assignment, please let me know and I'll send you the details in private. Thanks! -- Bastien
Re: [O] emacs export org-mode to wiki: especially for the org-mode tables
Hi Mark, filebat Mark writes: > I badly need the feature of exporting org-mode to wiki(like > mediawiki). There is an exporter for Confluence Wiki -- maybe you can start from this and write a mediawiki exporter. Or wait for someone to write it for you! Best, -- Bastien
Re: [O] BUG typo in languages.html
Hi Andreas, Andreas Röhler writes: > http://orgmode.org/worg/org-contrib/babel/languages.html > > Language Identifier Documentation Requirements > > C c ob-doc-Cnone > > ; > > mentiones lesser "c" as Identifier, seems it should be upper "C" Not sure -- why? > BTW > > couldn't see > > http://orgmode.org/worg/org-contrib/babel/languages.html > > in Worg git-repo It's there: org-contrib/babel/languages.org HTH, -- Bastien
Re: [O] [RFC] Org syntax (draft)
Hi Waldemar, Waldemar Quevedo writes: > By the way, does it exist somewhere a set of examples of Emacs > org-mode -> html conversion for all org-mode features? Not really -- and it would be nice to have one, especially for developers like you who are in charge of an external exporter! > I am mantaining the org-ruby gem which is used to render org-mode texts to > html, > and currently there is no "roadmap" of features to implement for it. > As a result, features and tweaks are added to the library > as long as someone submits a ticket requesting the feature in Github. > (Here is a list of the export features supported in case someone wants > to take a look: > https://github.com/bdewey/org-ruby/tree/master/spec/html_examples ) > Having a set of examples features from org-mode would be very useful > to see how much coverage other implementations of org-mode exporting > features have. > > Cheers everyone, keep org-mode being an awesome tool :) Thank *you* for maintaining the org-ruby gem -- truly a gem to the github community! Hopefully you'll be able to update the gem wrt the latest syntactic changes. There are not too many of them, and not every will use Org 8.0 so soon, but still. Best, -- Bastien
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
Hi Brian, sorry for the late reply. Brian van den Broek writes: > I hope both that my description is tolerably clear and that it is some > help in the ellipses bug hunt. I must say I have been lazy and quite gave up on this "wrong ellipses" issue. Since your description involves en/decryption, I assume it does affect too many users and too many possible use-cases. Let's revisit this issue after the next major release, if someone has* the energy to put a stab at it. Thanks, -- Bastien
Re: [O] BUG docu org-babel-default-header-args
Hi Andreas, Andreas Röhler writes: > http://orgmode.org/manual/System_002dwide-header-arguments.html#System_002dwide-header-arguments > Org Mode Info > System-wide header arguments > > > System-wide values of header arguments can be specified by customizing > the `org-babel-default-header-args' variable: > > ; > > Seems not the case as in ob-core.el > > (defvar org-babel-default-header-args > > ; Not sure what you mean -- do you mean that saying "customizing" in the manual is not appropriate because `org-babel-default-header-args' is a variable (defvar) and not an option (defcustom)? Thanks for further clarification! -- Bastien
Re: [O] Org-mode as a metalanguage: calling SQL "functions"
Am 05.04.2013 18:31, schrieb Eric Schulte: [ ... ] Yea, this could be a simple note, e.g., "the method by which variables are applied to code blocks are language-specific and determined by the semantics of the programming language of the code block, see ...". Hi, still can't see the purpose of this feature. OTOH expect an eternal trouble when re-implementing. Even the notion what a variable is at all may differ a lot in languages. If you define a syntax whose results are uncertain, only work from time to time, to a limited extend, it's better to rely on native source code. Best, Andreas
Re: [O] BUG docu org-babel-default-header-args
Am 05.04.2013 19:14, schrieb Bastien: Hi Andreas, Andreas Röhler writes: http://orgmode.org/manual/System_002dwide-header-arguments.html#System_002dwide-header-arguments Org Mode Info System-wide header arguments System-wide values of header arguments can be specified by customizing the `org-babel-default-header-args' variable: ; Seems not the case as in ob-core.el (defvar org-babel-default-header-args ; Not sure what you mean -- do you mean that saying "customizing" in the manual is not appropriate because `org-babel-default-header-args' is a variable (defvar) and not an option (defcustom)? Thanks for further clarification! Hi Bastien, customization needs a defcustom, not a defvar (defvar org-babel-default-header-args '((:session . "none") (:results . "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no") (:padnewline . "yes")) "Default arguments to use when evaluating a source block.") This var user can't customize, as Info tells falsely. Cheers, Andreas
Re: [O] BUG typo in languages.html
Am 05.04.2013 19:21, schrieb Bastien: Hi Andreas, Andreas Röhler writes: http://orgmode.org/worg/org-contrib/babel/languages.html LanguageIdentifier Documentation Requirements C c ob-doc-Cnone ; mentiones lesser "c" as Identifier, seems it should be upper "C" Not sure -- why? BTW couldn't see http://orgmode.org/worg/org-contrib/babel/languages.html in Worg git-repo It's there: org-contrib/babel/languages.org HTH, wrong there also. Evaluating (org-babel-do-load-languages 'org-babel-load-languages '( (c . t))) ==> Debugger entered--Lisp error: (file-error "Cannot open load file" "ob-c") require(ob-c) #[(pair) "A\303@!\211\203 But (org-babel-do-load-languages 'org-babel-load-languages '( (C . t))) ==> ((C . t))
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
On 4/5/13, Bastien wrote: > I must say I have been lazy and quite gave up on this "wrong ellipses" > issue. Since your description involves en/decryption, I assume it does > affect too many users and too many possible use-cases. For clarity, wrong ellipses (and other non-canonical visibility issues) occur for me without encryption being involved. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] BUG typo in languages.html
Hi Andreas, Andreas Röhler writes: > wrong there also. Evaluating > > (org-babel-do-load-languages >'org-babel-load-languages >'( > (c . t))) > > ==> > Debugger entered--Lisp error: (file-error "Cannot open load file" "ob-c") > require(ob-c) > #[(pair) "A\303@!\211\203 > > But > > (org-babel-do-load-languages >'org-babel-load-languages >'( > (C . t))) > > ==> > ((C . t)) I see, fixed, thanks for the explanations. -- Bastien
Re: [O] BUG docu org-babel-default-header-args
Hi Andreas, Andreas Röhler writes: > customization needs a defcustom, not a defvar > > (defvar org-babel-default-header-args > '((:session . "none") (:results . "replace") (:exports . "code") > (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no") > (:padnewline . "yes")) > "Default arguments to use when evaluating a source block.") > > This var user can't customize, as Info tells falsely. I see. I fixed the manual instead of turning `org-babel-default-header-args' into an option. Thanks, -- Bastien
Re: [O] emacs export org-mode to wiki: especially for the org-mode tables
Thanks a lot for your information, Bastien. I'll check it out, and reply this mail loop when I have successfully met my original requirement. At 2013-04-06 01:09:41,Bastien wrote: >Hi Mark, > >filebat Mark writes: > >> I badly need the feature of exporting org-mode to wiki(like >> mediawiki). > >There is an exporter for Confluence Wiki -- maybe you can start >from this and write a mediawiki exporter. Or wait for someone >to write it for you! > >Best, > >-- > Bastien
Re: [O] New Exporter BUG/Change in behaviour
Hello, Bernt Hansen writes: > My org file has > > #+OPTIONS: tasks:todo > > This globally skips DONE tasks in my exports when I export the entire > file in both the old and new exporter. > > If I select a task with C-c @ that is DONE (or any done state) and try > to export that in the new exporter I get nothing (except an empty table > of contents) -- even if the Org buffer is narrowed to only that task. > > The old exporter would export this anyway but it seems the new exporter > is honouring the global #+OPTIONS: task:todo even when it is outside the > currently narrowed buffer range. Indeed. OPTIONS is a buffer-wide keyword. > There is no local property that I am aware of to say export all todo > states. I have to list them individually which isn't user-friendly so I > can't reverse the global setting with a local property in my > task/subtree. Having to add a property for my exports for email just to > get it to override global options really isn't user-friendly since the > options per file are different and the user has to know exactly what to > undo (and future changes to the global options makes this a moving target) > Is this a bug? No, it isn't. > My current workaround is to delete the global #+OPTIONS > line (but that doesn't feel right since I have to add it back to export > what is left to do for the entire file when sharing it with others). I > regularly export small subtrees (with C-c @) to copy ASCII / HTML export > results to emails so the old exporter behaviour was much more > predictable in the results I would get when using C-c @. The new exporter distinguishes between subtree export (toggled with C-s key within the dispatcher) and region export. In the old exporter, C-c @ + export command would give you a subtree export. This is not the case in the new exporter. You have to explicitly mention you want a subtree export. On the other hand, you don't need to select a region beforehand. In other words, you don't trigger a subtree export anymore with C-c @ (but it triggers a region export). If you export a subtree in the new exporter jargon, you can override locally #+options: line by setting top headline's :EXPORT_OPTIONS: property to an appropriate value, e. g. :EXPORT_OPTIONS: tasks:t. There is no such mechanism for a region export. But you can implement a function that will remove the OPTIONS line when buffer is narrowed: (when (buffer-narrowed-p) (org-with-wide-buffer (goto-char (point-min)) (let ((case-fold-search t)) (while (re-search-forward "^[ \t]*#\\+options:" nil t) (when (eq (org-element-type (org-element-at-point)) 'keyword) (delete-region (line-beginning-position) (progn (forward-line) (point Then add it to `org-export-before-parsing-hook'. Regards, -- Nicolas Goaziou
Re: [O] org-html-postamble-format and #+DATE: specification in 8.0pre
Hello,
> Sorry I don't get it completely.
> I'd like to have as the DATE value the current change time of the file.
> You mean that I should set this with the Emacs timestamp facility? Like:
> #+DATE: Time-stamp: " "
If you're exporting a buffer associated to a file, you may use:
#+DATE: {{{modification-time(%Y-%m-%d)}}}
Regards,
--
Nicolas Goaziou
Re: [O] org-html-postamble-format and #+DATE: specification in 8.0pre
Hello,
Alan Schmitt writes:
> I have a more serious issue: it seems that '%d' is no longer taken into
> account. To reproduce, try exporting the following:
>
> #+BEGIN_SRC org
> # -*- org-export-allow-bind-keywords: t -*-
>
> #+TITLE: Testing the date
> #+BIND: org-html-postamble-format (("en" "Test %d %a"))
>
> Hello World
> #+END_SRC
You didn't specify any date.
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] Using org babel for generating ASCII art using PlantUML
On 04/05/2013 07:05 PM, Bastien wrote: > Hi Mats, > > sorry for the late reply. > > Mats Kindahl writes: > >> I find the PlantUML support very useful to generate diagrams when >> presenting designs, but unfortunately, I quite frequently have to send >> simple descriptions requiring ASCII only. Since PlantUML support >> generation of ASCII-art diagrams, I updated the org babel PlantUML >> support to generate ASCII art in place when no :file parameter is >> provided. > This could be useful, yes, but we cannot apply this patch until you > sign the FSF copyright assignment, as ob-plantuml.el is part of Org's > core which is part of Emacs. > > If you want to sign the assignment, please let me know and I'll send > you the details in private. Thank you Bastien, I've got the necessary papers and am working on it. I don't expect any problems, it's just red tape. I'll be back once I have the signatures I need. Best wishes, Mats Kindahl > > Thanks! > -- Senior Principal Software Developer Oracle, MySQL Department
Re: [O] New Exporter BUG/Change in behaviour
Nicolas Goaziou writes: > Hello, > > Bernt Hansen writes: > >> Is this a bug? > > No, it isn't. > >> My current workaround is to delete the global #+OPTIONS >> line (but that doesn't feel right since I have to add it back to export >> what is left to do for the entire file when sharing it with others). I >> regularly export small subtrees (with C-c @) to copy ASCII / HTML export >> results to emails so the old exporter behaviour was much more >> predictable in the results I would get when using C-c @. > > The new exporter distinguishes between subtree export (toggled with C-s > key within the dispatcher) and region export. In the old exporter, C-c @ > + export command would give you a subtree export. This is not the case > in the new exporter. You have to explicitly mention you want a subtree > export. On the other hand, you don't need to select a region beforehand. > In other words, you don't trigger a subtree export anymore with C-c @ > (but it triggers a region export). > > If you export a subtree in the new exporter jargon, you can override > locally #+options: line by setting top headline's :EXPORT_OPTIONS: > property to an appropriate value, e. g. :EXPORT_OPTIONS: tasks:t. Thanks for the clarification! I'll give it a whirl :) Regards, Bernt
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
Samuel Wales writes: > For clarity, wrong ellipses (and other non-canonical visibility > issues) occur for me without encryption being involved. I know it can occur, I use Org too :) It's hard to find reproducible recipes; when we have some (like the one Brian provided), it's hard to debug; and for I cannot afford to put this as a priority as the annoyance/hard-to-debug ratio is too low IMO. Let's revive this after 8.0 if needed, -- Bastien
Re: [O] iCalendar export problem
Hello, Simon Thum writes: > However, that's not what DTSTAMP is for. Actually, it should be set to > the date-time the export happens. At least, that's what they say: > > http://stackoverflow.com/questions/11594921/whats-the-difference-between-created-and-dtstamp-in-the-icalendar-format > > Changing that probably does not help my problem, but seems better than > the cooked-up values now ending up in DTSTAMP. I could not see any > other candidate problems, though the analysis is weak so far. Thank you for the report. I pushed a fix for the DTSTAMP value. Is it better now? Regards, -- Nicolas Goaziou
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Suvayu Ali writes: > 2. Oh that's easy to solve, use maildirs (sync with OfflineIMAP). That >does not work well because Gnus uses its own flags (an example where >Gnus actually breaks standards)! There are some hacks around that >out in the wild, so let's let it slide. > 3. Gnus stores some meta information/cache for maildirs in a .nnmaildir >folder *inside* the maildir directory tree! > maildir > ├── .nnmaildir > ├── cur > ├── new > └── tmp >I do not know how, but this supposed meta information or cache takes >about 2/3 of disk space as the original maildir! Obviously that is a >problem for large mailboxes. FWIW, I use offlineimap this way, but rather than pointing gnus directly at my local maildir, I use dovecot (a small local IMAP server) as an intermediary. This method is documented here: http://roland.entierement.nu/blog/2010/09/08/gnus-dovecot-offlineimap-search-a-howto.html Note the update at the end, since dovecot's command-line interface has changed since the article was first written. I actually use: (setq gnus-select-method '(nnimap "Mail" (nnimap-shell-program "/usr/lib/dovecot/imap -c ~/.dovecotrc") (nnimap-stream shell))) So far, my emacs (which contains everything I do except Firefox) has remained responsive, and my mailstore still makes sense to K9 when I'm mobile. G
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
> > FWIW, I use offlineimap this way, but rather than pointing gnus directly > at my local maildir, I use dovecot (a small local IMAP server) as an > intermediary. This method is documented here: > > http://roland.entierement.nu/blog/2010/09/08/gnus-dovecot-offlineimap-search-a-howto.html > +1 I also use gnus, dovecot and offlineimap, and used this same page to guide my setup. Although this wasn't trivial to setup, I love the results. A responsive email/Emacs environment which is fully available allowing me to read and write mail with or without internet access (great for hour long train commutes). > > Note the update at the end, since dovecot's command-line interface has > changed since the article was first written. I actually use: > > (setq gnus-select-method '(nnimap "Mail" > (nnimap-shell-program >"/usr/lib/dovecot/imap -c ~/.dovecotrc") > (nnimap-stream shell))) > > So far, my emacs (which contains everything I do except Firefox) has > remained responsive, and my mailstore still makes sense to K9 when I'm > mobile. > > G > > -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Export a Subtree to an other .org file
Hi Nicolas, For the org-org-export-to-org function, if the input is * test #+BEGIN_SRC R -n :var a=1 a #+END_SRC the output is * test #+BEGIN_SRC R -n a #+END_SRC That is, the ":var a=1" header argument is stripped (but the "-n" switch is preserved). Is this intentional? I think /everything/ in the #+BEGIN_SRC line should be preserved. What do you think? Thanks! -- Best, Hsiu-Khuern.
Re: [O] need file+function help
Hi Subhan, Subhan Tindall writes: > questions: > 1) are the values gathered by capture available to the function > specified for file+function, & if so what are their names? No. > 2) what is the general template for a function for use with > file+function, cleanup, return values, etc that would be expected? The function is expected to find a location where to put the new entry, not to return any specific value, and if it returns a value, the value is ignored. It can also act on the subtree at the location it has found, but this is slightly abusing the feature I'd say. > 3) would it be better to extend datetree to datetree+headline for > entries of this type? it seems like it a pretty usefully > functionality to have (I can think of 2 or 3 instances i'd regularly > use this just off the top of my head "datetree+headline" is improper, because a location in a datetree is a headline... so maybe your best chance is to use (function ...) or (file+function ...) and try to see if the function can interactively prompt for the values you want and edit the location as you want. But again, this goes beyond the purpose of function, which is to find to location. -- Bastien
Re: [O] css link colors for Worg are difficult to spot
Achim Gratz writes: > Bastien altern.org> writes: >> > The angry unicorn is still in worg though ... >> >> And it's back on orgmode.org too. > > Well let me say it again, I don't like it at all. The old unicorn seemed to > be blissful, which I think is what it should feel like using Org. Besides, > the new logo has some hard-not-to-notice problems with perspective and the > anatomy of the unicorn head. If people massively vote for the come back of the old unicorn, I've nothing against it. Let's deal with this after 8.0 though. -- Bastien
Re: [O] Google Summer of Code 2013?
Hi Waldemar, Waldemar Quevedo writes: > Are there any plans to participate this year in Google Summer of Code? > (Sort of short notice since the deadline is fastly approaching: March 29) > http://www.google-melange.com/gsoc/homepage/google/gsoc2013 I do not have time to handle this this year. GSoC is nice, but the fact that students get paid and mentors don't get paid can create frustrations, especially when mentors are also active contributors of the community. It's double work for them, at least this is my experience. We were lucky enough to have three GSoC projects last year, and from all the students we had, only Thorsten continues to contribute here. This is a good result, but maybe Thorsten would have contributed anyway -- so a bit disappointing in terms of "recruitment". > Surely there are some ideas that could make it! That's for sure. Maybe next year? We can continue to store ideas on Worg any time. -- Bastien
Re: [O] [ox-html] Using a different title in the head and in the body
Hi Alan, Alan Schmitt writes: > I'm building a small web site using org-mode, and I cannot find out how > to have a short title in the head of the generated html, and a longer > one in the body. > > Is this possible? Nope, this is not possible -- or maybe a ugly hack would be to set your own ... in #+HTML_HEAD and pray so that browsers interpret the last one they see. HTH, -- Bastien
Re: [O] Question about reftex mode in org-mode
Hi Robert, "Robert P. Goldman" writes: > Anyone else seen this? Have a solution (e.g., have org files assume > that TeX-master is t)? Maybe setting TeX-master to t as a local file variable would do? -- Bastien
Re: [O] We're doing it wrong. [WAS]: Zip utility on Windows for ODT exporter
Hi John and David, If one of you can provide a patch for this, that'd be great. Thanks, -- Bastien
Re: [O] (org-table-next-row) and # - bug or feature?
Hi Thorsten, Thorsten Jolitz writes: > The problem is actually in these two lines of 'org-table-insert-row': > > ,- > | (if (string-match "^[ \t]*| *[#$] *|" line) > |(setq new (replace-match (match-string 0 line) t t new))) > `- > > looks as if its intentional, but for me this behaviour still seems > buggy. Yes, I don't know why cells with # and $ should be copied when creating a new row. I'm copying Carsten so he might explain, or remove this quirk if needed. Thanks for reporting this, -- Bastien
Re: [O] Warning while publishing
Hi François, François Pinard writes: >Warning: defvar ignored because org-agenda-archives-mode is let-bound >Warning: defvar ignored because org-agenda-skip-function is let-bound Yes, you can safely ignore those warning. -- Bastien
Re: [O] Nice blog post - Org-mode in Your Pocket Is a GNU-Shaped Devil
Hi Haider, Haider Rizvi writes: > Not exactly the above, but I have the following my-gnus-browse bound > to ; in gnus-summary-mode-map, which opens up a browser with the right > links for gwene, gmane and nnrss groups. I think the browse-nnrss-url > is untouched from the gnus manual. Thanks -- will try this! -- Bastien
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi, Achim Gratz writes: > Hudson. However, I don't think that a CI framework is what we need or > want. As I said, simply running the tests (preferrably with two different > versions of Emacs) should be enough for now. Unless we hear from Jason if > he thinks the server can take the extra load its a moot point to discuss > details, but I think this can be done in one of the Git hooks (much like > Worg triggers publishing). Yagnesh Raghava Yakkala writes: > About hudson/jenkins (any other CI), If we have resources on the server, I > would say we should go for it. That will remove Bastien's concern of slowing > down development because of running tests by hand. I'm copying Jason -- the idea is to run tests on the servers via a Git hook, the same way that a Git hook publishes Worg. If the tests fail, the committer would get a warning and the commit would be discarded. Jason, do you think it's feasible? Enough? I guess hudson/travis is really too much for our needs. Thanks, -- Bastien
Re: [O] attr_html for table.el tables?
Hi Ken, Ken Williams writes: > It looks like `#+attr_html` doesn’t have any effect on table.el > tables, correct? I think so. > Is there another mechanism to specify export > options when org-mode renders table.el tables to HTML? Nope. Usually I just enclose table.el tables into #+begin_example so that they can displayed correctly, but that's clearly not what you want. Best, -- Bastien
Re: [O] Bug with automatic alignment of table columns in HTML export
Hi Kodi, Kodi Arfer writes: > You're quite welcome. That was prompt! I see this case now works in > master. The catch is that there are still some cases which give > inconsistent alignment between Emacs and HTML export, such as: > > | a | b | > |-+---| > | 100 | 1 | > | 1 | 1 | > | 1 | 1 | > | 1 | 1 | > | a | 1 | > | | 1 | > | | 1 | > | | 1 | > | | 1 | > | | 1 | > | | 1 | For such cases, you can use this: | | | | a | b | |-+-| | 100 | 1 | | 1 | 1 | | 1 | 1 | | 1 | 1 | | a | 1 | | | 1 | | | 1 | | | 1 | | | 1 | | | 1 | | | 1 | HTH, -- Bastien
Re: [O] Maxima tests fail in devel on OSX
Hi Nicolas, "Nicolas Richard" writes: > My attempts at finding a maxima option to avoid these lines were > unsuccessful (I mainly tried adding "(setq *load-verbose* nil)" to a > maxima-init.lisp file, but that doesn't help). I suppose that ignoring > any line that begins with ";;; Loading #P" will be the easiest way. > Here's an obvious patch in that direction : Applied, thanks. -- Bastien
Re: [O] Org tutorials
Hi Charles, Charles writes: > Is there a reason why Richard Dillon's YouTube Hack Emacs org-mode talks > are not included in the Org Tutorials? For instance > > An overview of Org Mode - > > http://www.youtube.com/watch?v=6W82EdwQhxU Actually this one was already there: http://orgmode.org/worg/org-tutorials/org-screencasts/ Feel free to add others to Worg, -- Bastien
Re: [O] saving state of buffer
Hi Carsten, Carsten Dominik writes: > Here is a patch that would change the default values for bookmark-jump and > saveplace. > Bastien, what do you think? I think it's good, I've applied this -- thanks! -- Bastien
Re: [O] GFDL
Hi Marcin, Marcin Borkowski writes: > HTH anyway Well, it did! It showed that it *is* possible somehow... and thanks for the TeX lesson btw. I can't integrate this like that for now, but lets remember the hack for when we will really be annoyed again by the +10 GFDL pages. Thanks, -- Bastien
Re: [O] problem with figure captions / labels in LaTeX export
Hi Dale, Dale Barr writes: > I encountered a problem with LaTeX export that seems to affect > org-versions 7.9.3f and 7.9.4. If you can, try to use latest development version, the problem should be fixed there. Otherwise, just wait a few days and the development version will be the stable release. -- Bastien
[O] Latex export of longtable with multiline heading
Dear Org-mode people, I have an Org mode document containing a longtable, which has its heading row split over two lines. Exporting this to Latex doesn't work. Here's a really small example (for which I wouldn't need longtable, but you get the point): #+ATTR_LaTeX: longtable align=|r|r| |---+-| | First | Age | | Name | (years) | |---+-| | Bob | 6 | | Dave | 7 | | Wendy | 9 | |---+-| The PDF document is missing the first line of the header. Looking at the Latex file which is generated, there appear to be too many (i.e. 2) instances of \endhead (but I'm no expert on longtables in Latex). It's important that I get this working, or find a work-around. Any suggestions? cheers, Simon
Re: [O] Highlighting bug with org-agenda-set-restriction-lock
On 5.4.2013, at 17:48, Bernt Hansen wrote: > Carsten Dominik writes: > >> I am fixing this - please let me know if I should revert my fix... >> >> Bernt, should be working in master. > > Works much better! Thanks!! Hi Bernt, Bastien has introduced a variable for this, you need to set it to get highlight in the headline only: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=b37e27 (setq org-agenda-restriction-lock-highlight-subtree nil) The face is now less intrusive, and you can change it of course. - Carsten
