[O] Check for compilation error
Hi all What is the reason that make check does not stop at the first compilation error with a non-zero exit status? Michael
Re: [O] [patch] extend org-meta-return to keywords
Hello, Rasmus ras...@gmx.us writes: Attached is a new version of the patch that will respect the variables that also govern `org-insert-headline'. It's smarter and preserves the layout better. Thanks for the patch. However there are already mechanisms to complete keywords faster (e.g., M-TAB, yasnippet). Of course, yours is more efficient, but also very specific. It makes sense on very few keywords. I have no strong opinion here, but I don't think it is general enough to go into core. Moreover, it can get in the way of expected M-RET behaviour, as in the following example - item | #+caption: test untenrsiu where M-RET is expected to insert an item. Anyway, some comments follow. + (point-at-bol-p (looking-back ^[[:space:]]*)) (point-at-bol-p (save-excursion (skip-chars-backward \t) (bolp))) See last paragraph in `looking-back' docstring. + (end-of-keyword + (save-excursion + (beginning-of-line) + (search-forward-regexp Nitpick: `re-search-forward' + org-element--affiliated-re (point-at-eol) t) Nitpick: `line-end-position' Also, you're not supposed to use `org-element--affiliated-re', as suggested by the double hyphen. If you want to tell when point is at an affiliated keyword, use ( (point) (org-element-property :post-affiliated element)) where ELEMENT is returned by `org-element-at-point'. You can then extract its name with, e.g., (save-excursion (beginning-of-line) (looking-at #\\+\\(.+?\\):) (upcase (org-match-string-no-properties 1))) + (elm (org-element-at-point)) + (key (and (eq 'keyword (org-element-type elm)) +(org-element-property :key elm +(when key KEY is nil when at an affiliated keyword. So this function is a no-op on #+CAPTION: and alike. Try it on a real caption, e.g., #+CAPTION: caption Paragraph + (when point-at-bol-p (open-line 1) + ;; Open-line makes sometimes ruins indention of the + ;; previous line. + (save-excursion (forward-line 1) + (org-indent-line))) Don't use `open-line' at all. Insert \n where appropriate. Also avoid using `org-indent-line' since you can already know what the expected indentation is (i.e., by storing it earlier). + (unless may-split (end-of-line)) + (unless point-at-bol-p + (when ( (point) end-of-keyword) + (goto-char end-of-keyword)) + (insert \n)) + (insert (format #+%s: key)) + (org-indent-line Ditto. Use stored indentation. +((and (eq type 'keyword) + ;; Keyword such as LATEX, ATTR_LATEX, CAPTION, and HEADER, + ;; LATEX_HEADER, LATEX etc. can occur multiple times. + (let ((key (org-element-property :key element))) +(if (member key org-element-affiliated-keywords) +(member key org-element-multiple-keywords) + t))) KEY cannot belong to `org-element-affiliated-keywords'. See above. Also, (or (not (member key org-element-affiliated-keywords)) (member key org-element-multiple-keywords)) Regards, -- Nicolas Goaziou
Re: [O] Check for compilation error
Michael Brand writes: What is the reason that make check does not stop at the first compilation error with a non-zero exit status? Emacs doesn't behave like a compiler. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [patch] extend org-meta-return to keywords
Hi,
Thanks for the comments.
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Rasmus ras...@gmx.us writes:
Attached is a new version of the patch that will respect the variables
that also govern `org-insert-headline'. It's smarter and preserves the
layout better.
Thanks for the patch. However there are already mechanisms to complete
keywords faster (e.g., M-TAB, yasnippet).
Personally, I never figured out how to use yasnippet. M-TAB is for
completion of new lines, not for continuation of ongoing work.
Of course, yours is more efficient, but also very specific.
So say you do
#+LATEX_HEADER: \usepackage{biblatex}
Now you need to add a bib resource. It's nice to quickly be able to get
a new #+LATEX_HEADER-line. It's specific, but it's meant as a
continuation of the M-RET logic.
It makes sense on very few keywords. I have no strong opinion here,
but I don't think it is general enough to go into core.
OK. Hopefully some more people will chime in so we can make an educated
guess.
Moreover, it can get in the way of expected M-RET behaviour, as in the
following example
- item
| #+caption: test
untenrsiu
where M-RET is expected to insert an item.
Sure. . . I'm not sure expected behavior is what I'd like here. But
that's the initial point, I guess.
Anyway, some comments follow.
Thanks for those.
Cheers,
Rasmus
--
The second rule of Fight Club is: You do not talk about Fight Club
Re: [O] [Prelim. patch] extend org-meta-return to keywords
M-RET working as expected is appealing. Your patch makes M-RET moreuseful than it is now. I vote +1. There are a few issues thought. I guess they can be worked out. For instance: #+HEA|DER: :var v=hello (cursor is the pipe |) ischanged into #+HEA #+HEADER: |DER: :var v=hello which is pretty useless Also if #+HEADER: is immediately followed by a #+BEGIN_SRC, the patch (for an unknown reason) is ignored, and the old behavior applies. Thanks for this Thierry Le 19/11/2014 15:41, Rasmus a écrit : Hi, Something I have wanted for a while is to have M-RET work as expected(?) on keyword lines such as #+LATEX_HEADER, #+CAPTION etc. An animation to illustrate, where '|' is point: #+CAPTION: this is a |long caption # click M-RET ⇒ #+CAPTION: this is a #+CAPTION: |long caption Would anyone else like this? Attached is a quick patch that works surprisingly well. I would work more on it if you guys agree this would be useful. It probably need much more work for corner-cases (any ideas what these are)? Thanks, Rasmus
Re: [O] [Prelim. patch] extend org-meta-return to keywords
Hi Thierry, Thanks for the feedback. I posted an updated patch under the subject: [patch] extend org-meta-return to keywords where Nicolas commented. Thierry Banel tbanelweb...@free.fr writes: M-RET working as expected is appealing. Your patch makes M-RET moreuseful than it is now. I vote +1. There are a few issues thought. I guess they can be worked out. For instance: #+HEA|DER: :var v=hello (cursor is the pipe |) ischanged into #+HEA #+HEADER: |DER: :var v=hello which is pretty useless Thanks. I'm pretty sure it's fixed in the version from last night. Also if #+HEADER: is immediately followed by a #+BEGIN_SRC, the patch (for an unknown reason) is ignored, and the old behavior applies. OK, that's a good test case. I will look into it. Thanks, Rasmus -- Enough with the bla bla!
Re: [O] [Prelim. patch] extend org-meta-return to keywords
Le 22/11/2014 15:31, Rasmus a écrit : There are a few issues thought. I guess they can be worked out. For instance: #+HEA|DER: :var v=hello (cursor is the pipe |) ischanged into #+HEA #+HEADER: |DER: :var v=hello which is pretty useless Thanks. I'm pretty sure it's fixed in the version from last night. Sorry, Rasmus, I should have noticed your second patch. First issue fixed! Regard, Thierry
Re: [O] Bernt Hansen's
Sebastien Vauban sva-n...@mygooglest.com writes: Hello Rene, rene wrote: Indeed - Bernt's writeup has been the source of inspiration for lots of people on this list. For sure. I find his code pretty close to what GTD should look like. There are a few things though that could be twicked a bit in order to comply with David Allen's new book on Getting Things Done. Can you detail them, for our own information, please? Best regards, Seb I'd like to see these as well, please! Dave
[O] include a specific PDF page to org beamer
Hi there,
I was wondering if there is a way to import a specific PDF page
in org beamer?
I tried the following ways but neither 1 or 2 worked and I had to
retreat to 3, which is a pain as it requires those extra lines for
each link.
1.
[[file:~/path/to/myfigure.pdf::10]]
2.
#+ATTR_LATEX: page=10
[[file:~/path/to/myfigure.pdf]]
3.
#+begin_LaTeX
\includegraphics[page=10]{file:~/path/to/myfigure.pdf}
#+end_LaTeX
Many thanks!
Zhihao
Re: [O] [patch] extend org-meta-return to keywords
Hi, First, Thierry, I think this patch fixes the second misbehavior you observed. Nicolas Goaziou m...@nicolasgoaziou.fr writes: I looked through your comments and as always they made the patch much better! Thanks! Moreover, it can get in the way of expected M-RET behaviour, as in the following example - item | #+caption: test untenrsiu I don't know if I should do something about this case. I guess it would be possible, but I find it awkward when behavior $BUTTON depends not only on not only the adjacent element, but also the previous element. If it's important, I guess it should be toggled explicitly on by a custom variable. (point-at-bol-p (save-excursion (skip-chars-backward \t) (bolp))) See last paragraph in `looking-back' docstring. Thanks, that's nice. Also, you're not supposed to use `org-element--affiliated-re', as suggested by the double hyphen. If you want to tell when point is at an affiliated keyword, use ( (point) (org-element-property :post-affiliated element)) That's a great tip in its own right, but actually I used `org-element--affiliated-re' for determining if point was in/on the keyword, as here: #+CAPT|ION: foo Anyway, I changed it to fixed regexp. Presently, it's hardcoded. Should I introduce a new defvar or just live with the hardcodedness? where ELEMENT is returned by `org-element-at-point'. You can then extract its name with, e.g., (save-excursion (beginning-of-line) (looking-at #\\+\\(.+?\\):) (upcase (org-match-string-no-properties 1))) In the current patch I run this code twice, once in `org-meta-return', once in `org-insert-keyword' (basically twice). I would probably be possible to pass the keyword as an argument, but I'm not sure it's worth it. Also, `org-insert-keyword' is not really using org-element anymore. + (elm (org-element-at-point)) + (key (and (eq 'keyword (org-element-type elm)) + (org-element-property :key elm +(when key KEY is nil when at an affiliated keyword. So this function is a no-op on #+CAPTION: and alike. Try it on a real caption, e.g., #+CAPTION: caption Paragraph Good call. I detect this case with (org-element-property :post-affiliated element) now. It seems to work in the variation of this I could come up with. Quick testing suggest that affiliated keywords are always on the top of an (greater) element. + (when point-at-bol-p (open-line 1) +;; Open-line makes sometimes ruins indention of the +;; previous line. +(save-excursion (forward-line 1) +(org-indent-line))) Don't use `open-line' at all. Insert \n where appropriate. Also avoid using `org-indent-line' since you can already know what the expected indentation is (i.e., by storing it earlier). Thanks. Actually, I think I saw `open-line' in `org-insert-headline` and that's why I used it. Perhaps that's another patch. + ((and (eq type 'keyword) + ;; Keyword such as LATEX, ATTR_LATEX, CAPTION, and HEADER, + ;; LATEX_HEADER, LATEX etc. can occur multiple times. + (let ((key (org-element-property :key element))) + (if (member key org-element-affiliated-keywords) + (member key org-element-multiple-keywords) + t))) KEY cannot belong to `org-element-affiliated-keywords'. See above. It test that *if* it's a member of `org-element-affiliated-keywords' then it should also be a member of `org-element-multiple-keywords'. Anyway, your test is nicer: Also, (or (not (member key org-element-affiliated-keywords)) (member key org-element-multiple-keywords)) Cheers, Rasmus -- Summon the Mothership! From 2e70cf7c7df61eebcc10e48077c5212d9015900e Mon Sep 17 00:00:00 2001 From: rasmus ras...@gmx.us Date: Wed, 19 Nov 2014 15:39:19 +0100 Subject: [PATCH] org.el: Add keyword-support to M-RET * org.el (org-insert-keyword): New function. (org-meta-return): May call `org-insert-keyword'. (org-M-RET-may-split-line): Add keyword. --- lisp/org.el | 91 + 1 file changed, 80 insertions(+), 11 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 6ab13f4..3405ab4 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1601,6 +1601,7 @@ contexts. Valid contexts are: headline when creating a new headline item when creating a new item table in a table field +keyword when creating a new keyword default the value to be used for all contexts not explicitly customized :group 'org-structure @@ -1614,6 +1615,7 @@ default the value to be used for all contexts not explicitly (const headline) (const item) (const table) + (const keyword) (const default)) (boolean) @@ -7725,8 +7727,8 @@ split the line and create a new headline with the text in the current line after point \(see
[O] Patch org-capture-set-target-location
Patch proposal for org-capture-set-target-location The idea is that when somebody use the function or file+function targets you can make the template subheading from the heading where the custom-function set the point. org-capture-set-target-loction force the org-capture-plist :exact-position to (point). So the template is inserted in the same level not as subheading With my patch the custom-function can (org-capture-put :exact-position nil), and now if point its placed in a heading the template is created as his subheading. For a use case can look at the following emacs.stackexchange question http://emacs.stackexchange.com/questions/3750/org-capture-files-entry-under-wrong-datetree/3765#3765 Thanks. Roberto Huelga. 0001-org-capture.el-set-exact-position-only-if-not-set.patch Description: Binary data
[O] [Babel] Detangling with Noweb references.
Hi all,
I would like detangling to work even where there are Noweb references in
code chunks.
My reason for this is that I've have hit the following case several times
and haven't found a satisfactory answer yet:
1. I would like to break up the code within braces or parens into their own
chunks
2. I would like to be able to detangle the code in those chunks. This
effectively means ( I think ) that Noweb style references are not a
possibility currently.
3. I don't want chunks that simply open and close parens/braces.
An example might look like:
method {
code;
code;
/* --- Chunk 1 --- */
/* --- End --- */
code;
/* --- Chunk 2 --- */
...
/* --- End --- */
}
Can anyone think of an alternative. And if not does anyone have any
interest in this functionality or is someone already working on this?
Thanks!
-deech
Re: [O] [Babel] Detangling with Noweb references.
http://orgmode.org/manual/prologue.html#prologue
and
http://orgmode.org/manual/epilogue.html#epilogue
come to mind but I am not sure whether that applies to your case or not.
On Sat, Nov 22, 2014 at 2:06 PM, aditya siram aditya.si...@gmail.com wrote:
Hi all,
I would like detangling to work even where there are Noweb references in
code chunks.
My reason for this is that I've have hit the following case several times
and haven't found a satisfactory answer yet:
1. I would like to break up the code within braces or parens into their own
chunks
2. I would like to be able to detangle the code in those chunks. This
effectively means ( I think ) that Noweb style references are not a
possibility currently.
3. I don't want chunks that simply open and close parens/braces.
An example might look like:
method {
code;
code;
/* --- Chunk 1 --- */
/* --- End --- */
code;
/* --- Chunk 2 --- */
...
/* --- End --- */
}
Can anyone think of an alternative. And if not does anyone have any interest
in this functionality or is someone already working on this?
Thanks!
-deech
--
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson
Re: [O] include a specific PDF page to org beamer
Hi Zhihao,
Zhihao Ding zhihao.d...@imm.ox.ac.uk writes:
1.
[[file:~/path/to/myfigure.pdf::10]]
2.
#+ATTR_LATEX: page=10
[[file:~/path/to/myfigure.pdf]]
3.
#+begin_LaTeX
\includegraphics[page=10]{file:~/path/to/myfigure.pdf}
#+end_LaTeX
3. can be reduced to
#+LATEX: \includegraphics{myfig.pdf}
However, probably this is what you are looking for:
#+ATTR_LATEX: :options page=10 :width 10cm
[[file:myfig.pdf]]
For other backends than LaTeX, a solution would be more involved.
Hope it helps,
Rasmus
--
Send from my Emacs
Re: [O] [patch] extend org-meta-return to keywords
Le 22/11/2014 20:26, Rasmus a écrit : Hi, First, Thierry, I think this patch fixes the second misbehavior you observed. Fixed! I was wondering, is there any reason why the new inserted keyword is UPPERCASED? If not, maybe it would be better to keep the oriGiNaL cASe.
[O] disable title-format h1%s/h1\n when exporting html
Dear list, I would like my org html exporter to not include the title as an H1 header. According to this (http://orgmode.org/worg/org-contrib/org-export-generic.html), I think I could do it by setting it to blank in my init file. However, I'd like to keep as is the default, but would like to disable the inclusion of h1%s/h1\n for each project/org file by itself. Is there any way to set this option within the org file? Thanks for your help. -- Vinh
Re: [O] [patch] extend org-meta-return to keywords
Rasmus ras...@gmx.us writes: Moreover, it can get in the way of expected M-RET behaviour, as in the following example - item | #+caption: test untenrsiu I don't know if I should do something about this case. I guess it would be possible, but I find it awkward when behavior $BUTTON depends not only on not only the adjacent element, but also the previous element. If it's important, I guess it should be toggled explicitly on by a custom variable. M-RET, is, first and foremost, an important keybinding for editing the /structure/ of the document. The behaviour you want to add has nothing to do with structure. As a consequence, I'm not sure it should go with M-RET, and if it does, I'm pretty sure it should not override the main purpose of the binding. Inserting headlines, and possibly items, is much more important than duplicating keywords. Also, you're not supposed to use `org-element--affiliated-re', as suggested by the double hyphen. If you want to tell when point is at an affiliated keyword, use ( (point) (org-element-property :post-affiliated element)) That's a great tip in its own right, but actually I used `org-element--affiliated-re' for determining if point was in/on the keyword, as here: #+CAPT|ION: foo You need to check if either element has `keyword' type or if you're on an affiliated keyword. If you ignore this, like you did, you end up introducing false positives like #+begin: |something ... #+end: Anyway, I changed it to fixed regexp. Presently, it's hardcoded. Should I introduce a new defvar or just live with the hardcodedness? A defconst is preferable, IMO. Also, `org-insert-keyword' is not really using org-element anymore. It should since you make it interactive and can, therefore, be called on its own. + ((and (eq type 'keyword) +;; Keyword such as LATEX, ATTR_LATEX, CAPTION, and HEADER, +;; LATEX_HEADER, LATEX etc. can occur multiple times. +(let ((key (org-element-property :key element))) + (if (member key org-element-affiliated-keywords) + (member key org-element-multiple-keywords) +t))) KEY cannot belong to `org-element-affiliated-keywords'. See above. It test that *if* it's a member of `org-element-affiliated-keywords' then it should also be a member of `org-element-multiple-keywords'. I was pointing out that your test was always false. Anyway, it doesn't matter anymore since you changed that part. Some comments follow: + (indention + (buffer-substring +(line-beginning-position) +(save-excursion + (beginning-of-line) + (skip-chars-forward \t) + (point Another option: (ind (org-get-indentation)) Then, after inserting \n, (org-indent-line-to ind) + (keyword-re #\\+\\(.+?\\):) + (key (save-excursion (beginning-of-line) + (skip-chars-forward \t) + (looking-at keyword-re) + (upcase (org-match-string-no-properties 1 As discussed above, this is too fragile. You need to duplicate the checks done in `org-meta-return' or refactor the code. + (end-of-keyword (save-excursion +(beginning-of-line) +(re-search-forward keyword-re (line-end-position) t) +(point (end-of-keyword (save-excursion (beginning-of-line) (search-forward :)) +(when key I think end-of-keyword should be bound after KEY is checked to avoid errors. + (insert \n)) + (insert (concat indention (format #+%s: key))) (insert indentation (format #+%s: key)) +((and + (or (eq type 'keyword) + ( (point) (org-element-property :post-affiliated element))) + (let ((key (save-excursion + (beginning-of-line) + (skip-chars-forward \t) + (and (looking-at #\\+\\(.+?\\):) ^[ \t]*#\\+\\(.+?\\): avoids the `skip-chars-forward' part. +(upcase (org-match-string-no-properties 1)) Actually, you don't need `upcase' if you use `member-ignore-case' below. +(and key + (or (not (member key org-element-affiliated-keywords)) + (member key org-element-multiple-keywords) See above. Regards,
Re: [O] Code, Sessions, and org-edit-special
Hi List, A simpler phrasing of my previous question. How do I find out if an Org function, `org-ctrl-c-ctrl-c`, was called somewhere up the stack. I'm trying to modify a function python-shell-get-process-name, but I don't want it to be modified when somewhere, possibly far upstream, Org is happening. Perhaps this is the wrong approach? Rather than examining the stack, should I just be checking if Org is the active mode? But I think when a code segment is executed, a temp file is created and Org isn't the active mode? Thanks, -k. * On 2014-11-21 at 18:38, Ken Mankoff wrote: Hi List, I'm trying to improve my code workflow. I use python and sessions. I'd like to be able to run code in the session even if I'm editing/viewing the code via `org-edit-special`. Furthermore, when I edit code outside of Org, I'd like to have sessions, that is, optionally one Python session per source file. This allows me to edit different code for different projects in different folders on virtual desktops, etc. I've solved the non-Org part of this with the following one re-defined and one new function: #+BEGIN_SRC emacs-lisp (defun elpy-shell-get-or-create-process () Get or create an inferior Python process for current buffer and return it. (let* ((bufname (format *%s* (kdm/python-shell-get-process-name t))) (proc (get-buffer-process bufname))) (if proc proc (run-python (python-shell-parse-command) t nil) ;; DEDICATED! (get-buffer-process bufname (defun kdm/python-shell-get-process-name (dedicated) (if (boundp 'py-buf-proc-name) (format %s py-buf-proc-name) (setq-local py-buf-proc-name (format %s (completing-read Python session name: nil nil nil (buffer-name) nil (buffer-name))) ))) #+END_SRC Now when I C-c C-c in a buffer without an associated Python session, I'm prompted for a name (defaulting to the buffer-name). I provide a session name, and then all future C-c C-c's for that buffer are executed there. This is good for Org. If I name a session foo, I can edit code in org-edit-special, assign Python session foo, and execute code in a session either from the org buffer or from the temp .py file. In theory. But since I've call kdm/pythons-shell-get-process-name, if I try to C-c C-c in a #+BEGIN_SRC section, it no longer works. I'm prompted for a session name (I should not be). Whatever I enter is ignored, and the code is executed either in a temporary *Python* if no :session, or in the :session name as it should be. How can I find out inside my `kdm/python-shell-get-process-name` if it was called from Org, in which case I would implement the original version. Thanks, -k.
[O] Documentation for NOBLOCKING property?
Just now, I needed to exempt a couple of subtrees from TODO dependency blocking. I found that you can do this by setting a subtree property NOBLOCKING. This option appears to be undocumented (by which I mean, it isn't mentioned in the manual's dependency checking page, and a web search for orgmode todo noblocking turned up pages about TODOs but none with any obvious reference to noblocking). I found the property by grepping the .el sources for blocked to find the org-todo function, and then scanning the function until I found something that looked like property access. Was it intentional to omit this from the documentation? hjh
Re: [O] Documentation for NOBLOCKING property?
Hi, James Harkins jamshar...@qq.com writes: Just now, I needed to exempt a couple of subtrees from TODO dependency blocking. I found that you can do this by setting a subtree property NOBLOCKING. This option appears to be undocumented (by which I mean, it isn't mentioned in the manual's dependency checking page, and a web search for orgmode todo noblocking turned up pages about TODOs but none with any obvious reference to noblocking). I found the property by grepping the .el sources for blocked to find the org-todo function, and then scanning the function until I found something that looked like property access. Was it intentional to omit this from the documentation? Indeed I have *never* heard of this. I guess it should be documented or something. Would you provide a patch? —Rasmus -- Er du tosset for noge' lårt!
Re: [O] disable title-format h1%s/h1\n when exporting html
Hi, Vinh Nguyen vinhdi...@gmail.com writes: Dear list, I would like my org html exporter to not include the title as an H1 header. According to this (http://orgmode.org/worg/org-contrib/org-export-generic.html), I think I could do it by setting it to blank in my init file. However, I'd like to keep as is the default, but would like to disable the inclusion of h1%s/h1\n for each project/org file by itself. Is there any way to set this option within the org file? Thanks for your help. So do you want no title at all or do you want to only suppress the h1-representation? For the former just don't set the title or use #+TITLE: For the latter you'd probably need a filter. Hope it helps, Rasmus -- And when I’m finished thinking, I have to die a lot
