Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
Charles Berry writes: > John Hendy gmail.com> writes: > > [deleted] >> > >> > I think the default behavior should be reverted, as tangling and >> > exporting are two different things. When I tangle, I want to see the >> > code blocks as they are in the org document (with possible variables and >> > expansions) but not to create files where I do not put it explicitly >> > into a code block. These wrappers have nothing to do with the code, and >> > are only there for the exported engine. So I would either revert to the >> > original behavior, or, introduce a new header argument, >> > e.g. :include-wrappers, which would, if set to t, include the export >> > wrappers in the tangled file. This might be useful for debugging >> > exporting of code block results, but not for general tangling. >> >> Thanks for chiming in. This was my gut reaction to the default >> behavior. I guess we're still only a sample size of 2, but >> intuitively, I would think that tangling would be a separate beast in >> most cases from exporting. Just to have it on the record, if I tangle, >> it's usually to take the code I've used in something like a Beamer >> presentation or document and combine it into a single .R file so >> someone can run it without needing Org-mode. > > [deleted] > > Sorry to be late to add my $0.02... > > I never want the try/catch wrappers. > > But noweb is indispensable. > > I use noweb a lot to organize and collect blocks. In some cases, I export > them and in others I just tangle them. > > I hope that the revised code will allow me to turn off try/catch wrapping > and still be able to use noweb when tangling or exporting. > In addition to noweb, there are cases where variable expansion is useful in tangled code. The simplest option is to move things like try/catch blocks out of the code block expansion function, and into the execution function. Then if other language present similar constructs (which we want to add to execution by default but never want to tangle), we can think about abstracting this out into some new level of code block expansion. Thoughts? > > Best, > > Chuck > > -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] following org links to gnus messages and window management
Alan Schmitt writes: > Hi Bastien, > > Bastien writes: > >>> - if not, is there a way to copy a link then open it using the >>> minibuffer (I would then do the switch to screen 0 manually)? >> >> This does not use the minibuffer but you could add that: >> >> (progn >> (org-next-link) >> (org-open-link-from-string >>(org-element-property :raw-link (org-element-link-parser > > This was most helpful: I just need to copy the link I want to follow, go > to the first screen, and interactively call `org-open-link-from-string'. > This works great for the moment. > >>> - finally, do you have alternative window management options to suggest >>> that would work well with following links to gnus messages? >> >> Well, all I can think of now is >> >> (setq org-agenda-window-setup 'other-frame) > > Thanks, but I'm trying to avoid using several frames. (OS > X unfortunately does not come with a window manager that I like ...) > > Thanks again, > > Alan I have a setup that's probably more complicated than what you want, but maybe you'll find something interesting in it. The problem is, you need to somehow specify when or under what conditions you do away with the opened windows and return to your org file or agenda. In my case, I use the following to answer emails. When I open the link it stores the current window configuration, and when the email is sent it triggers the restore. I believe I've confused myself slightly while trying to set up interactive vs non-interactive versions, but so far I've never wanted to use it non-interactively, so it works fine. #+BEGIN_SRC org (defvar org-mail-window-conf nil "Save org-buffer window configuration here, for later restoration.") (defun org-mail-restore-after-send () (gnus-summary-exit nil t) (when (window-configuration-p org-mail-window-conf) (set-window-configuration org-mail-window-conf)) ; Should check here that we actually made it back to the org ; heading. Could save an ID prop on the heading and check for that. (call-interactively 'org-agenda-todo)) (defun org-mail-handle-mail (&optional interactive-p) "Handle mail-related links for current headline." (interactive "p") (unless (org-back-to-heading t) (error "Not in an org item")) (when interactive-p (setq org-mail-window-conf (current-window-configuration))) (let (message mailto) (while (re-search-forward org-any-link-re (line-end-position) t) (let ((addr (or (match-string-no-properties 2) (match-string-no-properties 0 (cond ((string-match "^mailto:"; addr) (push (substring addr (match-end 0)) mailto)) ((and (featurep 'bbdb) (string-match-p "^
Re: [O] OrgStruct for Python source code
On 3/19/2014 9:19 PM, Ilya Shlyakhter wrote: Another option is to use Thorsten Jolitz's excellent outshine mode ( http://orgmode.org/worg/org-tutorials/org-outside-org.html ). I've written a small extension that allows it to fold language elements: http://www.broadinstitute.org/~ilya/outshine-python.el Apologies, correct link is https://github.com/notestaff/outshine/blob/outshine-lang/outshine-lang.el
Re: [O] OrgStruct for Python source code
On 3/19/2014 3:39 PM, Karl Voit wrote: I am evaluating methods to fold Python source code. simply turn on orgstruct-mode in a python buffer and try M-x org-cycle RET on a def: it will fold it. Another option is to use Thorsten Jolitz's excellent outshine mode ( http://orgmode.org/worg/org-tutorials/org-outside-org.html ). I've written a small extension that allows it to fold language elements: http://www.broadinstitute.org/~ilya/outshine-python.el
Re: [O] Navigating from agenda causes incorrect expansion of children
expands logbook, but i can take it from here. thank you! unfortunately, that is not a global solution as there are various other places where the same behavior occurs. On 3/19/14, Bastien wrote: > Samuel Wales writes: > >> so where is the setting to show EVERYTHING? > > (add-hook 'org-agenda-after-show-hook 'show-all) > > :) > > -- > Bastien > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Namespace problem org-mode / Clojure
That's great! A big thanks to Bastien for fixing the elisp, and keeping Clojure code blocks working smoothly. Speaking of org-mode and Clojure... You may be interested in the recent Clojure org-mode postings at the Google group: https://groups.google.com/forum/#!topic/clojure/hWqPXn1_pK4 https://groups.google.com/forum/#!topic/clojure/V8p3Q9UaNYw I'm planning to look at this later. It looks like quite a body of work using org-mode + Clojure. Regards, Greg On Wed, 2014-03-19 at 15:30 +0100, Volker Strobel wrote: > A belated, but very big thanks to both of you! It works perfectly > now :) > > > Best, Volker
Re: [O] Navigating from agenda causes incorrect expansion of children
Samuel Wales writes: > so where is the setting to show EVERYTHING? (add-hook 'org-agenda-after-show-hook 'show-all) :) -- Bastien
Re: [O] org-html-do-format-code: End of buffer
Hi Andrey, Andrey Tykhonov writes: > I've tried to reproduce with (toggle-debug-on-error) and now (setq > debug-on-error t) but buffer with the backtrace doesn't appear. Maybe you need to try from a fresh Emacs session: in this case, just add (setq debug-on-error t) in your .emacs.el. > I can see > just the same messages in the *Messages* buffer that's all. Another way to explore this: M-x find-function RET org-html-do-format-code RET M-x edebug-defun RET Then try to export: the evaluation will stop at the beginning of this function. You need to type `n' to let the evaluation continue step by step, and perhaps you will hit the point where you can make sense of this "End of buffer" error. Good luck! -- Bastien
Re: [O] Navigating from agenda causes incorrect expansion of children
for the first time in many, many years of HATING this behavior and trying to debug it and trying to defadvice around it, i have a lead on it. thank you. so where is the setting to show EVERYTHING? this is HUGE. On 3/19/14, Bastien wrote: > Samuel Wales writes: > >> I think there must be a bunch of us who are experiencing >> this, because I am too. >> >> The fix does not work for me. >> >> 3b is never shown. >> >> * test 1 >> *** 2a >> SCHEDULED: <2014-03-19 Wed> >> * 3a >> * 3b >> *** 2b > > This is not the same case: in Dan's example, the sibling (at the same > level) was not shown. In your example, the second entry below is not > shown, which is the expected behavior. > > -- > Bastien > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Small bug in example code
Reuben Thomas writes: > OK, I have commits ready to push as soon as you install my SSH key! Done, -- Bastien
Re: [O] org-html-do-format-code: End of buffer
Hi Bastien! Bastien writes: > Hi Andrey, > > Andrey Tykhonov writes: > >> What is the problem? Why mentioned error occurs? How can I fix it? Please >> help. > > Can you reproduce the error with (setq debug-on-error t) and send us > the backtrace? If you can do this from an uncompiled version of Org, > that's even better. I've tried to reproduce with (toggle-debug-on-error) and now (setq debug-on-error t) but buffer with the backtrace doesn't appear. I can see just the same messages in the *Messages* buffer that's all.
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Luke Crook writes: > Rasmus gmx.us> writes: > >> >> I've used this snip to recover such fields >> >> \makeatletter >> \let\Title\ title >> \let\Author\ author >> \let\Date\ date >> \makeatother >> >> Obviously, this is only good for LaTeX. >> > > How would I implement this? Is including in the .tex file sufficient? > Having these in the Org-mode file itself? When I try in the .tex file, it > appears almost verbatim as; For some reason your "@" (the sign from email address) becomes "". It needs to be "@". See the gmane version if you are in doubt. Here's a working example. #+TITLE: title #+AUTHOR: name #+LATEX: \newcommand{\myname}{\Author} Remember to escape latex macros like ~\myname~ as ~@@latex:\myname@@~ in Org to get "\myname" * make some latex commands :noexport: # Local Variables: # org-latex-title-command: "\\makeatletter\n \ # \\let\\Title\\@title\n \ # \\let\\Author\\@author\n \ # \\let\\Date\\@date\\makeatother\n \ # \\maketitle" # End: -- In theory, practice and theory are the same. In practice they are not
Re: [O] Small bug in example code
OK, I have commits ready to push as soon as you install my SSH key! On 19 March 2014 22:52, Bastien wrote: > Reuben Thomas writes: > > > In the function org-toggle-iimage-in-org in the page > > > > http://orgmode.org/worg/org-configs/org-config-examples.html#sec-2_2 > > > > the call (iimage-mode) needs to be (iimage-mode 'toggle), otherwise > > iimage-mode is only ever switched on. (iimage-mode does toggle when > > used as a command, but not when called from Lisp.) > > (Same suggestion for this one.) > > Thanks! > > -- > Bastien > -- http://rrt.sc3d.org
Re: [O] org-html-do-format-code: End of buffer
Hi Andrey, Andrey Tykhonov writes: > What is the problem? Why mentioned error occurs? How can I fix it? Please > help. Can you reproduce the error with (setq debug-on-error t) and send us the backtrace? If you can do this from an uncompiled version of Org, that's even better. -- Bastien
Re: [O] Navigating from agenda causes incorrect expansion of children
Samuel Wales writes: > I think there must be a bunch of us who are experiencing > this, because I am too. > > The fix does not work for me. > > 3b is never shown. > > * test 1 > *** 2a > SCHEDULED: <2014-03-19 Wed> > * 3a > * 3b > *** 2b This is not the same case: in Dan's example, the sibling (at the same level) was not shown. In your example, the second entry below is not shown, which is the expected behavior. -- Bastien
Re: [O] Post() evaluates but fails in export
Nicolas Goaziou writes: > Bastien writes: > >> Oh, yes, of course. Feel free to apply it on master then. > > Done. Thanks, -- Bastien
Re: [O] Obsolete information in worg
Hi Reuben, Reuben Thomas writes: > In this section: > > http://orgmode.org/worg/org-configs/org-config-examples.html#sec-2_2 > > the information about yasnippet is out of date; more up-to-date > information is available in the manual: > > http://orgmode.org/org.html#Interaction > > Hence, I suggest removing the references to yasnippet from the worg > page. can you send me your public key so that I add you as a committer to worg.git? This way you can fix these problems directly. Thanks, -- Bastien
Re: [O] Small bug in example code
Reuben Thomas writes: > In the function org-toggle-iimage-in-org in the page > > http://orgmode.org/worg/org-configs/org-config-examples.html#sec-2_2 > > the call (iimage-mode) needs to be (iimage-mode 'toggle), otherwise > iimage-mode is only ever switched on. (iimage-mode does toggle when > used as a command, but not when called from Lisp.) (Same suggestion for this one.) Thanks! -- Bastien
Re: [O] preview and default class [8.2.5h (release_8.2.5h-677-g55b0a3 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Hi Bastien, > Mhh, yes, I'm for moving it to the previewing section. > > Do you want to get commit access so that you can fix this directly? > Otherwise, just send a patch and I'll apply it. > > Thanks! Here's a patch. I can commit it if you like, but I don't want to do so without some review (it's not as trivial a change as moving the corresponding footnote to the other section). >From 4b431a0fc2a4df7cecd8b6649227415ed86e7f7c Mon Sep 17 00:00:00 2001 From: Nicolas Richard Date: Wed, 19 Mar 2014 23:13:39 +0100 Subject: [PATCH] Keep documentation on "Previewing LaTeX" in its own section * doc/org.texi: Keep documentation on "Previewing LaTeX" in its own section --- doc/org.texi | 39 ++- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index c442f83..447cde9 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -10140,19 +10140,13 @@ format sub- and superscripts in a WYSIWYM way. Going beyond symbols and sub- and superscripts, a full formula language is needed. Org mode can contain @LaTeX{} math fragments, and it supports ways to process these for several export back-ends. When exporting to @LaTeX{}, -the code is obviously left as it is. When exporting to HTML, Org invokes the -@uref{http://www.mathjax.org, MathJax library} (@pxref{Math formatting in +the code is obviously left as it is. When exporting to HTML, Org can invoke +the @uref{http://www.mathjax.org, MathJax library} (@pxref{Math formatting in HTML export}) to process and display the math@footnote{If you plan to use this regularly or on pages with significant page views, you should install @file{MathJax} on your own server in order to limit the load of our server.}. -Finally, it can also process the mathematical expressions into -images@footnote{For this to work you need to be on a system with a working -@LaTeX{} installation. You also need the @file{dvipng} program or the -@file{convert}, respectively available at -@url{http://sourceforge.net/projects/dvipng/} and from the @file{imagemagick} -suite. The @LaTeX{} header that will be used when processing a fragment can -be configured with the variable @code{org-format-latex-header}.} that can be -displayed in a browser. +It can also process the mathematical expressions into images that can be +displayed in a browser (see @pxref{Previewing @LaTeX{} fragments}). @LaTeX{} fragments don't need any special marking at all. The following snippets will be identified as @LaTeX{} source code: @@ -10210,11 +10204,21 @@ lines: @cindex @LaTeX{} fragments, preview @vindex org-latex-create-formula-image-program -If you have @file{dvipng} or @file{imagemagick} installed@footnote{Choose the -converter by setting the variable +If you have a working @LaTeX{} installation and either @file{dvipng} or +@file{convert} installed@footnote{These are respectively available at +@url{http://sourceforge.net/projects/dvipng/} and from the @file{imagemagick} +suite. Choose the converter by setting the variable @code{org-latex-create-formula-image-program} accordingly.}, @LaTeX{} -fragments can be processed to produce preview images of the typeset -expressions: +fragments can be processed to produce images of the typeset expressions to be +used for inclusion while exporting to HTML (see @pxref{@LaTeX{} fragments}), +or for inline previewing within Org mode. + +@vindex org-format-latex-options +@vindex org-format-latex-header +You can customize the variables @code{org-format-latex-options} and +@code{org-format-latex-header} to influence some aspects of the preview. In +particular, the @code{:scale} (and for HTML export, @code{:html-scale}) +property of the former can be used to adjust the size of the preview images. @table @kbd @kindex C-c C-x C-l @@ -10230,13 +10234,6 @@ process the entire buffer. Remove the overlay preview images. @end table -@vindex org-format-latex-options -@vindex org-format-latex-header -You can customize the variables @code{org-format-latex-options} and -@code{org-format-latex-header} to influence some aspects of the preview. In -particular, the @code{:scale} (and for HTML export, @code{:html-scale}) -property of the former can be used to adjust the size of the preview images. - @vindex org-startup-with-latex-preview You can turn on the previewing of all @LaTeX{} fragments in a file with -- 1.9.1
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Bastien writes: > Nicolas Goaziou writes: > >> As you noticed, secondary strings are omitted in the manual, but still >> valid locations: titles in headlines or inlinetasks, inline footnotes, >> and plain list item tags. > > Any reason not to mention secondary strings? No reason besides clarity, maybe. A long list of locations could be confusing. > In this particular case, mentioning headlines and plain list items > would be useful, otherwise careful readers* may assume that macros > are not available there. What about excluding most tempting locations instead? "... which can be referenced with {{{name(arg1, arg2)}}}. These references, called macros, can be inserted anywhere Org markup is recognized. In particular, this excludes all keywords but CAPTION, TITLE, AUTHOR and EMAIL, source blocks, example blocks and comments. In addition to user-defined macros..." Regards, -- Nicolas Goaziou
[O] Small bug in example code
In the function org-toggle-iimage-in-org in the page http://orgmode.org/worg/org-configs/org-config-examples.html#sec-2_2 the call (iimage-mode) needs to be (iimage-mode 'toggle), otherwise iimage-mode is only ever switched on. (iimage-mode does toggle when used as a command, but not when called from Lisp.) -- http://rrt.sc3d.org
[O] Obsolete information in worg
In this section: http://orgmode.org/worg/org-configs/org-config-examples.html#sec-2_2 the information about yasnippet is out of date; more up-to-date information is available in the manual: http://orgmode.org/org.html#Interaction Hence, I suggest removing the references to yasnippet from the worg page. -- http://rrt.sc3d.org
Re: [O] Post() evaluates but fails in export
Bastien writes: > Oh, yes, of course. Feel free to apply it on master then. Done. Regards, -- Nicolas Goaziou
Re: [O] Navigating from agenda causes incorrect expansion of children
I think there must be a bunch of us who are experiencing this, because I am too. The fix does not work for me. 3b is never shown. * test 1 *** 2a SCHEDULED: <2014-03-19 Wed> * 3a * 3b *** 2b On 3/19/14, Bastien wrote: > Hi Dan, > > you need to have (agenda t) in `org-show-siblings'. > > See `org-show-siblings' docstring for details. > > HTH, > > -- > Bastien > > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] OrgStruct for Python source code
* Bastien wrote: > Hi Karl, Hi Bastien! > simply turn on orgstruct-mode in a python buffer and try > M-x org-cycle RET on a def: it will fold it. Oh, even better! :-) Thanks for the pointer! -- 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
Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
John Hendy gmail.com> writes: [deleted] > > > > I think the default behavior should be reverted, as tangling and > > exporting are two different things. When I tangle, I want to see the > > code blocks as they are in the org document (with possible variables and > > expansions) but not to create files where I do not put it explicitly > > into a code block. These wrappers have nothing to do with the code, and > > are only there for the exported engine. So I would either revert to the > > original behavior, or, introduce a new header argument, > > e.g. :include-wrappers, which would, if set to t, include the export > > wrappers in the tangled file. This might be useful for debugging > > exporting of code block results, but not for general tangling. > > Thanks for chiming in. This was my gut reaction to the default > behavior. I guess we're still only a sample size of 2, but > intuitively, I would think that tangling would be a separate beast in > most cases from exporting. Just to have it on the record, if I tangle, > it's usually to take the code I've used in something like a Beamer > presentation or document and combine it into a single .R file so > someone can run it without needing Org-mode. ]deleted] Sorry to be late to add my $0.02... I never want the try/catch wrappers. But noweb is indispensable. I use noweb a lot to organize and collect blocks. In some cases, I export them and in others I just tangle them. I hope that the revised code will allow me to turn off try/catch wrapping and still be able to use noweb when tangling or exporting. Best, Chuck
[O] OrgStruct for Python source code
Hi! I am evaluating methods to fold Python source code. I stumbled over orgstruct-mode which looks quite cool to me. My first test with (setq orgstruct-heading-prefix-regexp "^[ ]*##[ ]+\*[ ]") worked out of the box. Unfortunately, this attempt requires a comment linke for each Python-def in order to be able to fold at def-borders. IMHO it would be very cool if I could come up with a regexp which folds at the def-definitions like (setq orgstruct-heading-prefix-regexp "^[ ]*def .+(.*)\s-*$") -> optional white spaces followed by "def " and a name. Then the parenthesis with optional arguments followed by optional whitespaces. This should fold all defs. Unfortunately, this does not work at my side. Did I make a mistake or do I have to limit myself to matching comment lines only? Thanks! -- 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
Re: [O] mobile-org http links not recognized on iPhone
I've just tested this and you are right. If I follow the orgmode convention of http links and use the View in mobile-org, the links are clickable. But if I cut and paste a link like http://www.something.com in orgmode, it's not clickable in mobile-org View. I guess I'll have to follow the orgmode convention and redo all my http links. Thanks. On Tue, Mar 18, 2014 at 3:26 AM, Sean Escriva wrote: > > Chris Henderson writes: > > > http links on mobile-org on iPhone is not click-able and I need to select > > all, copy and paste the link on safari instead of just clicking and > opening > > it directly. Is this normal behavior? > > No links should be clickable, they are for me. For example, with the > following link in my one of my org agenda files: > > - [[http://queue.acm.org/detail.cfm?id%3D2413037][Thinking Methodically > about Performance]] > > In MobilOrg I can view the node in the doc, using the right arrow, and > then choose View as Document. The links are clickable in this view, as > other views assume editing. > > -- > -sean >
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Eric S Fraga ucl.ac.uk> writes: > You could always use the new command in the org directive, assuming you > only use LaTeX export: > > #+LATEX_HEADER: \newcommand{\orgauthor}{} > #+AUTHOR: \orgauthor > > This would avoid duplication. Brilliant!! Thank you.
[O] org-html-do-format-code: End of buffer
When I export org-file to the HTML by means of C-c C-e h H (as HTML buffer) I get the following error: org-html-do-format-code: End of buffer and exporting doesn't finish (buffer with the result doesn't appear). Mentioned org-file is pretty simple: #+name: basic-python #+begin_src python :results silent 'hello world' #+end_src In the same time for Emacs Lisp it does work, for example: #+name: basic-elisp #+begin_src emacs-lisp (defun test () (interactive) (message "Test")) #+end_src Also I tried such commands as `org-html-export-to-html' and `org-html-export-as-html' and got the following in the *Messages* buffer: org-babel-exp process python at line 2... Here is not Git work tree org-html-do-format-code: End of buffer What is the problem? Why mentioned error occurs? How can I fix it? Please help. (org-version) "8.2.5h" $ emacs --version GNU Emacs 24.3.1 I removed built in `org' package and installed it by means of el-get. Thank you, Andrey
Re: [O] Property EXPORT_OPTIONS ignored?
Hi Robert, Robert Eckl writes: > i'm trying to exclude one section from the toc > > Following http://orgmode.org/manual/Export-settings.html in following > example section 2 shoud not appear in the toc, but it appears. > > #+OPTIONS: toc:t > * Section 1 > * Section 2 > :PROPERTIES: > :EXPORT_OPTIONS: toc:nil > :END: > > What I'm missing? Subtree options set through EXPORT_OPTIONS apply to the subtree export, available through C-c C-e C-s, not to the subtree itself during normal (unrestricted) export. Maybe you can use inline tasks? Or limit the scope of the TOC like this: #+OPTIONS: toc:1 if the headlines you want to ignore are not top-level headlines. HTH, -- Bastien
Re: [O] OrgStruct for Python source code
Hi Karl, Karl Voit writes: > This should fold all defs. Unfortunately, this does not work at my > side. Did I make a mistake or do I have to limit myself to matching > comment lines only? simply turn on orgstruct-mode in a python buffer and try M-x org-cycle RET on a def: it will fold it. `orgstruct-heading-prefix-regexp' comes on top of that, if needed, but as long as `outline-regexp' is properly set, orgstruct-mode gives you the cycling commands. For example, this is the bindings I have for emacs-lisp: (global-set-key (kbd "C-M-]") (lambda () (interactive) (org-cycle t))) (global-set-key (kbd "M-]") (lambda () (interactive) (ignore-errors (end-of-defun) (beginning-of-defun)) (org-cycle))) HTH, -- Bastien
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Rasmus gmx.us> writes: > > I've used this snip to recover such fields > > \makeatletter > \let\Title\ title > \let\Author\ author > \let\Date\ date > \makeatother > > Obviously, this is only good for LaTeX. > How would I implement this? Is including in the .tex file sufficient? Having these in the Org-mode file itself? When I try in the .tex file, it appears almost verbatim as; Title title Author author I cannot get the substitution to work.
[O] bug#17040: 24.3.50; Emacs + Org mode hangs
> From: Sebastien Vauban > Date: Wed, 19 Mar 2014 15:57:36 +0100 > > Anyway, here's the backtrace I got: Thanks for the effort, but as I said several times, such backtraces are not useful without the Lisp backtrace part. All I can say from this backtrace is that you were deep inside some hook stored in before-change-functions; that hook was invoked because you inserted something into a buffer. That is all. What we need is names of some Lisp functions, preferably from Org, that we could then examine in order to look for potential infloops. That's impossible without Lisp backtrace. To get that, you need the .gdbinit file, and you need to instruct GDB to read it by using the 'source' command.
[O] Property EXPORT_OPTIONS ignored?
Hi, i'm trying to exclude one section from the toc Following http://orgmode.org/manual/Export-settings.html in following example section 2 shoud not appear in the toc, but it appears. #+OPTIONS: toc:t * Section 1 * Section 2 :PROPERTIES: :EXPORT_OPTIONS: toc:nil :END: What I'm missing? TIA, Robert Emacs 24.3.1 (Org mode 8.2.5e)
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Nicolas Goaziou writes: > Bastien writes: > >> thanks for the thorough answer, I agree. > > Champagne! ;) Hehe. >> Can we sum it up as "Macros are only available in headlines and >> paragraphs", for the sake of clarifying the Macro section in the >> manual? > > The manual states: > > "in paragraphs, verse blocks, table cells and some keywords" > > "some keywords" implicitly refers to AUTHOR, DATE, TITLE and > CAPTION. Oops, I checked a (very) old version of the manual without noticing, sorry for the noise. > As you noticed, secondary strings are omitted in the manual, but still > valid locations: titles in headlines or inlinetasks, inline footnotes, > and plain list item tags. Any reason not to mention secondary strings? In this particular case, mentioning headlines and plain list items would be useful, otherwise careful readers* may assume that macros are not available there. * I've met some. Not a big deal anyway, -- Bastien
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Bastien writes: > thanks for the thorough answer, I agree. Champagne! ;) > Can we sum it up as "Macros are only available in headlines and > paragraphs", for the sake of clarifying the Macro section in the > manual? The manual states: "in paragraphs, verse blocks, table cells and some keywords" "some keywords" implicitly refers to AUTHOR, DATE, TITLE and CAPTION. As you noticed, secondary strings are omitted in the manual, but still valid locations: titles in headlines or inlinetasks, inline footnotes, and plain list item tags. I think that's all. Regards, -- Nicolas Goaziou
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Hi Nicolas, thanks for the thorough answer, I agree. Can we sum it up as "Macros are only available in headlines and paragraphs", for the sake of clarifying the Macro section in the manual? Also, it seems that macros are only fontified in headlines and paragraphs, which matches the short description above. Is there any false positives/negatives you can think of? Thanks, -- Bastien
Re: [O] Post() evaluates but fails in export
Hi Nicolas, Nicolas Goaziou writes: >> (The patch does not apply on maint anymore though :/...) > > It never applied to maint. It was built on top of master. ISTR some > features don't exist in maint (is it :post header?). Oh, yes, of course. Feel free to apply it on master then. Thanks! -- Bastien
Re: [O] Post() evaluates but fails in export
Hello, Bastien writes: > (The patch does not apply on maint anymore though :/...) It never applied to maint. It was built on top of master. ISTR some features don't exist in maint (is it :post header?). Regards, -- Nicolas Goaziou
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Hello, Bastien writes: > Luke Crook writes: > >> It would be great if org-mode added support for substitution to the #+ >> fields. > > Nicolas, what do you think? In the current model, macros are considered part of Org syntax, like, e.g., text markup. One advantage is that they can be parsed, so you can get information about them with tools like `org-element-context'. Though,, the obvious limitation is that they can only exist wherever Org syntax is defined. In particular, you wouldn't (at least, I hope) expect bold text in a LATEX keyword (or an example block...) to be recognized. There is no macro here either, and macros behaviour is consistent with other Org syntax. It wasn't always the case. Before Org 8.0, as already written on this ML, macros were, in some sense, more powerful as you could write one almost anywhere (even though "almost" was hard to define and explain). The manual also specified that they could be used to build complex constructs. I changed the model. Indeed, since Babel was introduced in Org, macros have been, at best, an awkward way to hack an Org document (e.g., definition are only one line long, they are hard to edit). Nowadays, Babel is really the way to go for this task: you can use the language of your choice, definitions are easily editable, and so on. Thus, it is acceptable to limit a bit macros as no user is deprived from total control over its documents. In that scheme, macros are still useful in the most simple cases, e.g., as small placeholders in the middle of the document, so they are still implemented, in a limited and somewhat protected environment. I think it somehow strikes a balance between ease of use and power, as both needs are covered. I understand that it is tempting to merge the two concepts, and it is partly possible since macros can contain Babel code themselves, but I strongly believe that these tools must focus on their own niche. Or, to put it differently, I don't think that macros should overlap too much with Babel. Here, the OP wants to build conditional LaTeX code within the Org document. This is far beyond macros' scope. I suggest to rely on Babel code for the task, or even a filter, instead. In any case, there's no need to extend macros past their current limitation. Regards, -- Nicolas Goaziou
Re: [O] Incorrect hexification in URLs in LaTeX Export
On Mar 18, 2014, at 17:24, "R. Michael Weylandt" wrote: > Can't comment on Andreas's issue about unescaping text when it's given to org > already escaped. Hi Bastien, TLDR: remove ?\= from org-link-escape-chars. I looked at this again and I think I've stumbled on another small issue relating to hex escaping. If I type a link with an equals sign (=) into the link prompt of org-insert-link, the link inserted into my buffer has a %3D instead of the valid =. Tracing this, it goes through org-make-link-string, which hands off to org-link-escape which uses the defconst org-link-escape-chars as the table of values to escape. Org-link-escape-chars appears to only be used within org-link-escape at this time. I think = is escaped because it may have conflicted with the verbatim syntax at some point, but that doesn't appear to be an issue any more. Is there a reason not to remove it?
Re: [O] [patch][ox-html] Support for level based containers
On 2014-03-18 15:41, Rasmus wrote: Rick Frankel writes: On 2014-03-17 23:31, Rasmus wrote: A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline. So, using this definition, in html5, the wrappers should be =sections= to the same level as the toc heading level specified for the document, and =divs= after.[1] So you want it to be section until h:N? That should be easy. 1. The default should stay the same as it is now -- the string "div" As you prefer. But, after reviewing the spec (see above vis. =section= and =article=), i would submit that a better patch would be to implement [1] above -- remove the defcustom (i only added to support using a different default wrapper element in html5), and use =section= and =div= based on toc level when html5-fancy is true. As far as i can tell from the spec, =article= would almost never be correct for the average org doc. Here's a relevant quote from the spec: OK. That certainly makes it easier. But should it not then be a cons or an alist specifying which container to use when the headline level is above or below h:N and deepening on whether html5-fancy is used? Not really necessary. It's overly complex with no obvious advantage. I guess the right question to ask is (it may have been mentioned much earlier in the thread) -- what problem does the patch solve? Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element. So blogs, technical docs and similar? I can see people using Org such things? Or do W3-people thinkg of something different when they say it is "syndicatable" Yes, a a blog is the prototypical example -- but only the index page, where multiple articles are concatenated into a single page. Most likely, an org document implementing this would have the =article=s (indvidual blog posts) at level 1, and sections below. In the most common use, the =article= would probably be the outer wrapper around the entire body section of the output, and would be set as the "content" wrapper in =org-html-divs=. BTW, the html5 version of =org-html-divs= would be: #+BEGIN_SRC emacs-lisp '((preamble "header" "preamble") (content "article" "content") (postamble "footer" "postamble")) #+END_SRC I think the best way to implement this would be letting the user specify it with the =HTML_CONTAINER= property already implemented. As this seems very much in keeping with the spec, i will implement this change when i have some time in the next couple of weeks if i don't hear any strong arguments against. I can change my patch to this behavior if you want. Though I think it's pretty strong to hardcode values, as one would might have reasons to change it in say an ox-publish project. Using =PROPERTIES= on org heading is not really hardcoding. It's the "org-way" of associating things with document sections/headings. To recap, I don't really see a compelling reason to specify a hierarchy of wrappers specific to html5-fancy output. After reviewing the spec, i do see the value in wrapping org document sections in =section= tags per the rules in [1] above (from previous email). rick
Re: [O] [patch][ox-html] Stylistic changes
On 2014-03-18 15:46, Rasmus wrote: Rick Frankel writes: On 2014-03-17 23:36, Rasmus wrote: When you refer above to "utf-8 entities", do you mean the named html entities (e.g., <) or the actual utf-8 encoded characters? The latter. Do M-x describe-char on such an character. Emacs will tell you the code points. My conjecture is therefore that one could write a script that would translate html values to these weird hex string or codepoints. It would create more ugly source output, but perhaps better for XHTML. Personally, I don't care about XHTML as I have little intuition as to when to use. . . Do you close the empty tags in your html (e.g., , )? Then you're using xhtml. I believe the named entities are encoding independent, while including encoded characters in html output is fine -- although making sure the page is served with the correct character encoding is another issue entirely. Not what I meant. I'm only addressing your concern about &HUMAN-READABLE-NAME; vs %HEX-VALUE;. As to using a more extensive set of named entities, as i said above, the problem is that the xhtml flavors don't support them, and I don't see any advantage in making the exporter handle character encoding differently based on ouput doctype. Definitely not. Why I ask if there's a point in changing nice entities to ugly entities for the sake of not getting them in XHTML-encoded documents. Yes we should. You can't properly post-process the html if it's invalid xml. And the definition of "pretty" and "ugly" are subjective. The question is, do we want to generate valid (x)html or not? My vote is yes. In our case, html is an output format and not a source format. In fact, we should probably compress out unnecessary whitespace, etc. the way other web generators do to make the smallest/most efficent output for webserving. As Nicolas would point out, you can always use a filter to map all the entities in the output. With ox-latex.el we for instance don't include entities that are not supported by the default package alist. A similar concern could be at play here. Agreed.
Re: [O] why I got the message
hi, I figured out! after restart emacs with (require 'ox), I found a strange error message: Wrong type argument: integerp, (48 . 57) and the error message disapeared after updating emacs from 24.0.95-1 to 24.1-7, and M-S- also works! thanks again!
Re: [O] why I got the message
Dillon Peng writes: > Bastien gnu.org> writes: > >> >> Hi Dilon, >> >> I cannot reproduce the problem. >> >> Please M-x org-version RET and report the *whole* indication, >> it might be a problem in your installation. > > I got the message when M-x org-version RET: > Org-mode version 8.2.5h (8.2.5h-dist @ /study/doctor/note/org-8.2.5h/lisp/) > > I used the org-8.2.5h's source without executing "make and make install", > so that the above path was not standard path (ex. /usr/share/emacs/site-lisp). > and It seems be able to work well for other things such as exporting html. > thanks again! > Can't reproduce it either: I only get this kind of error if point is not within the table. -- Nick
Re: [O] why I got the message
Bastien gnu.org> writes: > > Hi Dilon, > > I cannot reproduce the problem. > > Please M-x org-version RET and report the *whole* indication, > it might be a problem in your installation. I got the message when M-x org-version RET: Org-mode version 8.2.5h (8.2.5h-dist @ /study/doctor/note/org-8.2.5h/lisp/) I used the org-8.2.5h's source without executing "make and make install", so that the above path was not standard path (ex. /usr/share/emacs/site-lisp). and It seems be able to work well for other things such as exporting html. thanks again! > > Best, >
Re: [O] verbatim and apostrophes
Hi Alan, Alan Schmitt writes: > A suggestion could be to allow any text inside the markers, except for > the marker itself which would need to be escaped. Escaping could take > the form of doubling the marker: > > ~"foo bar"~ --> "foo bar" > ~"foo ~~ bar"~ --> "foo ~ bar" > > As I've not thought this through, I'm pretty sure someone will find a > huge flaw in this suggestion. Well, the huge flaw will never be obvious with such solutions... because the flaw is precisely this: it hides huge flaws. (Do not bother parsing the above, I'm not sure myself.) FWIW here is my gut reaction: I'm not a fan (euphemism) of escaping here, I feel like it adds little value while bumping complexity too much. But exploring it might be worth it, if someone wants to try! -- Bastien
Re: [O] link interfering with brackets when abbreviated
Samuel Wales writes: > btw, the nuclear power plant MUST be painted blue. FWIW, I strongly disagree. -- Bastien
Re: [O] special table from clock
Hi Martin, Martin writes: > But I'm unsure how to store the data for that in my APPT entries: I > could use properties (but how?) and I would really like to use the > CLOCK entries for calculating the times. Well, this *is* a complex request. One quick idea is to use properties and to look at org-collector.el from the contrib/ repository. What is not clear is whether you are confortable with writing Elisp. If you are, then starting from org-collector.el and writing your own transformation functions will surely lead to something... sorry for not being more helpful here. Best, -- Bastien
Re: [O] why I got the message
Hi Dilon, I cannot reproduce the problem. Please M-x org-version RET and report the *whole* indication, it might be a problem in your installation. Best, -- Bastien
Re: [O] Problem with org-bibtex-read with fields type, key
Hi Stefan, "Stefan-W. Hahn" writes: > I have a little problem with org-bibtex function org-bibtex-read: > > My bibtex entries have the keyword "type" and "key". When > reading such an entry with org-bibtex-read I get an alist > with the entries ":type" and ":key" each twice. Yes, I confirm the bug -- by any chance, did you have time to sort this out? (I see you already committed a fix to org-bibtex.el) Thanks in advance, -- Bastien
[O] why I got the message
hi, all my emacs is GNU Emacs 24.0.95.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.24.10), org is 8.2.5h when I used C-c | to add a table 5X2 as follows: | d | | | | | |---+---+---+---+---| | d | | | | | and place cursor at "d" in 1 x 1, and (1) press M-x org-table-delete-column, I got the following message: user-error: This command is active in special context like tables, headlines or items (2) press M-x org-table-insert-row, I got : Not at a table how to resolve it, or what I missed, any advice will be appreciated! Dillon Peng
Re: [O] following org links to gnus messages and window management
Hi Bastien, Bastien writes: >> - if not, is there a way to copy a link then open it using the >> minibuffer (I would then do the switch to screen 0 manually)? > > This does not use the minibuffer but you could add that: > > (progn > (org-next-link) > (org-open-link-from-string >(org-element-property :raw-link (org-element-link-parser This was most helpful: I just need to copy the link I want to follow, go to the first screen, and interactively call `org-open-link-from-string'. This works great for the moment. >> - finally, do you have alternative window management options to suggest >> that would work well with following links to gnus messages? > > Well, all I can think of now is > > (setq org-agenda-window-setup 'other-frame) Thanks, but I'm trying to avoid using several frames. (OS X unfortunately does not come with a window manager that I like ...) Thanks again, Alan
Re: [O] Post() evaluates but fails in export
Hi Nicolas, Nicolas Goaziou writes: > The attached patch should fix the issue. Could you confirm it? I just tested and it fixes the issue. I'll Jarmo double-confirm this. (The patch does not apply on maint anymore though :/...) Thanks in advance for apply it! -- Bastien
Re: [O] HTML table export options essentially undocumented
Hi James, James Harkins writes: > It may be useful to link to this from the page on tables in HTML > export, then. I slightly enhance the "Tables in HTML export" section of the manual. Thanks, -- Bastien
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Eric S Fraga writes: > Luke Crook writes: > >> I tried creating a custom class and then tried creating a custom style. But >> I found the easiest to be the following; >> >> >> #+AUTHOR: >> #+LATEX_HEADER: \newcommand{\orgauthor}{} > > [...] > >> Works very well, apart from the duplication of author, email, date etc. > > You could always use the new command in the org directive, assuming you > only use LaTeX export: > > #+LATEX_HEADER: \newcommand{\orgauthor}{} > #+AUTHOR: \orgauthor > > This would avoid duplication. I've used this snip to recover such fields \makeatletter \let\Title\@title \let\Author\@author \let\Date\@date \makeatother Obviously, this is only good for LaTeX. -- There are known knowns; there are things we know that we know
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Luke Crook writes: > I tried creating a custom class and then tried creating a custom style. But > I found the easiest to be the following; > > > #+AUTHOR: > #+LATEX_HEADER: \newcommand{\orgauthor}{} [...] > Works very well, apart from the duplication of author, email, date etc. You could always use the new command in the org directive, assuming you only use LaTeX export: #+LATEX_HEADER: \newcommand{\orgauthor}{} #+AUTHOR: \orgauthor This would avoid duplication. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.5h-660-gef207f
Re: [O] following org links to gnus messages and window management
Hi Alan, Alan Schmitt writes: > When I follow a link in a task to a gnus file, this takes over the > current frame, and when I'm done dealing with the message, I have to > "winner-undo" my way until I restore my window configuration. This is > not very convenient. > > My questions are: > - is there a way to run some code before following a link (for instance > "save the current window configuration", or "switch to screen 0")? Nope. > - if not, is there a way to copy a link then open it using the > minibuffer (I would then do the switch to screen 0 manually)? This does not use the minibuffer but you could add that: (progn (org-next-link) (org-open-link-from-string (org-element-property :raw-link (org-element-link-parser > - finally, do you have alternative window management options to suggest > that would work well with following links to gnus messages? Well, all I can think of now is (setq org-agenda-window-setup 'other-frame) > I remember > seeing something nice in Sacha Chua's interview of Magna Sveen > mentioning "perspective-mode", but I have not tried it yet. Me neither! Hope that helps, -- Bastien
Re: [O] Is there an environment for Org syntax?
Hi Fletcher, Fletcher Charest writes: > When I use the edit buffer (by pressing C-c '), my Org syntax is > indented properly (in accordance with org-indent-mode, which is set > to t). The code block itself looks like this after editing: > > #+BEGIN_SRC org :exports code > ,* Top level headline > ,** Second level > ,*** Third level > some text > ,*** Third level > more text > #+END_SRC > > As you can see, the text ('some text' and 'more text') is not > indented. This is a little bit annoying, but not too much - I can add > the spaces myself. The indentation of the exported HTML looks correct to me: "some text" is right below "*** Third level" > The problem is with the HTML export: I can't see the HTML output as I > would see it in my Emacs buffer, that is to say, without the leading > stars. In my output (see attached), leading stars are visible, > although not colored. I would like them to be completely invisible. The HTML color of the leading stars is taken from the org-hide face. When your background is black, the org-hide face is black, hence the color you see in the HTML output. HTH, -- Bastien
Re: [O] HTML table export options essentially undocumented
On Mar 18, 2014 4:45 PM, "Nicolas Goaziou" wrote: > Did you try column groups? > > (info "(org) Column groups") > > It is not back-end specific. No, I hadn't... I was in a rush and trying to do something that I thought would be simple (and just a quick and dirty one-off export). Even given more time, I'm not sure I would have thought to look in the tables section. It may be useful to link to this from the page on tables in HTML export, then. hjh
Re: [O] Strange newline characters in org-export-as-html
Hi Grant, Grant Rettke writes: > My config is definitely to blame. > > With my config newlines are output as: Okay, thanks for confirming, -- Bastien
Re: [O] Navigating from agenda causes incorrect expansion of children
Hi Dan, you need to have (agenda t) in `org-show-siblings'. See `org-show-siblings' docstring for details. HTH, -- Bastien
Re: [O] [patch] capture property table-line-pos can be a function
Hi Bastien, · Bastien wrote: > Hi Thomas, > > Thomas Holst writes: > >> I am sorry, I used =git format-patch= for the patches assuming all will >> go well. Here are both patches with rewritten commit messages. Hopefully >> I made them well. > > No problem -- the game now is to find the small differences between > your original patches and the ones I just committed :) > > http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=176125c3 > http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=599ccd1c > > Thanks for this, ok noticed the differences. Next time I'll be better :-) Thank you for accepting the patch. Now my local branch in org-mode is empty. -- Bis neulich ... Thomas
Re: [O] [PATCH] Fix clock table when there are links in headings.
Hi Alexey, Alexey Lebedeff writes: > But I don't want do disable linking agenda clocktable row to the > original heading, it's very convenient. I just want it to look pretty, > but the thing from the screenshot looks really ugly. Patch affects > execution only when :link is true. Of course you're right. I pushed this change: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=3a233a It should do what you want -- thanks for insisting and for the patch you submitted for this. -- Bastien
Re: [O] A JavaScript Org-mode parser I'm experimenting with
Hi François, hi Masafumi, François Pinard writes: > Just want to share that, for the last few days, I'm playing with a > JavaScript Org-mode parser written by Masafumi Oyamada, found here: > > https://github.com/mooz/org-js Looks great! Thanks for this Masafumi. > Might someone, familiar enough with the Org mode Web site, add a pointer > for it in the http://orgmode.org/worg/org-tools/index.html page? I added a link to this page together with a few information: http://orgmode.org/worg/org-tools/#sec-1-10 Thanks, -- Bastien
Re: [O] [PATCH] Fix clock table when there are links in headings.
Hi Bastien, 2014-03-18 20:10 GMT+04:00 Bastien : > Hi Alexey, > > Alexey Lebedeff writes: > >> Sorry, I failed to explicitly mention that it was in agenda >> clockreport. It was in the screenshot, but I forgot that clocktable is >> used in other places than agenda. > > You need to configure `org-agenda-clockreport-parameter-plist' > like this: > > (setq org-agenda-clockreport-parameter-plist '(:link nil :maxlevel 2)) But I don't want do disable linking agenda clocktable row to the original heading, it's very convenient. I just want it to look pretty, but the thing from the screenshot looks really ugly. Patch affects execution only when :link is true.
Re: [O] [patch] capture property table-line-pos can be a function
Hi Thomas, Thomas Holst writes: > I am sorry, I used =git format-patch= for the patches assuming all will > go well. Here are both patches with rewritten commit messages. Hopefully > I made them well. No problem -- the game now is to find the small differences between your original patches and the ones I just committed :) http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=176125c3 http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=599ccd1c Thanks for this, -- Bastien
Re: [O] [PATCH] Only set org-hide foreground if one is available
Hi Nikolai, Nikolai Weibull writes: > Sorry, I realize that I was way too terse. No problem. Thanks for the detailed explanations, makes sense. I pushed your patch. Thanks, -- Bastien
[O] following org links to gnus messages and window management
Hello, I'm using escreen (http://www.emacswiki.org/emacs/EmacsScreen) to manage my windows in emacs, typically keeping gnus on screen 0, org agenda and related todo files on screen 2, and so on. When I follow a link in a task to a gnus file, this takes over the current frame, and when I'm done dealing with the message, I have to "winner-undo" my way until I restore my window configuration. This is not very convenient. My questions are: - is there a way to run some code before following a link (for instance "save the current window configuration", or "switch to screen 0")? - if not, is there a way to copy a link then open it using the minibuffer (I would then do the switch to screen 0 manually)? - finally, do you have alternative window management options to suggest that would work well with following links to gnus messages? I remember seeing something nice in Sacha Chua's interview of Magna Sveen mentioning "perspective-mode", but I have not tried it yet. Thanks, Alan