Re: [O] Re: org-src-fontify-natively makes things very, very slow
On Sun, Mar 20, 2011 at 4:34 AM, Eric S Fraga wrote: > yes, I used to use yasnippet a lot but I don't any longer. I am > actually in confusion as to which completion mechanism to use in Emacs > these days and am going a little crazy... :( I'm currently playing with > auto-complete. Why did you give up on yasnippet? -- Le
Re: [O] hide #+ lines?
Filippo A. Salustri wrote: > You're right of course. Sorry about the mixup with the attribution. There was nothing wrong with your attribution. I was just adding some information to my previous posting about who suggested the drawer solution, but more importantly, adding the bit of setup needed: I think it's important to make each thread complete or provide enough references so that future wanderers can find their way without too much trouble. > Nick, your previous post that mentioned org-drawers helped my hide the > eval line. Thanks for that. > > As for the #+BEGIN block, my installation shows these lines in a > rather gaudy orange, which I do find distracting. > I found that those lines do have their own face, so I made 'em dark > grey (my background is black). I can still see them, but it's the > text in the block that stands out now. > That sounds like a good solution. Nick
[O] Re: Org expert mode?
Rainer M Krug writes: > But following on your statement that the features will still be there, > I would actually suggest to introduce an "Org Babel Mode" which would > *disable* features like archiving - the archiving feature (very useful > for time management et al) is quite useless in the use of babel for > literate programming. This "Org Babel mode" should not be a mode for > the whole of org, but rather on a per file basis. I would suggest that archiving can fit very well into a literate programming and/or writing workflow. One can use org-archive-subtree, for instance, to remove unneeded sections of code/prose without deleting them altogether. I do this all the time when drafting a new bit of code or an essay. Best, Matt
Re: [O] hide #+ lines?
You're right of course. Sorry about the mixup with the attribution. Nick, your previous post that mentioned org-drawers helped my hide the eval line. Thanks for that. As for the #+BEGIN block, my installation shows these lines in a rather gaudy orange, which I do find distracting. I found that those lines do have their own face, so I made 'em dark grey (my background is black). I can still see them, but it's the text in the block that stands out now. Cheers. Fil On 19 March 2011 21:42, Nick Dokos wrote: > Filippo A. Salustri wrote: > >> >> On 19 March 2011 18:26, Nick Dokos wrote: >> ... >> > Another similar solution (cribbed from this list, but I don't remember >> > who suggested it) is to define a drawer and put all that stuff in it - > > That was Carsten: see > http://thread.gmane.org/gmane.emacs.orgmode/2722/focus=2732 > and there is another bit of setup needed to keep the drawer closed to begin > with. Carsten suggested > > (add-hook 'org-mode-hook > (lambda () (org-cycle-hide-drawers 'all))) > >> >> Juan & Nick, >> I like your ideas, but my case is a little different. I only want to >> hide the BEGIN/END statements, not what comes between them. >> That is, I'm using a trick Ido Magal suggested >> (http://permalink.gmane.org/gmane.emacs.orgmode/39226). >> It works fine, except I see all the distracting block directives. >> > > The first line in the posting you point to is not org-mode related at > all: it asks emacs to eval the form when the file is visited. Since > emacs requires that to be the *first* line you cannot do anything about > that. However, there is another way to specify local variables: in a > "Local variables" section at the end of the file. That *can* be put into a > drawer: > > :SETUP: > # Local variables: > # eval: (org-update-all-dblocks) > # End: > :END: > > but it becomes the "personal property" of the last headline, so if that > is folded, the drawer is completely invisible and if it's deep in the > tree it becomes difficult to find. I would put it under its own > headline, perhaps "* COMMENT setup". > > The #+BEGIN: ... / #+END surrounding the output of the dblock cannot be > hidden afaik, but are they really distracting? I find them helpful in > focusing my eyes on the output. > > Nick > > > -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: salus...@ryerson.ca http://deseng.ryerson.ca/~fil/
[O] [BUG] fill-paragraph in orgstruct mode blows up
I use orgstruct mode when composing email and fill-paragraph blew up with the following backtrace when I tried to fill a paragraph after a drawer, as described in the last paragraph of this email. :SETUP: # Local variables: # eval: (org-update-all-dblocks) -*- # End: :END: This is a dummy paragraph after the drawer. Put cursor here and call fill-paragraph after enabling orgstruct-mode. You should get the error below. Nick Org-mode version 7.5 (release_7.5.86.g6daa.dirty) , | Debugger entered--Lisp error: (wrong-type-argument stringp nil) | re-search-backward(nil nil t) | (cond ((and (looking-at item-re) (or (< ind ind-ref) (eq org-list-ending-method (quote regexp (throw (quote exit) (point))) ((<= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method (quote indent))) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at "^[ ]*#\\+end_") (re-search-backward "^[]*#\\+begin_" nil t)) ((looking-at "^[ ]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at "^[ ]*$") (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) ((< ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1))) | (let ((ind (org-get-indentation))) (cond ((and (looking-at item-re) (or (< ind ind-ref) (eq org-list-ending-method (quote regexp (throw (quote exit) (point))) ((<= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method (quote indent))) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at "^[ ]*#\\+end_") (re-search-backward "^[ ]*#\\+begin_" nil t)) ((looking-at "^[ ]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at "^[ ]*$") (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) ((< ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1 | (while t (let ((ind (org-get-indentation))) (cond ((and (looking-at item-re) (or (< ind ind-ref) (eq org-list-ending-method (quote regexp (throw (quote exit) (point))) ((<= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method (quote indent))) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at "^[ ]*#\\+end_") (re-search-backward "^[]*#\\+begin_" nil t)) ((looking-at "^[ ]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at "^[ ]*$") (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) ((< ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1) | (catch (quote exit) (while t (let ((ind (org-get-indentation))) (cond ((and (looking-at item-re) (or (< ind ind-ref) (eq org-list-ending-method ...))) (throw (quote exit) (point))) ((<= (point) lim-up) (throw (quote exit) nil)) ((and (not (eq org-list-ending-method ...)) (looking-at org-list-end-re)) (throw (quote exit) nil)) ((looking-at "^[]*#\\+end_") (re-search-backward "^[]*#\\+begin_" nil t)) ((looking-at "^[ ]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at "^[ ]*$") (forward-line -1)) ((zerop ind) (throw (quote exit) nil)) ((< ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1)) | (cond ((eq (nth 2 context) (quote invalid)) nil) ((looking-at item-re) (point)) (t (let ((hl 0) (i -1) end-bounds) (when (and (not (eq org-list-ending-method (quote indent))) (progn (while (setq i ...) (setq hl ...)) (setq end-bounds (org-in-regexp org-list-end-re hl))) (>= (point) (car end-bounds)) (< (point) (cdr end-bounds))) (goto-char (car end-bounds)) (forward-line -1))) (catch (quote exit) (while t (let ((ind (org-get-indentation))) (cond ((and ... ...) (throw ... ...)) ((<= ... lim-up) (throw ... nil)) ((and ... ...) (throw ... nil)) ((looking-at "^[ ]*#\\+end_") (re-search-backward "^[]*#\\+begin_" nil t)) ((looking-at "^[ ]*:END:") (re-search-backward org-drawer-regexp nil t) (beginning-of-line)) ((and inlinetask-re ...) (org-inlinetask-goto-beginning) (forward-line -1)) ((looking-at "^[]*$") (forward-line -1)) ((zerop ind) (throw ... nil)) ((< ind ind-ref) (setq ind-ref ind) (forward-line -1)) (t (forward-line -1 | (let* ((case-fold-search t) (context (org-list-context)) (lim-up (car context)) (inlinetask-re (and (featurep (quote org-inlinetask)) (org-inlinetask-outline-regexp))) (item-re (org-item-re)) (ind-ref (if (or (looking-at "^[]*$") (and inlinetask-re (looking-at inlinetask-re))) 1 (org-get-indentation (cond ((eq (nth
Re: [O] hide #+ lines?
Filippo A. Salustri wrote: > > On 19 March 2011 18:26, Nick Dokos wrote: > ... > > Another similar solution (cribbed from this list, but I don't remember > > who suggested it) is to define a drawer and put all that stuff in it - That was Carsten: see http://thread.gmane.org/gmane.emacs.orgmode/2722/focus=2732 and there is another bit of setup needed to keep the drawer closed to begin with. Carsten suggested (add-hook 'org-mode-hook (lambda () (org-cycle-hide-drawers 'all))) > > Juan & Nick, > I like your ideas, but my case is a little different. I only want to > hide the BEGIN/END statements, not what comes between them. > That is, I'm using a trick Ido Magal suggested > (http://permalink.gmane.org/gmane.emacs.orgmode/39226). > It works fine, except I see all the distracting block directives. > The first line in the posting you point to is not org-mode related at all: it asks emacs to eval the form when the file is visited. Since emacs requires that to be the *first* line you cannot do anything about that. However, there is another way to specify local variables: in a "Local variables" section at the end of the file. That *can* be put into a drawer: :SETUP: # Local variables: # eval: (org-update-all-dblocks) # End: :END: but it becomes the "personal property" of the last headline, so if that is folded, the drawer is completely invisible and if it's deep in the tree it becomes difficult to find. I would put it under its own headline, perhaps "* COMMENT setup". The #+BEGIN: ... / #+END surrounding the output of the dblock cannot be hidden afaik, but are they really distracting? I find them helpful in focusing my eyes on the output. Nick
Re: [O] gnowsys-mode update?
I too am interested in gnowsys-mode and have been meaning to look more deeply into it. I remember reviewing gnowsys-mode and it looked very interesting and related to the "semantic web" and there was a semantic web workshop in Reston, VA recently--gnowsys-mode was on the agenda. THere may be some exciting apps one could make with a mashup with org-mode and gnowsys-mode (with one or the other as an emacs sub/"minor-mode"). On Sat, Mar 19, 2011 at 6:33 PM, Martin Weigele wrote: > Thank you very much Nagarjuna G - > > Am Samstag, 19. März 2011, 12:19:46 schrieb Nagarjuna G: > > On Fri, Mar 18, 2011 at 8:25 PM, Martin Weigele > wrote: > > > Hi all, > > > > > > I've run into some texts about "gnowsys" as a major mode extending org, > > > > >... > >... > > Yes. We use the gnowsys-mode interface for sites running using > > gnowsys. So far this is the only complete interface for gnowsys. > > Mostly used by the developers and those who maintain the sites, such > > as atlas.gnowledge.org > > > > OK I understand now the starting point to understand gnowsys, and, hence, > for gnowsys on top of orgmode is > http://www.gnu.org/software/gnowsys . > > This is so great. > > > I am glad that somewhere some one is interested in this project. It > > is very encouraging. Let me know what kind of usecase you have > > thought about for using gnowsys-mode. > > > The project is even in pre-infancy state, but it is about using such > modelling to understand and learn structures in humanities (for me coming > from > a CS background). > > Martin > >
Re: [O] sitemap seems to cache old #+TITLE
Bastien writes: > This was a bug in Org 7.5 which has been fixed in Org 7.5 -- Ahem -- I mean it was a bug in Org 7.4, of course. -- Bastien
Re: [O] sitemap seems to cache old #+TITLE
Hi, lbml...@hethcote.com writes: > At one point in the recent past I had a file org.org with > #+TITLE: LBM TCH KB Org > > Eventually I changed it to be > #+TITLE: KBorg > > no matter what I do, the generated sitemap pick up the old title. This was a bug in Org 7.5 which has been fixed in Org 7.5 -- upgrading to the latest release should fix your problem. HTH, -- Bastien
Re: [O] sitemap seems to cache old #+TITLE
I see that the old title is cached in ~/.org-timestamps, I'll try clearing that and see what happens. L On Sat, 19 Mar 2011, lbml...@hethcote.com wrote: On Sat, 19 Mar 2011, Carsten Dominik wrote: On 19.3.2011, at 04:13, lbml...@hethcote.com wrote: Have you tried forcing republishing of all files by using a C-u prefix to your publishing command? I have now, and there is no change in result. C-u C-c C-e P does cause a longer export/publish time but result appears the same. - Carsten Louis
Re: [O] hide #+ lines?
Juan & Nick,
I like your ideas, but my case is a little different. I only want to
hide the BEGIN/END statements, not what comes between them.
That is, I'm using a trick Ido Magal suggested
(http://permalink.gmane.org/gmane.emacs.orgmode/39226).
It works fine, except I see all the distracting block directives.
Cheers.
Fil'
On 19 March 2011 18:26, Nick Dokos wrote:
> Juan Pechiar wrote:
>
>> On Sat, Mar 19, 2011 at 05:27:23PM -0400, Filippo A. Salustri wrote:
>> > I've started using #+ blocks here and there, and (meaning no
>> > disrespect) I find them a bit ugly. I would much rather there were
>> > some way to hide the #+ directives (without, of course, impeding their
>> > functionality).
>> > I believe I've done my due diligence, checking doc & google, but I
>> > can't find anything to help.
>> >
>> > Anyone got something to offer?
>>
>> If you are referring to directives such as export templates, etc.,
>> these can in general be placed anywhere in the document. For example,
>> inside a COMMENT'ed heading at the end of the document, with folded
>> view as default.
>>
>> You can also have all that in another file and use #+setupfile or
>> #include for inclusion.
>>
>> Other things such as #+category have their equivalent as properties,
>> which are normally folded.
>
> Another similar solution (cribbed from this list, but I don't remember
> who suggested it) is to define a drawer and put all that stuff in it -
> isn't that what drawers are for? :-) Keep the drawer closed and the mess
> is hidden - and it is not affected by general visibility cycling: you
> have to open the drawer deliberately.
>
> The top of one of my org files looks like this:
>
> --8<---cut here---start->8---
> :SETUP:
> #+STARTUP: showall lognotedone
> #+SEQ_TODO: TODO(t) STARTED(s) WAITING(w) | DONE(d) DEFERRED CANCELLED(c)
> #+TAGS: { FINANCES(f) HOME(h) PACC(p) SCHOOL(s) WORK(w) } CALL(c) ERRAND(e)
> :END:
> --8<---cut here---end--->8---
>
> You need to set up the variable org-drawers - see section 2.8 of the Org
> manual.
>
> Nick
>
--
Filippo A. Salustri, Ph.D., P.Eng.
Mechanical and Industrial Engineering
Ryerson University
350 Victoria St, Toronto, ON
M5B 2K3, Canada
Tel: 416/979-5000 ext 7749
Fax: 416/979-5265
Email: salus...@ryerson.ca
http://deseng.ryerson.ca/~fil/
Re: [O] gnowsys-mode update?
Thank you very much Nagarjuna G - Am Samstag, 19. März 2011, 12:19:46 schrieb Nagarjuna G: > On Fri, Mar 18, 2011 at 8:25 PM, Martin Weigele wrote: > > Hi all, > > > > I've run into some texts about "gnowsys" as a major mode extending org, > > >... >... > Yes. We use the gnowsys-mode interface for sites running using > gnowsys. So far this is the only complete interface for gnowsys. > Mostly used by the developers and those who maintain the sites, such > as atlas.gnowledge.org > OK I understand now the starting point to understand gnowsys, and, hence, for gnowsys on top of orgmode is http://www.gnu.org/software/gnowsys . This is so great. > I am glad that somewhere some one is interested in this project. It > is very encouraging. Let me know what kind of usecase you have > thought about for using gnowsys-mode. > The project is even in pre-infancy state, but it is about using such modelling to understand and learn structures in humanities (for me coming from a CS background). Martin
Re: [O] hide #+ lines?
Juan Pechiar wrote:
> On Sat, Mar 19, 2011 at 05:27:23PM -0400, Filippo A. Salustri wrote:
> > I've started using #+ blocks here and there, and (meaning no
> > disrespect) I find them a bit ugly. I would much rather there were
> > some way to hide the #+ directives (without, of course, impeding their
> > functionality).
> > I believe I've done my due diligence, checking doc & google, but I
> > can't find anything to help.
> >
> > Anyone got something to offer?
>
> If you are referring to directives such as export templates, etc.,
> these can in general be placed anywhere in the document. For example,
> inside a COMMENT'ed heading at the end of the document, with folded
> view as default.
>
> You can also have all that in another file and use #+setupfile or
> #include for inclusion.
>
> Other things such as #+category have their equivalent as properties,
> which are normally folded.
Another similar solution (cribbed from this list, but I don't remember
who suggested it) is to define a drawer and put all that stuff in it -
isn't that what drawers are for? :-) Keep the drawer closed and the mess
is hidden - and it is not affected by general visibility cycling: you
have to open the drawer deliberately.
The top of one of my org files looks like this:
--8<---cut here---start->8---
:SETUP:
#+STARTUP: showall lognotedone
#+SEQ_TODO: TODO(t) STARTED(s) WAITING(w) | DONE(d) DEFERRED CANCELLED(c)
#+TAGS: { FINANCES(f) HOME(h) PACC(p) SCHOOL(s) WORK(w) } CALL(c) ERRAND(e)
:END:
--8<---cut here---end--->8---
You need to set up the variable org-drawers - see section 2.8 of the Org manual.
Nick
Re: [O] hide #+ lines?
Hi, If you are referring to directives such as export templates, etc., these can in general be placed anywhere in the document. For example, inside a COMMENT'ed heading at the end of the document, with folded view as default. You can also have all that in another file and use #+setupfile or #include for inclusion. Other things such as #+category have their equivalent as properties, which are normally folded. Regards, .j. On Sat, Mar 19, 2011 at 05:27:23PM -0400, Filippo A. Salustri wrote: > I've started using #+ blocks here and there, and (meaning no > disrespect) I find them a bit ugly. I would much rather there were > some way to hide the #+ directives (without, of course, impeding their > functionality). > I believe I've done my due diligence, checking doc & google, but I > can't find anything to help. > > Anyone got something to offer?
Re: [O] Having problem with latex export of image file
On 3/17/11 Mar 17 -4:35 AM, Bastien wrote: > Hi Nick, > > Nick Dokos writes: > >> I didn't look very hard, but I didn't find documentation on these. > > If Robert or you can provide a documentation patch for this, it would > be nice. It's not (only) laziness from me: since you stumbled on the > issue, I guess you can better explain what is at stake. > > Thanks! > I'm ordinarily willing to chime in with a manual patch, but this seems odd enough that I wonder if there isn't a bug that needs fixing. In particular, it seems very weird to me that the latex exporter would treat un-directoried pathnames as files to be exported as links rather than inline images *even if there is a #+CAPTION present*. Is it worth re-examining this, instead of documenting it? cheers, r
Re: [O] sitemap seems to cache old #+TITLE
On Sat, 19 Mar 2011, Carsten Dominik wrote: On 19.3.2011, at 04:13, lbml...@hethcote.com wrote: Have you tried forcing republishing of all files by using a C-u prefix to your publishing command? I have now, and there is no change in result. C-u C-c C-e P does cause a longer export/publish time but result appears the same. - Carsten Louis
[O] hide #+ lines?
Hi, I've started using #+ blocks here and there, and (meaning no disrespect) I find them a bit ugly. I would much rather there were some way to hide the #+ directives (without, of course, impeding their functionality). I believe I've done my due diligence, checking doc & google, but I can't find anything to help. Anyone got something to offer? Cheers. Fil -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: salus...@ryerson.ca http://deseng.ryerson.ca/~fil/
Re: [O] Re: Making GTD more mangeable with org
Marcelo de Moraes Serpa writes: > Thanks, this works for me :) > > Anyway, I just wanted to debate over this particular overview file. > Not sure if this really worths it, but has been working for me lately. > You guys use something similar? For day to day GTD type things, the agenda with diary entries and todos works perfectly for me. For individual tasks, the outline and specific sparse-tree views of the file(s) associated with that task will give me everything else I need! I start my working day with three things, all within emacs (as the focal point of my computer interactions most of the day): eshell, agenda day view for today, and gnus. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
suvayu ali writes: > 2011/3/19 Sébastien Vauban : >>> My solution, by the way, is to insert the #+end_src line immediately upon >>> writing a #+begin_src line and then back up a line to start writing the > >>> code. >> >> "My" solution is even simpler: just use a yasnippet template, that prompts >> you >> for the language and puts the begin/end upfront: > > Or use org's own template mechanism[fn:1], > > 1. 2. > and so on ... > > Footnotes: > > [fn:1] [[info:org#Easy%20Templates][info:org#Easy Templates]] Thanks for this! I am always forgetting about these and they do work well. For some reason, I always find it difficult to find them in the info manual. I guess it's because I don't think of them as templates and always search for "short-cut" and "abbreviation" in the table of contents for the org manual and neither is useful. Could I suggest that maybe the heading for this section be something like "Short-cut keys for easy templates"? Or something similar? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Sébastien Vauban writes: > Hi Eric, > > Eric S Fraga wrote: [...] >> where there is no matching #+end_src or, more precisely, the next #+end_src >> line is one that does not belong to this current source block. Your search >> (in org.el) for the end of the block assumes that it does have the end >> statement in place already. I'm not sure how to fix this because it's an >> ill-defined situation. > > You say "your search..." but I only added the overlay-put command... and I > must admit this whole block is difficult to follow (so many cases). Yes but the overlay needs to know where to end; I am using search in a more general sense here in that you are defining the start and end of a region to overlay using regular expressions, are you not? [...] >> My solution, by the way, is to insert the #+end_src line immediately upon >> writing a #+begin_src line and then back up a line to start writing the >> code. > > "My" solution is even simpler: just use a yasnippet template, that prompts you > for the language and puts the begin/end upfront: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
[O] Re: [Accepted] org-export-preprocess-string: Use backend var
Matt Lundin writes: > Jambunathan K writes: > This patch (0135cb9c) breaks Wes Hardaker's generic export (in contrib). > > Since the backend is nil, the following line causes org-export to try to > require org-nil: > > (require (intern (concat "org-" backend-name)) nil) > > Debugger entered--Lisp error: (file-error "Cannot open load file" "org-nil") > require(org-nil nil) > > I ask because even though org-export-generic.el is a contributed > package, an option to call it is hard-coded into org-export: > > \[g] export using Wes Hardaker's generic exporter I missed Nick's earlier patch to fix this. Everything is working properly now. Sorry for the noise. Best, Matt
Re: [O] Bug: Recurring items don't always show up in timeline
Chris Randle wrote:
> On 2011-03-18 21:20, Nick Dokos wrote:
> > Mark S wrote:
> >
> >> I posted this before as a question, but since it has been confirmed by
> >> others, and shows up under Linux and Windows, I'll now post the
> >> details as a bug.
> >>
> >> The Timeline view *would* be very useful for scheduling months in
> >> advance, reviewing history, or printing a year event
> >> calendar. Unfortunately, it appears that it can't really be trusted.
> >> The basic problem is that in AGENDA TIMELINE view ("C-a L") recurring
> >> items are frequently and unpredictably dropped from the view. The
> >> regular AGENDA view works fine AFAIK -- its the TIMELINE that is at
> >> issue.
> >
> > AFAICT, the culprit is org-get-all-dates: it matches date strings,
> > translates
> > to number of days since the (imaginary) date 0001-12-31bce,
> > accumulates them in a list, sorts them, takes care of gaps - but
> > completely ignores any repeaters: iow, the "don't always show" in the
> > Subject line should more accurately say "never show".
>
> Unless I'm missing something (again!), when I try it, they *do* repeat
> *sometimes*. For example, the entry
>
> TODO [#A] Bath for dog <2011-03-10 Thu +1w>
>
> appears in agenda timeline as follows:
>
> 2011-03-10, miss 1 week, 2011-03-24, 2011-03-31, 2011-04-07, miss 7
> weeks, 2011-06-02, miss 8 weeks (agenda terminates 2011-07-31).
>
That's true. I believe that's when it coincides with another entry: it
sneaks in on the heels of the other entry. But I may very well be wrong:
I have only scratched the surface a bit.
Nick
Re: [O] OT: Another great application for Org
On Sat, Mar 19, 2011 at 6:33 PM, Carsten Dominik wrote: > Another great way to use Org-mode.. > > http://xkcd.com/874/ > Sounds like me alright (minus the blog post bit ;-) ) Thanks for sharing. -- Manish
Re: [O] Re: [Bug] MCE for HTML test of export
On Sat, Mar 19, 2011 at 22:55, Nicolas wrote: > [snip] > >>> Also, you may have a look at default templates, as your HTML variant is >>> slightly wrong (wrt tag). > >> I'm not sure to understand what's "wrong". You mean the fact I added manually >> a tag after the title? > > I just meant that you could replace by . I think both are > valid HTML-wise, but Emacs doesn't report an error with the latter. is valid HTML, is valid XHTML. Browsers will treat both the same way in almost every case since it’s all tag soup to them.[1] Org uses XHTML as far as I can tell, so is the correct choice here. Aankhen [1]: Unless you’re serving it up as real XHTML, which I highly doubt. ;-)
Re: [O] Bug: Recurring items don't always show up in timeline
On 2011-03-18 21:20, Nick Dokos wrote:
Mark S wrote:
I posted this before as a question, but since it has been confirmed by
others, and shows up under Linux and Windows, I'll now post the
details as a bug.
The Timeline view *would* be very useful for scheduling months in
advance, reviewing history, or printing a year event
calendar. Unfortunately, it appears that it can't really be trusted.
The basic problem is that in AGENDA TIMELINE view ("C-a L") recurring
items are frequently and unpredictably dropped from the view. The
regular AGENDA view works fine AFAIK -- its the TIMELINE that is at
issue.
AFAICT, the culprit is org-get-all-dates: it matches date strings, translates
to number of days since the (imaginary) date 0001-12-31bce,
accumulates them in a list, sorts them, takes care of gaps - but
completely ignores any repeaters: iow, the "don't always show" in the
Subject line should more accurately say "never show".
Unless I'm missing something (again!), when I try it, they *do* repeat
*sometimes*. For example, the entry
TODO [#A] Bath for dog <2011-03-10 Thu +1w>
appears in agenda timeline as follows:
2011-03-10, miss 1 week, 2011-03-24, 2011-03-31, 2011-04-07, miss 7
weeks, 2011-06-02, miss 8 weeks (agenda terminates 2011-07-31).
--
Chris Randle
[O] Re: Merging .org files
On Sat, Mar 19, 2011 at 18:23, Matt Lundin wrote: > Aankhen writes: >> [snip] >> >> Do you normally have ‘org-completion-use-ido’ turned off or something? >> (Just wondering why you couldn’t use ‘org-refile’ directly.) > > Yes, that is correct. I normally have org-completion-use-ido turned off. > > You could easily call org-refile with a prefix argument directly from > within an org-buffer. However, I find it more convenient to bind > "(org-refile t)" to one of the function keys than to type C-u C-c C-w. > The latter works only on org buffers, while the former is global. > Moreover, when navigating org files in this way, I only want to see > first level headlines, whereas my default refile binding uses deeper > levels. A’right, makes sense. I appreciate the detailed explanation. Aankhen
[O] Re: [Bug] MCE for HTML test of export
Hello, Sébastien Vauban writes: > Perfect. Works like a charm. Please do apply it... Done. >> Also, you may have a look at default templates, as your HTML variant is >> slightly wrong (wrt tag). > I'm not sure to understand what's "wrong". You mean the fact I added manually > a tag after the title? I just meant that you could replace by . I think both are valid HTML-wise, but Emacs doesn't report an error with the latter. Regards, -- Nicolas
[O] BUG: time entry window scrollbar always scrolls right
In the time entry prompt "C-c !", when I press the up or down on the scroll-bar right scroll happens. -- Le
[O] Re: Capture question
On Sat, 19 Mar 2011 10:41:34 -0400 Matt Lundin wrote: > Suvayu Ali writes: > > > As far as I understand GMail sends a multipart message, plain text > > and html mixed. I can't comment further as I don't know much more > > about email technologies and standards. > > And FWIW, Gnus users can make sure they don't see the html parts of > multipart/alternative messages sent by Gmail by setting the variable > mm-discouraged-alternatives or by converting the html to text via > mm-text-html-renderer. > > This doesn't fix the underlying problem of Gmail users sending > multipart messages, but it at least makes the emails readable. Something similar with claws and thunderbird. With claws by default it strips all html and shows only plain text and for Tbird, you can configure it to do that. :) -- Suvayu Open source is the future. It sets us free.
[O] Re: Capture question
Suvayu Ali writes: > As far as I understand GMail sends a multipart message, plain text > and html mixed. I can't comment further as I don't know much more about > email technologies and standards. And FWIW, Gnus users can make sure they don't see the html parts of multipart/alternative messages sent by Gmail by setting the variable mm-discouraged-alternatives or by converting the html to text via mm-text-html-renderer. This doesn't fix the underlying problem of Gmail users sending multipart messages, but it at least makes the emails readable. Best, Matt
Re: [O] OT: Another great application for Org
On Sat, Mar 19, 2011 at 8:03 AM, Carsten Dominik wrote: > > Another great way to use Org-mode.. > > http://xkcd.com/874/ > That is *fantastic*. Maybe if I actually wrote out a plan like that on a schedule, I'd feel better about myself... since that's about how things often happen :)
Re: [O] Re: Symbol's function definition is void: org-datetree-find-year-create / autoload org-datetree library?
On 19.3.2011, at 14:51, Matt Lundin wrote:
> "Urs Rau (UK)" writes:
>
>> On latest git version release_7.4-419-g68114f, [Org-mode version 7.4
>> (release_7.4.419.g68114f)] , I am trying to archive to a date-tree and
>> get the error:
>>
>> Symbol's function definition is void: org-datetree-find-year-create
>>
>> I found that if I '(load "org-datetree.el")' in the scratch buffer, it then
>> succeeds.
>>
>> Does org-datetree not get auto-loaded?
>
> I mentioned this in a previous email, but I'll elaborate a bit here.
> Only one function from org-datetree is autoloaded:
> org-datetree-find-date-create. None of the other functions is loaded
> until this function is called *or* until you evaluate (require
> 'org-datetree).
>
> To solve the problem, you could either rewrite the defadvice to use
> org-datetree-find-date-create or add (require 'org-datetree) to your
> emacs.
A third possibility it to wrap the defadvice form into
(eval-after-load "org-datetree"
'(defadvice..
)
This will wait for the time when org-datetree is loaded.
Cheers
- Carsten
>
> To change the advice, simply replace the following lines
>
> --8<---cut here---start->8---
> (org-datetree-find-year-create y)
> (org-datetree-find-month-create y m)
> (org-datetree-find-day-create y m d)
> --8<---cut here---end--->8---
>
> with
>
> --8<---cut here---start->8---
> (org-datetree-find-date-create `(,m ,d ,y))
> --8<---cut here---end--->8---
>
>> Also I have searched the *.el files to find the definition of
>> "org-datetree-find-year-create" and found inconsistent use of the
>> "keep-restriction" check, sometimes it is all lower case, sometimes it
>> is all uppercase, I guess lisp is not case sensitive?
>>
>> $ find ./ -type f -exec grep -i "keep-restriction" {} /dev/null \;
>> ./lisp/org-agenda.el: (date &optional keep-restriction))
>> ./lisp/org-capture.el: (DATE &optional KEEP-RESTRICTION))
>> ./lisp/org-datetree.el:(defun org-datetree-find-date-create (date &optional
>> keep-restriction)
>> ./lisp/org-datetree.el:If KEEP-RESTRICTION is non-nil, do not widen the
>> buffer.
>> ./lisp/org-datetree.el:(or keep-restriction (widen))
>
> Look at the context in which the uppercase occurs (e.g., a docstring).
>
> Best,
> Matt
>
[O] Re: Symbol's function definition is void: org-datetree-find-year-create / autoload org-datetree library?
"Urs Rau (UK)" writes:
> On latest git version release_7.4-419-g68114f, [Org-mode version 7.4
> (release_7.4.419.g68114f)] , I am trying to archive to a date-tree and
> get the error:
>
> Symbol's function definition is void: org-datetree-find-year-create
>
> I found that if I '(load "org-datetree.el")' in the scratch buffer, it then
> succeeds.
>
> Does org-datetree not get auto-loaded?
I mentioned this in a previous email, but I'll elaborate a bit here.
Only one function from org-datetree is autoloaded:
org-datetree-find-date-create. None of the other functions is loaded
until this function is called *or* until you evaluate (require
'org-datetree).
To solve the problem, you could either rewrite the defadvice to use
org-datetree-find-date-create or add (require 'org-datetree) to your
emacs.
To change the advice, simply replace the following lines
--8<---cut here---start->8---
(org-datetree-find-year-create y)
(org-datetree-find-month-create y m)
(org-datetree-find-day-create y m d)
--8<---cut here---end--->8---
with
--8<---cut here---start->8---
(org-datetree-find-date-create `(,m ,d ,y))
--8<---cut here---end--->8---
> Also I have searched the *.el files to find the definition of
> "org-datetree-find-year-create" and found inconsistent use of the
> "keep-restriction" check, sometimes it is all lower case, sometimes it
> is all uppercase, I guess lisp is not case sensitive?
>
> $ find ./ -type f -exec grep -i "keep-restriction" {} /dev/null \;
> ./lisp/org-agenda.el: (date &optional keep-restriction))
> ./lisp/org-capture.el: (DATE &optional KEEP-RESTRICTION))
> ./lisp/org-datetree.el:(defun org-datetree-find-date-create (date &optional
> keep-restriction)
> ./lisp/org-datetree.el:If KEEP-RESTRICTION is non-nil, do not widen the
> buffer.
> ./lisp/org-datetree.el:(or keep-restriction (widen))
Look at the context in which the uppercase occurs (e.g., a docstring).
Best,
Matt
[O] Re: [Accepted] org-export-preprocess-string: Use backend var
Jambunathan K writes: > Bastien > >>> + ;; Backend-specific preprocessing >>> + (let* ((backend-name (symbol-name backend)) >>> +(f (intern (format "org-export-%s-preprocess" backend-name >>> + (require (intern (concat "org-" backend-name)) nil) >>> + (funcall f parameters)) > > A few words of explanation from my side. > > Summary: Facilitate transparent plugging-in of per-backend > pre-processing logic to the org exporter. > > Jambunathan K. > This patch (0135cb9c) breaks Wes Hardaker's generic export (in contrib). Since the backend is nil, the following line causes org-export to try to require org-nil: (require (intern (concat "org-" backend-name)) nil) --8<---cut here---start->8--- Debugger entered--Lisp error: (file-error "Cannot open load file" "org-nil") require(org-nil nil) --8<---cut here---end--->8--- I ask because even though org-export-generic.el is a contributed package, an option to call it is hard-coded into org-export: --8<---cut here---start->8--- \[g] export using Wes Hardaker's generic exporter --8<---cut here---end--->8--- Best, Matt
[O] OT: Another great application for Org
Another great way to use Org-mode.. http://xkcd.com/874/
[O] Re: Merging .org files
Aankhen writes: > On Sat, Mar 19, 2011 at 02:08, Matt Lundin wrote: >> Pere Quintana Seguí writes: >> >>> Now I have to learn to better navigate within my much longer org files. >>> Before, I used ido-mode to jump from buffer to buffer, now I guess I >>> have to practise more sparse trees to jump from headline to headline. >> >> I use this function to jump quickly (via ido) to a first level headline >> in my org files: >> >> [snip] > > Do you normally have ‘org-completion-use-ido’ turned off or something? > (Just wondering why you couldn’t use ‘org-refile’ directly.) Yes, that is correct. I normally have org-completion-use-ido turned off. You could easily call org-refile with a prefix argument directly from within an org-buffer. However, I find it more convenient to bind "(org-refile t)" to one of the function keys than to type C-u C-c C-w. The latter works only on org buffers, while the former is global. Moreover, when navigating org files in this way, I only want to see first level headlines, whereas my default refile binding uses deeper levels. Best, Matt
Re: [O] Re: org-src-fontify-natively makes things very, very slow
2011/3/19 Sébastien Vauban : >> My solution, by the way, is to insert the #+end_src line immediately upon >> writing a #+begin_src line and then back up a line to start writing the >> code. > > "My" solution is even simpler: just use a yasnippet template, that prompts you > for the language and puts the begin/end upfront: Or use org's own template mechanism[fn:1], 1.
Re: [O] [PATCH] Bugfix: org-agenda-open-link
Bert Burgemeister writes:
> * Org-agenda.el (org-agenda-open-link): C-c C-o didn't open links
> inserted via the `%%( )' mechanism, affecting usability of
> `%%(org-bbdb-anniversaries).
>
> TINYCHANGE
> ---
>
>
> The bug was apparently introduced in commit
> ba1e90893d128d8004e4cb6763af692c5a6cd677.
>
> --
> Bert
>
>
>
> lisp/org-agenda.el | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 4b4dd68..123668c 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -6742,13 +6742,13 @@ at the text of the entry itself."
> (+ (point-at-bol)
>(or (org-get-at-bol 'prefix-length) 0)
> (cond
> - (buffer
> - (with-current-buffer buffer
> - (save-excursion
> - (save-restriction
> - (widen)
> - (goto-char marker)
> - (org-offer-links-in-entry arg prefix)
> + ((and buffer
> +(with-current-buffer buffer
> + (save-excursion
> +(save-restriction
> + (widen)
> + (goto-char marker)
> + (org-offer-links-in-entry arg prefix))
> ((or (org-in-regexp (concat "\\(" org-bracket-link-regexp "\\)"))
> (save-excursion
> (beginning-of-line 1)
Ok, perhaps I should complement my patch with a bug report.
%%(org-bbdb-anniversaries) inserts birthdays into the agenda that
contain links to the respective BBDB entry. These links are broken.
Here is a demonstration of the bug that doesn't require BBDB. Put the
following line into one of your agenda files:
%%((lambda () (concat "[[" "http" "://example.com" "]" "]")))
M-x org-agenda-list now includes decent links to http://example.com.
C-c C-o on one of them answers "No links".
--
Bert
[O] Re: org-advertized-archive-subtree: Symbol's function definition is void: org-datetree-find-year-create
Urs Rau writes: > I am trying to archive completed tasks to a datetree. I am using "Move > Subtree to Archive file" (C-c C-x -C-s) And I get the following error: > > release_7.4-419-g68114f > Org-mode version 7.4 (release_7.4.419.g68114f) > afile=/Users/ursr/org/tasksnotes.org_archive > org-advertized-archive-subtree: Symbol's function definition is void: > org-datetree-find-year-create I think you'll need (require 'org-datetree) in your .emacs. The problem is that the advice calls functions from that file that are not autoloaded. Best, Matt > > And I had done a C-c C-x ! to reload all org files, jsut in case. ;-) > > I have added the following settings taken from the worg site page: > http://orgmode.org/worg/org-hacks.html > > Topic: Archive in a date tree > Posted to Org-mode mailing list by Osamu Okano > > (setq org-archive-location "%s_archive::date-tree") > (defadvice org-archive-subtree > (around org-archive-subtree-to-data-tree activate) > "org-archive-subtree to date-tree" > (if > (string= "date-tree" >(org-extract-archive-heading > (org-get-local-archive-location))) > (let* ((dct (decode-time (org-current-time))) > (y (nth 5 dct)) > (m (nth 4 dct)) > (d (nth 3 dct)) > (this-buffer (current-buffer)) > (location (org-get-local-archive-location)) > (afile (org-extract-archive-file location)) > (org-archive-location > (format "%s::*** %04d-%02d-%02d %s" afile y m d > (format-time-string "%A" (encode-time 0 0 0 d m y) > (message "afile=%s" afile) > (unless afile > (error "Invalid `org-archive-location'")) > (save-excursion > (switch-to-buffer (find-file-noselect afile)) > (org-datetree-find-year-create y) > (org-datetree-find-month-create y m) > (org-datetree-find-day-create y m d) > (widen) > (switch-to-buffer this-buffer)) > ad-do-it) > ad-do-it)) > ;; > > How do I fix this and make sure I can file into a datetree? Also is > this going to be based on USA dates or will it work right with > European dates? > > Thanks. > > -- > Urs Rau > > ___ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [O] gnowsys-mode update?
On Fri, Mar 18, 2011 at 8:25 PM, Martin Weigele wrote: > Hi all, > > I've run into some texts about "gnowsys" as a major mode extending org, > > e.g. > - > http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-514/paper12.pdf > - http://lab.gnowledge.org/documentation > > which seems to be about linking org-mode to semantic web ideas like OWL. > > But it seems also there is nothing much to be found after 2009. > > Is this still an active thing going on on top of orgmode? yes. we still maintain it and runs well on top of and depends on orgmode. > > If not what happened to it? > > Any hints greatly appreciated. > Yes. We use the gnowsys-mode interface for sites running using gnowsys. So far this is the only complete interface for gnowsys. Mostly used by the developers and those who maintain the sites, such as atlas.gnowledge.org Currently we are exporting the knowledge base only as RDF statements. OWL export and import are not yet written. The work stalled since the developer who knows elisp in our team is no longer very active. We still need to fix some bugs. I am glad that somewhere some one is interested in this project. It is very encouraging. Let me know what kind of usecase you have thought about for using gnowsys-mode. -- GN
[O] Re: [Bug] MCE for HTML test of export
Hi Nicolas,
Nicolas wrote:
> Sébastien Vauban writes:
>> Regarding this problem only, it must be an interaction then with my
>> following setting for the inline task in HTML:
>>
>> #+begin_src emacs-lisp
>> ;; templates for inline tasks in various exporters
>> (setq org-inlinetask-export-templates
>> '((html "%s%s%s"
>> '((unless (eq todo "")
>> (format "%s%s "
>> class todo todo priority))
>> heading content))
>> (latex "\\todo[inline]{\\textbf{\\textsf{%s
>> %s}}\\linebreak{} %s}"
>> '((unless (eq todo "")
>> (format "\\textsc{%s%s}" todo priority))
>>heading content))
>> (ascii " -- %s%s%s"
>> '((unless (eq todo "")
>> (format "%s%s " todo priority))
>>heading
>>(unless (eq content "")
>> (format "\n ¦ %s"
>> (mapconcat 'identity
>> (org-split-string content
>> "\n")
>> "\n ¦ ")))
>> #+end_src
>
> Indeed, it came from your templates. To prevent this, I made sure, with the
> following patch, that CONTENT is always enclosed by newline characters.
> Would you mind testing it before I apply it ?
Perfect. Works like a charm. Please do apply it...
> Also, you may have a look at default templates, as your HTML variant is
> slightly wrong (wrt tag).
I'm not sure to understand what's "wrong". You mean the fact I added manually
a tag after the title?
If yes, it was to have the "title" line (task subject, with TODO keyword) on
its own line, followed by the rest of the entry on subsquent paragraphs.
But, indeed (after testing it), it seems I am not (anymore?) forced to insert
that. Was it this you were talking about?
Thanks for the comment, anyway... and for the patch!
Best regards,
Seb
--
Sébastien Vauban
Re: [O] Re: Problem with agenda and diary
Padawan, Julien Danjou writes: > Kids, look at the `message-subscribed-*' variables to configure this at > home. I use (setq nnmail-treat-duplicates 'delete) so I don't need to mess around with `message-subscribed-*' variables manually to avoid receiving duplicates. It's confusing not to see your email address when doing a wide reply, as Nick and I found out. It's okay now that we know it, but nobody can guess what is the value of your `message-subscribed-*'. :) -- Bastien
Re: [O] Re: Problem with agenda and diary
Padawan, Julien Danjou writes: > Kids, look at the `message-subscribed-*' variables to configure this at > home. I use (setq nnmail-treat-duplicates 'delete) so I don't need to mess around with `message-subscribed-*' variables manually to avoid receiving duplicates. It's confusing not to see your email address when doing a wide reply, as Nick and I found out. It's okay now that we know it, but nobody can guess what is the value of your `message-subscribed-*'. :) -- Bastien
Re: [O] C-0 C-c | throws emacs into infinite loop
On Sat, Mar 19, 2011 at 2:43 PM, Carsten Dominik wrote: > > On 18.3.2011, at 15:29, Le Wang wrote: > > > The doc-string of `org-table-convert-region' doesn't specifically address > 0 as SEPARATOR, but 0 is an integer. It shouldn't hang in any case. When I > C-g out of the loop, my undo limit was exceeded because the line filled with > hundreds of thousands of empty cells. > > > > I think the correct behavior is to convert region into table using 0 > spaces as a separator -- so each character forms its own column. > > While this might be nice, it is such a border case that, for now, I have > only added an > error message to prevent the converter from going into an infinite loop. > > Or do you have a *really* goo use case for this? > No, I don't have a use case for this. IMO, a reasonable argument should result in some reasonable non-surprising behaviour. We can argue whether 0 is a reasonable argument, though. I'm okay as long as it doesn't hang. > - Carsten > > -- Le
[O] Re: org-src-fontify-natively makes things very, very slow
Hi Eric,
Eric S Fraga wrote:
> Sébastien Vauban writes:
>> Maybe this is (partly?) due to the overlay I added:
>>
>> #+begin_src emacs-lisp
>> (overlay-put (make-overlay beg1 block-end)
>> 'face 'org-block-background))
>> #+end_src
>
> This could indeed be one cause, especially depending on what this does when
> there is no block-end line, or at least not anywhere near in the buffer. I
> seem to get a slowdown when I have a situation like this:
>
> #+begin_example
>
> [... some text ...]
> #+begin_src somelanguage
> [... text which is part of the source block...]
>
>
> [... lots of other text ...]
> [... including other source blocks]
>
> #+end_example
>
> where there is no matching #+end_src or, more precisely, the next #+end_src
> line is one that does not belong to this current source block. Your search
> (in org.el) for the end of the block assumes that it does have the end
> statement in place already. I'm not sure how to fix this because it's an
> ill-defined situation.
You say "your search..." but I only added the overlay-put command... and I
must admit this whole block is difficult to follow (so many cases).
> It may be worthwhile making the overlay optional? Although I must admit that
> I like it!
I simply can't live without it, either.
> My solution, by the way, is to insert the #+end_src line immediately upon
> writing a #+begin_src line and then back up a line to start writing the
> code.
"My" solution is even simpler: just use a yasnippet template, that prompts you
for the language and puts the begin/end upfront:
--8<---cut here---start->8---
#name : #+begin_src...#+end_src
# --
#+srcname: ${1:name}
#+begin_src ${2:language} $3
$0
#+end_src
--8<---cut here---end--->8---
Best regards,
Seb
--
Sébastien Vauban
Re: [O] Re: Merging .org files
On Sat, Mar 19, 2011 at 02:08, Matt Lundin wrote: > Pere Quintana Seguí writes: > >> Now I have to learn to better navigate within my much longer org files. >> Before, I used ido-mode to jump from buffer to buffer, now I guess I >> have to practise more sparse trees to jump from headline to headline. > > I use this function to jump quickly (via ido) to a first level headline > in my org files: > > [snip] Do you normally have ‘org-completion-use-ido’ turned off or something? (Just wondering why you couldn’t use ‘org-refile’ directly.) Aankhen
Re: [O] Custom Agenda View for Projects
2011/3/18 Josh Berry : > On Fri, Mar 18, 2011 at 10:57, Jason McBrayer wrote: >> On Thu, Mar 17, 2011 at 6:55 PM, Josh Berry wrote: >> >>> I think org considers child tasks to be dependencies of the parent >>> task -- so if a parent task (such as your PROJ) has children, it won't >>> be displayed in a tags-todo agenda view, because that takes >>> dependencies into account. >> >> That's a logical explanation, but shouldn't this only be the case if >> the parent has the :ORDERED: property set? > > No, if :ORDERED: is set, then each child is a dependency of the next > child. So if you have: > > * TODO top > ... :ORDERED: t ... > ** TODO a > ** TODO b > ** TODO c > > Only "a" will appear in your agenda view. But if you have: > > * TODO top > ** TODO a > ** TODO b > ** TODO c > > All children of "top"--that is, "a", "b" and "c"--will appear. > However, in neither case will "top" appear, because it has children > that are not yet completed. > >>> Have you tried just a "tags" view with a match of "TODO=\"PROJ\""? >>> IIRC this will do what you want. >> >> I gave this a test, and apparently it does not. What's shown is still >> dependent on the value of org-enforce-todo-dependencies. > > I see, it does not, my bad. I tried experimenting a bit on my own, > and didn't find an easy way using just agendas. > > You might consider experimenting with Stuck Projects though. If you > consider all projects to be "stuck", you could probably build an > agenda view that shows you all projects regardless of what's in them. > (I don't use stuck projects myself, so YMMV.) > > -- Josh > Dear Josh, dear Jason, thanks a lot for evaluating the options! That makes things a lot clearer for me, and for the moment I'll stick with org-enforce-todo-dependencies nil. Cheers, Christian
