Re: [O] "Generic" Source block language specification?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/11/12 00:17, Eric Schulte wrote: > Rainer M Krug writes: > >> Hi >> >> I have in a document a definition of a projection, which is essentially a >> text as follow: >> >> #+BEGIN_src +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 +lon_0=30.75 >> +x_0=0 +y_0=0 >> +datum=WGS84 +units=m +no_defs #+END_src >> >> Now this does obviously not export, as the source block language is missing. >> Is there a way >> that I can get the same formating of the source in the exportes output but >> without the syntax >> highlighting? >> >> BEGIN_EXAMPLE END_EXAMPLE >> >> is similar, but I would like the block to be formated as the SRC blocks. >> > > I bet "fundamental" would work, e.g., Yes, it does - works perfectly. Is this documented? Thanks, Rainer > > #+begin_src fundamental +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 > +lon_0=30.75 +x_0=0 > +y_0=0 +datum=WGS84 +units=m +no_defs #+end_src > >> >> Thanks, >> >> Rainer > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCvMSIACgkQoYgNqgF2egpKrQCdFYFJKZ/f7Ix+XOrO3sv2qpno wwoAnjz66rQYFBr0+Wr699pdrBx8aGT1 =NPZQ -END PGP SIGNATURE-
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes: >> The non-technical question: I understand this exporter is just a proof >> of concept, but it is working quite well for me, and I'm ready to help >> tweaking this. If I do further modifications, should I send them to the >> list? > > I classified it as "proof of concept" because I was too lazy to dig into > Scrlttr2 documentation and provide a complete enough letter back-end. > I would be glad that someone maintains it. > > I think the simplest solution is to: > > 1. Ask for push access to Org. Done. > 2. Commit file in contrib/ directory. > 3. Add yourself as Maintainer in it (or Author, for that matter). As I really haven't done much, it should at most be maintainer ;-) > 4. Commit additional changes when you see fit, without sending the > file over and over to the ML. > > For point 1, see http://orgmode.org/worg/org-contribute.html (For Org > Developers) > > Also, it would be nice if you signed FSF papers. I've signed and sent them by sent mail, but I haven't heard back yet (they're supposed to send me a pdf with their signature added). Alan
Re: [O] [ANN] e-latex back-end: changes to attributes syntax
Nicolas Goaziou writes:
> * Images (from manual)
>
> #+caption: The black-body emission of the disk around HR 4049
> #+name: fig:SED-HR4049
> #+attr_latex: :options "5cm,angle=90"
> [[./img/sed-hr4049.pdf]]
>
> #+attr_latex: :float wrap :placement "{r}{0.4\\textwidth}" :options
> "width=0.38\\textwidth"
> [[./img/hst.png]]
I just tried this (using current head on master), but the following
#+begin_src org
#+attr_latex: :options "0.9\linewidth"
[[./objets.pdf]]
#+end_src
yields
#+begin_src latex
\includegraphics[(:options 0.9linewidth)]{./prototype.pdf}
#+end_src latex
The problem is that even if I remove the ":option", then I get
"(0.9linewidth)" with extra parentheses and the backslash removed.
This is for a beamer file.
Is this a bug?
Alan
Re: [O] Extending org-koma-letter.el
Alan Schmitt writes: >> 3. Add yourself as Maintainer in it (or Author, for that matter). > > As I really haven't done much, [...] yet ;) > I've signed and sent them by sent mail, but I haven't heard back yet > (they're supposed to send me a pdf with their signature added). OK. Keep us informed when the process is over. Note this step is not mandatory to modify a file in contrib/, so you can do 1-3 meanwhile. Regards, -- Nicolas Goaziou
Re: [O] [ANN] e-latex back-end: changes to attributes syntax
Alan Schmitt writes:
> Nicolas Goaziou writes:
>
>> * Images (from manual)
>>
>> #+caption: The black-body emission of the disk around HR 4049
>> #+name: fig:SED-HR4049
>> #+attr_latex: :options "5cm,angle=90"
>> [[./img/sed-hr4049.pdf]]
>>
>> #+attr_latex: :float wrap :placement "{r}{0.4\\textwidth}" :options
>> "width=0.38\\textwidth"
>> [[./img/hst.png]]
>
> I just tried this (using current head on master), but the following
>
> #+begin_src org
> #+attr_latex: :options "0.9}\linewidth"
> [[./objets.pdf]]
> #+end_src
>
> yields
>
> #+begin_src latex
> \includegraphics[(:options 0.9linewidth)]{./prototype.pdf}
> #+end_src latex
>
> The problem is that even if I remove the ":option", then I get
> "(0.9linewidth)" with extra parentheses and the backslash removed.
>
> This is for a beamer file.
>
> Is this a bug?
This is a bug which I fixed some hours ago. Though, you need to escape
the backslash.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] e-latex back-end: changes to attributes syntax
Nicolas Goaziou writes: > This is a bug which I fixed some hours ago. Though, you need to escape > the backslash. OK, it's working now. By the way, do I need to fully restart emacs after installing a new version of org-mode, or is there a simpler way to load it? Thanks, Alan
Re: [O] [ANN] e-latex back-end: changes to attributes syntax
Alan Schmitt writes: > Nicolas Goaziou writes: > >> This is a bug which I fixed some hours ago. Though, you need to escape >> the backslash. > > OK, it's working now. > > By the way, do I need to fully restart emacs after installing a new > version of org-mode, or is there a simpler way to load it? Most of the time, M-x org-reload should do it. Though, when some oddities happen afterwards, I restart Emacs nonetheless. Regards, -- Nicolas Goaziou
Re: [O] [ANN] e-latex back-end: changes to attributes syntax
Da: Alan Schmitt A: Nicolas Goaziou Inviato: Venerdì 23 Novembre 2012 13:37 > Nicolas Goaziou writes: >> This is a bug which I fixed some hours ago. Though, you need to escape > > the backslash. > OK, it's working now. > By the way, do I need to fully restart emacs after installing a new > version of org-mode, or is there a simpler way to load it? I think M-x org-reload should suffice. Giovanni
[O] org-link and gnus-registry
Hi to all
I'm trying to setup gnus-registry for use with org-link. What I want to
do is reading emails (nnimap) in the INBOX, create a todo with
org-remember containing a link to this email, then move the email to
another group.
As was discussed before in this list, gnus-register is the way to do
this. Otherwise org-link will not find the message after it has gone to
another group.
This is not working for me. It might have to do with how org-store-links
creates the link. For me the links look like this:
[[gnus:Stuff#blu162-ds55e622a1ef424d0bd1f57c9...@phx.gbl][Email from
Yongbin: Re: Visit]]
"Stuff" is the name of my INBOX. This means the message-ID contains the
name of the original group. If the message is moved to another group, it
won't be found. It seems that either org-store-link or org-follow-link
does not respect gnus-registry.
I cannot find the mistake. Can somebody help me?
This is my setup (Emacs 23.4.1, Ubuntu 12.10):
,
| .gnus.el:
`
(setq gnus-registry-install t)
(setq
gnus-registry-split-strategy 'majority
gnus-registry-ignored-groups '(("nnrs" t)
("expired-spool" t)
("out-spool" t)
("deleted-messages" t)
("nndraft" t)
("spamassassined" t)
("spam" t)
("UCE-TMP" t))
gnus-registry-max-entries 2500
;; this is the default
gnus-registry-use-long-group-names t)
(gnus-registry-initialize)
(setq gnus-refer-article-method
'(current
(nnregistry)))
Thanks for help,
Sven
Re: [O] e-latex back-end: changes to attributes syntax
Hi Alan, * Alan Schmitt [23. Nov. 2012]: > Nicolas Goaziou writes: >> This is a bug which I fixed some hours ago. Though, you need to escape >> the backslash. > > OK, it's working now. > > By the way, do I need to fully restart emacs after installing a new > version of org-mode, or is there a simpler way to load it? There is: (org-reload &optional UNCOMPILED) Reload all org lisp files. With prefix arg UNCOMPILED, load the uncompiled versions. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
[O] agenda entries from bbdb3 anniversaries, birthdays AND weddings?
Hi, Following the example in the manual, the agenda can show (from bbdb3) either birthdays or weddings but can it show both? Does anyone have a solution to this? The choice is toggled by setting org-bbdb-anniversary-field to either 'birthday or 'wedding. The entry in an org agenda file is (as per the manual): * Anniversaries :PROPERTIES: :CATEGORY: Anniv :END: %%(org-bbdb-anniversaries) As there has been recent discussion[1] about the status and life expectancy of the %%(..) syntax in orgmode, I am wondering if there may be a new solution on the horizon. Thanks, Myles Footnotes: [1] http://permalink.gmane.org/gmane.emacs.orgmode/62422
Re: [O] [PATCH] org-edit-special too much space if starting with empty block
Has anyone had a chance to check this out? Others have run into this problem. On Sun, Nov 18, 2012 at 1:49 PM, Le Wang wrote: > On Fri, Nov 9, 2012 at 8:23 AM, Nicolas Goaziou wrote: >> Thank you for your patch. >> >> Would you mind adding comments in the function in order to explain the >> need for two pass. Also, you may want to reverse the if test in order to >> get rid of the progn. > > I've refactored and added comments. > >> Finally, could you provide the patch as "git format-patch" and add >> a changelog entry to it? > > The patch is now in the requested format. If the commit message and > inlined comments still aren't enough to explain the changes, please > let me know. > > Thanks! > > > -- > Le -- Le
Re: [O] "Generic" Source block language specification?
Rainer M Krug writes: > On 23/11/12 00:17, Eric Schulte wrote: >> Rainer M Krug writes: >> >>> Hi >>> >>> I have in a document a definition of a projection, which is essentially a >>> text as follow: >>> >>> #+BEGIN_src +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 +lon_0=30.75 >>> +x_0=0 +y_0=0 >>> +datum=WGS84 +units=m +no_defs #+END_src >>> >>> Now this does obviously not export, as the source block language is >>> missing. Is there a way >>> that I can get the same formating of the source in the exportes output but >>> without the syntax >>> highlighting? >>> >>> BEGIN_EXAMPLE END_EXAMPLE >>> >>> is similar, but I would like the block to be formated as the SRC blocks. >>> >> >> I bet "fundamental" would work, e.g., > > Yes, it does - works perfectly. Is this documented? > Yes. Whatever language string is placed at the top of the source block will define the mode used for export and in-block editing. I believe that is documented. Cheers, > > Thanks, > > Rainer > >> >> #+begin_src fundamental +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 >> +lon_0=30.75 +x_0=0 >> +y_0=0 +datum=WGS84 +units=m +no_defs #+end_src >> >>> >>> Thanks, >>> >>> Rainer >> > -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] org-link and gnus-registry
"Sven Bretfeld" writes: > As was discussed before in this list, gnus-register is the way to do > this. Otherwise org-link will not find the message after it has gone to > another group. > > This is not working for me. It might have to do with how org-store-links > creates the link. For me the links look like this: > > [[gnus:Stuff#blu162-ds55e622a1ef424d0bd1f57c9...@phx.gbl][Email from > Yongbin: Re: Visit]] > > "Stuff" is the name of my INBOX. This means the message-ID contains the > name of the original group. If the message is moved to another group, it > won't be found. It seems that either org-store-link or org-follow-link > does not respect gnus-registry. > > I cannot find the mistake. Can somebody help me? I'm having very mixed results with gnus-registry, and I'm still looking for a better solution. In the meantime: - make sure the message is moved from inside gnus, it seems it's required to be tracked by the registry; - if you cannot get to the message, try to search for it (I use notmuch, which works nicely), figure out the mailbox name, and you can then manually fix the link by changing the mailbox name there. I use stable mailboxes for this: archive is for the current month, otherwise the message is in "old/year/month". Searches and links let me get to messages really easily. Alan
Re: [O] "Generic" Source block language specification?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/11/12 16:02, Eric Schulte wrote: > Rainer M Krug writes: > >> On 23/11/12 00:17, Eric Schulte wrote: >>> Rainer M Krug writes: >>> Hi I have in a document a definition of a projection, which is essentially a text as follow: #+BEGIN_src +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 +lon_0=30.75 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs #+END_src Now this does obviously not export, as the source block language is missing. Is there a way that I can get the same formating of the source in the exportes output but without the syntax highlighting? BEGIN_EXAMPLE END_EXAMPLE is similar, but I would like the block to be formated as the SRC blocks. >>> >>> I bet "fundamental" would work, e.g., >> >> Yes, it does - works perfectly. Is this documented? >> > > Yes. Whatever language string is placed at the top of the source block will > define the mode > used for export and in-block editing. I believe that is documented. OK - then I thought that I can use all languages *for formating* which are defined in the listings package in LaTeX, but it doesn't matter what I take: it always formats it in as a source block but obviously without syntax highlighting. For editing: C-c ' only works ehen using "fundamental" - other non-existent languages are not accepted (obviously). So I assume in org, there is support for "fundamental", but I could not find it in the documentation when I looked. At the moment, my org info documentation seems to be not accessible (blank page when opening it). Cheers, Rainer > > Cheers, > >> >> Thanks, >> >> Rainer >> >>> >>> #+begin_src fundamental +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 >>> +lon_0=30.75 +x_0=0 >>> +y_0=0 +datum=WGS84 +units=m +no_defs #+end_src >>> Thanks, Rainer >>> >> > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCvlaMACgkQoYgNqgF2egpgFgCeP7BZGpBUv1uU+tIzaFy4XvH5 C3gAn1ri7W9R4OJEKHq/RpVAELcFvpyM =Ezlp -END PGP SIGNATURE-
Re: [O] latex include file
It worked
Thanks
M
Sent from my iPhone
On Nov 22, 2012, at 3:30 PM, Marvin Doyley wrote:
> I haven't tried this, I will upgrade to the latest version of org and
> try. How do I tell org only to export the body ?
>
> Sent from my iPhone
>
> On Nov 22, 2012, at 2:06 PM, Marvin Doyley wrote:
>
>> Hi there,
>>
>> I am trying to figure out how to export a latex file while suppressing the
>> \begin{document} \end{document} and all the other frontmatter stuff.
>>
>> In essence, I would like to create a .tex file that will be included in
>> another latex file. More specifically, I want the exported file to look
>> something like
>>
>> \section{}
>>
>> BLAH BLAH
>>
>> \begin{equation}
>>
>> E=MC^2
>> \end{equation}
>>
>> I have created a costume org-export-latex-classes to suppress packages, but
>> I am stuck with the other front matter stuff.
>>
>> Best Wishes
>> M
>>
>>
>>
Re: [O] "Generic" Source block language specification?
Rainer M Krug writes: > On 23/11/12 16:02, Eric Schulte wrote: >> Rainer M Krug writes: >> >>> On 23/11/12 00:17, Eric Schulte wrote: Rainer M Krug writes: > Hi > > I have in a document a definition of a projection, which is essentially a > text as > follow: > > #+BEGIN_src +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 +lon_0=30.75 > +x_0=0 +y_0=0 > +datum=WGS84 +units=m +no_defs #+END_src > > Now this does obviously not export, as the source block language is > missing. Is there a > way that I can get the same formating of the source in the exportes > output but without > the syntax highlighting? > > BEGIN_EXAMPLE END_EXAMPLE > > is similar, but I would like the block to be formated as the SRC blocks. > I bet "fundamental" would work, e.g., >>> >>> Yes, it does - works perfectly. Is this documented? >>> >> >> Yes. Whatever language string is placed at the top of the source block will >> define the mode >> used for export and in-block editing. I believe that is documented. > > OK - then I thought that I can use all languages *for formating* which are > defined in the listings > package in LaTeX, but it doesn't matter what I take: it always formats it in > as a source block but > obviously without syntax highlighting. > > For editing: C-c ' only works ehen using "fundamental" - other non-existent > languages are not > accepted (obviously). > > So I assume in org, there is support for "fundamental", but I could not find > it in the > documentation when I looked. > When editing a code block, Org-mode will take the name of the language, append "-mode", and then try to call the result as a function. So for example, an R code block will call "R-mode" to edit the contents using R-mode. Thus any *-mode is a valid code block name. > > At the moment, my org info documentation seems to be not accessible >(blank page when opening it). > > Cheers, > > Rainer > >> >> Cheers, >> >>> >>> Thanks, >>> >>> Rainer >>> #+begin_src fundamental +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 +lon_0=30.75 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs #+end_src > > Thanks, > > Rainer >>> >> > -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] "Generic" Source block language specification?
Rainer M Krug wrote: > On 23/11/12 16:02, Eric Schulte wrote: > > Rainer M Krug writes: > > > >> On 23/11/12 00:17, Eric Schulte wrote: > >>> Rainer M Krug writes: > >>> > Hi > > I have in a document a definition of a projection, which is essentially > a text as > follow: > > #+BEGIN_src +proj=aea +lat_1=-28.25 +lat_2=-29.75 +lat_0=29 +lon_0=30.75 > +x_0=0 +y_0=0 > +datum=WGS84 +units=m +no_defs #+END_src > > Now this does obviously not export, as the source block language is > missing. Is there a > way that I can get the same formating of the source in the exportes > output but without > the syntax highlighting? > > BEGIN_EXAMPLE END_EXAMPLE > > is similar, but I would like the block to be formated as the SRC blocks. > > >>> > >>> I bet "fundamental" would work, e.g., > >> > >> Yes, it does - works perfectly. Is this documented? > >> > > > > Yes. Whatever language string is placed at the top of the source block > > will define the mode > > used for export and in-block editing. I believe that is documented. > > OK - then I thought that I can use all languages *for formating* which are > defined in the listings > package in LaTeX, but it doesn't matter what I take: it always formats it in > as a source block but > obviously without syntax highlighting. > > For editing: C-c ' only works ehen using "fundamental" - other non-existent > languages are not > accepted (obviously). > > So I assume in org, there is support for "fundamental", but I could not find > it in the > documentation when I looked. > > At the moment, my org info documentation seems to be not accessible (blank > page when opening it). > In order for this to work, emacs has to have a mode to handle it: "fundamental" as a language works, because emacs has a mode called fundamental-mode. I append the relevant portion of the documentation (section 14.2, Editing source code) I hope it comes in useful until you get your info problems resolved, but note that it's also available online at http://orgmode.org/org.html#Editing-source-code See org-src-lang-modes below for the details: , | | 14.2 Editing source code | | | Use `C-c '' to edit the current code block. This brings up a language | major-mode edit buffer containing the body of the code block. Saving | this buffer will write the new contents back to the Org buffer. Use | `C-c '' again to exit. | |The `org-src-mode' minor mode will be active in the edit buffer. The | following variables can be used to configure the behavior of the edit | buffer. See also the customization group `org-edit-structure' for | further configuration options. | | `org-src-lang-modes' | If an Emacs major-mode named `-mode' exists, where `' | is the language named in the header line of the code block, then | the edit buffer will be placed in that major-mode. This variable | can be used to map arbitrary language names to existing major | modes. | | `org-src-window-setup' | Controls the way Emacs windows are rearranged when the edit buffer | is created. | | `org-src-preserve-indentation' | This variable is especially useful for tangling languages such as | Python, in which whitespace indentation in the output is critical. | | `org-src-ask-before-returning-to-edit-buffer' | By default, Org will ask before returning to an open edit buffer. | Set this variable to nil to switch without asking. | |To turn on native code fontification in the _Org_ buffer, configure | the variable `org-src-fontify-natively'. | ` HTH, Nick
Re: [O] "Generic" Source block language specification?
Rainer M Krug writes: > Hi > > I have in a document a definition of a projection, which is essentially a > text as follow: > > #+BEGIN_src > +proj=aea +lat_1=-28.25 > +lat_2=-29.75 > +lat_0=29 > +lon_0=30.75 > +x_0=0 > +y_0=0 > +datum=WGS84 > +units=m > +no_defs > #+END_src > > Now this does obviously not export, as the source block language is missing. > Is there a way that I > can get the same formating of the source in the exportes output but without > the syntax highlighting? > > BEGIN_EXAMPLE > END_EXAMPLE > > is similar, but I would like the block to be formated as the SRC > blocks. Marking the src block as `fundamental' has a drawback. One can no longer have in-buffer fontification of src blocks. A better option would be to have a custom variable which produces black-and-white src blocks on export. ODT already has this option. C-h v org-e-odt-fontify-srcblocks RET I am CCing Nicolas, to check whether he would be interested in introducing an export knob for this. > Thanks, > Rainer --
Re: [O] [org-e-texinfo] generate menu items
Aloha Jon, Thanks very much for these changes, which appear to work nicely with the draft Org manual. What do you think about the various macro commands defined in org.texi? How to put them in the Org file and then get them into the texinfo output? The org.texi file has them between @finalout and @copying. I don't know if they have to be there, but I assume they were put there for a reason. All the best, Tom Jonathan Leech-Pepin writes: > Hello Tom, Nicolas, > > I've just pushed a change that should provide the desired results. > > The optional title for the menu entries (as well as associated node > headings) can be set using the :TEXINFO_MENU_TITLE: property. > > On 18 November 2012 11:22, Thomas S. Dye wrote: > >> Nicolas Goaziou writes: >> >> > t...@tsdye.com (Thomas S. Dye) writes: >> > >> >> Nicolas Goaziou writes: >> > >> >>> That's a bit of work, because, so far, node-property values are not >> >>> parsed. So it would require to define a new class of node-properties: >> >>> those with a parsed value. But then, how to decide which properties >> have >> >>> their value parsed are parsed and which have not? >> > >> >> Thanks for the information and explanation. Back-end-specific >> >> properties should work nicely in this case. >> >> >> >> I'll wait to see what Jonathan thinks about the original query. >> > >> > Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this >> > one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed, I can >> > give it a try. >> > >> > > If you do include these node properties I can then adjust the texinfo > exporter to use the generic TOC/Optional title property rather than a > backend specific one. > > > Regards, > > -- > Jon > > >> > I would be consistent with #+caption[short]: long for other elements. >> > >> > >> > Regards, >> >> I'm biased by LaTeX, which uses the optional argument for the TOC and >> running heads. Since the back-ends are free to use this optional entry >> as they please, and not only for the TOC, perhaps :EXPORT_SHORT_ENTRY: >> (because that is its usual function), or :EXPORT_OPTIONAL_ENTRY: >> (because the back-end has the option to use it where appropriate). >> >> All the best, >> Tom >> >> -- >> Thomas S. Dye >> http://www.tsdye.com >> >> > Hello Tom, Nicolas, > > I've just pushed a change that should provide the desired results. > > The optional title for the menu entries (as well as associated node > headings) can be set using the :TEXINFO_MENU_TITLE: property. > > On 18 November 2012 11:22, Thomas S. Dye wrote: > > > Nicolas Goaziou writes: > > > t...@tsdye.com (Thomas S. Dye) writes: > > > >> Nicolas Goaziou writes: > > > >>> That's a bit of work, because, so far, node-property values > are not > >>> parsed. So it would require to define a new class of > node-properties: > >>> those with a parsed value. But then, how to decide which > properties have > >>> their value parsed are parsed and which have not? > > > >> Thanks for the information and explanation. Back-end-specific > >> properties should work nicely in this case. > >> > >> I'll wait to see what Jonathan thinks about the original query. > > > > Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this > > one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed, > I can > > give it a try. > > > > > If you do include these node properties I can then adjust the texinfo > exporter to use the generic TOC/Optional title property rather than a > backend specific one. > > > Regards, > > -- > Jon > > > > > I would be consistent with #+caption[short]: long for other > elements. > > > > > > Regards, > > > I'm biased by LaTeX, which uses the optional argument for the TOC > and > running heads. Since the back-ends are free to use this optional > entry > as they please, and not only for the TOC, perhaps > :EXPORT_SHORT_ENTRY: > (because that is its usual function), or :EXPORT_OPTIONAL_ENTRY: > (because the back-end has the option to use it where appropriate). > > > All the best, > Tom > > -- > > > Thomas S. Dye > http://www.tsdye.com > > > -- Thomas S. Dye http://www.tsdye.com
Re: [O] Question re. Bernt's agenda setup
Viktor Rosenfeld writes: > it's Shift-P and you need to bind the function bh/narrow-to-project to > the keycode. See the code blocks in the following two sections: > > http://doc.norang.ca/org-mode.html#SpeedCommands > http://doc.norang.ca/org-mode.html#NarrowToSubtree > > Cheers, > Viktor > > PS: I agree that Bernt's document is absolutely awesome! > Manish wrote: > >> Hello Bernt and others, >> >> I was picking up tips from Bernt's awesome and famous document at >> http://doc.norang.ca/org-mode.html. In section 7.1, just between the >> two screenshots, I came across following text: Hi, Yes it is capital P. Do I need to make this more explicit in the document? My document is famous??!!?? Eeek! :) Thanks for the feedback :) Regards, Bernt PS. I'm a bit behind in reading the org-mode list... almost 1000 unread messages :(. If you want a faster response please send emails directly to me and cc the list. >> >> ,[ excerpt from section 7.1 ] >> | After selecting a project (with P on any task in the agenda) the block >> | agenda changes to show the project and any subprojects in the Projects >> | section. Tasks show project-related tasks that are hidden when not >> | narrowed to a project. >> ` >> >> The feature/concept seems very useful to be able to zoom into a project >> of interest but I could't figure out how =P= helps with this since it >> seems to move to previous item while in the ageda view. >> >> Can someone (or Bernt) using the setup point me to right direction >> please? >> >> Regards >> --Manish >>
Re: [O] Question re. Bernt's agenda setup
Memnon Anon writes: > Manish writes: > >> a way to >> pick out all #+begin_src parts from the .org version? > > (org-babel-tangle &optional ONLY-THIS-BLOCK TARGET-FILE LANG), > bound to `C-c C-v t' by default. > Not all emacs-lisp blocks are set to :tangle yes, though. The org version of the document is available at http://doc.norang.ca/org-mode.org You should be able to load that in org-mode and then tangle it with C-c C-v C-t to generate org-mode.el with all of the elisp from the document in it. Some of the code blocks in the document are explicitly set to :tangle no because one or more of the following apply: - The code block is replaced with another that allows overriding values in a users .emacs - The code block shows an old setting that I don't use anymore - The code block is a repeat of a setting that is included in another block Let me know if you find something missing from the tangled version that you think should be there. I guess I should add a "How To Use This Document" section with these details. Thanks for the feedback :) Regards, Bernt
Re: [O] Question re. Bernt's agenda setup
Viktor Rosenfeld writes: > Alan Schmitt wrote: > >> Viktor Rosenfeld writes: >> >> > it's Shift-P and you need to bind the function bh/narrow-to-project to >> > the keycode. See the code blocks in the following two sections: >> > >> > http://doc.norang.ca/org-mode.html#SpeedCommands >> > http://doc.norang.ca/org-mode.html#NarrowToSubtree >> >> I managed to make this work, but if I run the command in the agenda I >> need to refresh it afterwards (using 'g'). Are you seeing the same >> thing? > > Yes, unfortunately. I think I remember that it used to refresh the > agenda automatically. This is above my pay grade, I'm afraid. > > Cheers, > Viktor > >> >> And I also want to say I have learned a lot implementing the suggestions >> in that document. >> >> Alan I have also noticed this in Windows at work and actually toyed with the idea of dropping the commands from the agenda that don't refresh properly anymore ... but quickly found I can't live without that functionality. So I too am doing 'g' to refresh as required ATM. If I figure out a fix I'll post that. Thanks for the feedback :) Regards, Bernt
Re: [O] Question re. Bernt's agenda setup
Manish writes: > On Mon, Nov 19, 2012 at 7:34 PM, Alan Schmitt wrote: >> Manish writes: >> >>> On Sat, Nov 17, 2012 at 6:25 PM, Manish wrote: >>> [snip (21 lines)] =F12 SPC= with =V= is so much better at doing project reviews than anything else I have ever seen. My only gripe is that functions called by =V= and =P= do not refresh the agenda. I am trying to understand enough elisp to be able to call org-agenda-redo and beginning-of-buffer in some right places.. >>> >>> My bad. While making the same setup from scratch in home laptop found >>> that everything works as advertised. My work setup must have something >>> interfering with it. >> >> I'd be really curious to know what it is. I'm in the same situation here >> where the agenda is not refreshed when doing a P or V from within it. >> (Doing a W works, though). > > Strangely, it refreshes fine on Ubuntu but not on Windows (both with no > code other than Bernt's). I am using Emacs 24.2 and git head from > master branch. > > My half-baked attempts to add some bits to relevant functions to call > org-agenda-redo followed by beginning-of-buffer did not work. I am now > looking to using AutoHotKey as a duct tape solution. I've noticed this as well. I'm using Emacs 23.2 on Debian Linux and 23.1 (I think) on Windows at work. It may be related to changes in git master but I haven't had time to look into it yet and won't before the Christmas holidays with my current work schedule. Regards, Bernt
Re: [O] Exclude all TODO keywords from refile targets
Jason Dunsmore writes: > I found a bit of code to exclude DONE keywords from refile targets > here: http://orgmode.org/worg/org-hacks.html#sec-2-3 > > Since I try to keep all headings with keywords as end nodes, I wanted > to exclude all TODO (and DONE) keywords. However, the member function > doesn't work on a sequence data type, so I couldn't use > org-todo-keywords the same way the org-hacks code used > org-done-keywords. Furthermore, org-todo-keywords contains extraneous > characters in parenthesis that define "selection characters". I ended > up creating a new variable, org-todo-keywords-list, and converting the > data from org-todo-keywords into a similar format as > org-done-keywords. > > Perhaps a org-todo-keywords-list variable would be a useful addition > to org-mode. Here's the code I'm using: > > (setq org-todo-keywords '((sequence "TODO(t)" "DELEGATE(l)" > "STARTED(s@)" "WAITING(w@)" "|" "DONE(d)" "CANCELLED(c)" > "DELEGATED(e@)" "POSTPONED(p@)"))) > You should be able to use org-todo-keywords-1 which contains a list of todo keywords for the current org file. HTH, Bernt > ;; define a new variable > (defvar org-todo-keywords-list nil > "A list version of org-todo-keywords, without the selection characters > in parenthesis.") > > ;; create org-todo-keywords-list from org-todo-keywords-list, using a > ;; similar format to org-done-keywords > (dolist (keyword (first org-todo-keywords)) > (when (and (stringp keyword) > (not (equal keyword "|"))) > (add-to-list 'org-todo-keywords-list > (replace-regexp-in-string "(.*)" "" keyword > > (defun jbd-verify-refile-target () > "Exclude todo keywords with a done state from refile targets" > (not (member (nth 2 (org-heading-components)) org-todo-keywords-list))) > > (setq org-refile-target-verify-function 'jbd-verify-refile-target)
