[O] [BUG] Inconsistency in src block hiding
Hello, In the following example (latest Org), with point at |, when TAB is pressed, block gets hidden at the name level. --8---cut here---start-8--- |#+name: test #+begin_src emacs-lisp test #+end_src --8---cut here---end---8--- It is because `org-babel-result-regexp' is matched in `org-babel-hide-result-toggle-maybe'. But, should it be the case? In particular, if I look at `org-babel-data-names', upon which `org-babel-result-regexp' is built, I'm not sure that name keyword should define a result line. As such, I would guess that it should be removed from that list. Regards, -- Nicolas Goaziou
[O] [babe] :var assignment no longer of tolerant of whitespace
Hi It used to be the case that you could assign a variable and any whitespace would be chomped: --8---cut here---start-8--- #+begin_src emacs-lisp :var a = 1 :var b = 2 (+ a b) #+end_src --8---cut here---end---8--- However it is now required to remove the whitespace: --8---cut here---start-8--- #+begin_src emacs-lisp :var a=1 :var b=2 (+ a b) #+end_src --8---cut here---end---8--- I haven't noticed any announcement of a change in terms of whitespace use, so I'm mentioning it in case it is actually a regression, or is it by design? If the change has been announced, then I apologize in advance for the noise. Best, Martyn
[O] [babel] :var assignment no longer tolerant of whitespace
Martyn Jago martyn.j...@btinternet.com writes: (Fixed typos in heading) Hi It used to be the case that you could assign a variable and any whitespace would be chomped: #+begin_src emacs-lisp :var a = 1 :var b = 2 (+ a b) #+end_src However it is now required to remove the whitespace: #+begin_src emacs-lisp :var a=1 :var b=2 (+ a b) #+end_src I haven't noticed any announcement of a change in terms of whitespace use, so I'm mentioning it in case it is actually a regression, or is it by design? If the change has been announced, then I apologize in advance for the noise. Best, Martyn
[O] [org-babel] [PATCH] Improve ditta.jar finding heuristics
Hi everybody,
I've been using org-mode for quite a while but only recently found
myself in need of using ditaa to draw some simple diagram. As it turns
out my installation of emacs(Ubuntu 10.10, emacs-snapshot from
https://launchpad.net/~cassou/+archive/emacs) doesn't come with
ditta.jar pre-bundled, although I'm not sure if it should. Anyway, despite
my installation of ditta with help of apt-get, org-babel kept
unsuccessfully trying to locate
/usr/share/emacs/24.0.91/lisp/contrib/ditta.jar, leaving me without any
diagrams produced.
So to alleviate the problem I cloned git repository and wrote a small
patch implementing very crude algorithm, which is, nonetheless, in my
opinion, still an improvement on default behavior. For more details see
commit message.
Andrey Smirnov
From 03b434347e02c2fc95f38a7a4e87850eb5f87f56 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov andrew.smir...@gmail.com
Date: Sun, 20 Nov 2011 19:40:32 +0700
Subject: [PATCH] org-babel: Add simple ditaa.jar searching heuristics
lisp/ob-ditaa.el: Add two functions `org-ditaa-try-find-file-in' and
`org-ditaa-delete-if-not' and more complicated algorithm for setting
the value of `org-ditaa-jar-path'.
Prior to this the algorithm used to locate ditaa.jar was to look for
it in ${ob-ditaa.el path}/../contrib/ but that approach fails if said 'jar'
doesn't come pre-bundled with user's emacs install and even if it does
it precludes user from using system-wide installed(via apt-get or any
such tool) instance of ditaa in favor of pre-bundled one.
New heuristics does the following:
1. Looks in the predefined set of locations, right now it is
- /usr/share/ditaa/ (Location where it is installed in
Ubuntu)
- ${ob-ditaa.el path}/../contrib/
2. If previous set yeilds no results it tryies to locate said
ditta.jar in either /usr/share/ or /usr/lib/
---
lisp/ob-ditaa.el | 72 +-
1 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
index 0aba9a6..15b3fbe 100644
--- a/lisp/ob-ditaa.el
+++ b/lisp/ob-ditaa.el
@@ -42,7 +42,77 @@
'((:results . file) (:exports . results) (:java . -Dfile.encoding=UTF-8))
Default arguments for evaluating a ditaa source block.)
-(defvar org-ditaa-jar-path)
+;;; Not having delete-if-not from cl package is rather annoying,
+;;; but, alright, we'll do it live.
+(defun org-ditaa-delete-if-not (pred seq)
+ Destructively remove all elements of SEQ that do not satisfy predicat PRED
+ (dolist (elt seq seq)
+(when (not (apply pred (list elt)))
+ (setq seq (delete elt seq)
+
+(defun org-ditaa-try-find-file-in (dir filename)
+ Traverse directory tree supplied in DIR and search for FILENAME.
+Return full path to FILENAME if found.
+ (let ((candidate-file (expand-file-name filename dir)))
+(cond ((file-exists-p candidate-file)
+ candidate-file)
+ ((file-directory-p dir)
+ (do ((path-to-file nil)
+ ;; List of sub-directories with . , .. and all
+ ;; items that are not directories filtered out
+ (subdir-list
+ (org-ditaa-delete-if-not
+ (lambda (e) (file-directory-p
+ (file-name-as-directory
+ (expand-file-name e dir
+ (delete
+ ..
+ (delete
+ .
+ ;; Access to some directories might result in
+ ;; Permission denied file error. Wrap the call
+ ;; in condition-case to avoid that
+ (condition-case ex
+ (directory-files dir)
+ ('file-error)
+ (setq subdir-list (cdr subdir-list
+ ((or (not subdir-list)
+ path-to-file) path-to-file)
+ (when subdir-list
+ (let ((subdir (file-name-as-directory
+ (expand-file-name (car subdir-list) dir
+ (setq path-to-file (when (and subdir
+ (file-directory-p subdir))
+ (org-ditaa-try-find-file-in subdir filename)))
+ (t
+ nil
+
+;;; When looking for ditaa.jar go through predefined list of most
+;;; likely places to have it, then if else fails try to find it
+;;; somwhere in /usr/share or /usr/lib
+(defvar org-ditaa-jar-path
+ (let* ((potential-path-list
+ (list /usr/share/ditaa/ditaa.jar ; Ubuntu 10.10 installed via apt-get
+ (expand-file-name; Bundled with emacs
+ ditaa.jar
+ (file-name-as-directory
+ (expand-file-name
+ scripts
+ (file-name-as-directory
+ (expand-file-name
+ ../contrib
+ (file-name-directory (or load-file-name
+ buffer-file-name)
+ (actual-path (car potential-path-list)))
+(while (and actual-path
+ (not (file-exists-p actual-path)))
+ (setq potential-path-list (cdr potential-path-list))
+ (setq actual-path (car potential-path-list)))
+(when (not actual-path)
+ (setq actual-path (or (org-ditaa-try-find-file-in /usr/share ditaa.jar)
+ (org-ditaa-try-find-file-in /usr/lib ditaa.jar
+actual-path))
+
(defun org-babel-execute:ditaa (body params)
Execute a
Re: [O] [OT] Scanning for archiving
TP wing...@gmail.com writes: Apparently the S1500's are supported on Linux via Sane (http://www.sane-project.org/sane-backends.html#S-FUJITSU). Don't see any mention of the S1300 (but it probably also works?). I can confirm that the S1300 works well with Linux. Best, Matt
Re: [O] Getting rid of split frame with org-capture
On Sun, 13 Nov 2011 12:57:21 -0500, Nick Dokos nicholas.do...@hp.com wrote: 1) If I don't pass -c to emacsclient, then I need to search all my workspaces to find where emacs decided to put the capture frame 2) If I pass do pass -c to emacsclient, then I need to close the frame afterwards. And more significantly, I need to close the empty frame when I use store-link instead. (I could work around this by using seperate protocols for for each) Sounds like a worthwhile thing to fix - patches would probably be welcome. I came up with the following hack, which seems to do what I want: (defadvice org-protocol-check-filename-for-protocol (around tp/org-protocol-make-frame activate) Advice org-protocol-check-filename-for-protocol to open windows in new frames. (flet ((org-switch-to-buffer-other-window (rest args) ; for org-mks (let ((pop-up-frames t)) (apply 'switch-to-buffer-other-window args))) (org-pop-to-buffer-same-window (rest args) ; for org-capture (let ((pop-up-frames t)) (apply 'switch-to-buffer-other-window args (let ((display-buffer-mark-dedicated t)) ad-do-it)))
Re: [O] [babel] :var assignment no longer tolerant of whitespace
Hi Martyn, Tom mentioned this regression earlier and I treated it as a new restriction on variable specifications, but if multiple people are running into this issue I suppose spaces around equals should be supported. I have just pushed up a change and a test case ensuring that examples like yours below will work. Cheers -- Eric Martyn Jago martyn.j...@btinternet.com writes: Martyn Jago martyn.j...@btinternet.com writes: (Fixed typos in heading) Hi It used to be the case that you could assign a variable and any whitespace would be chomped: #+begin_src emacs-lisp :var a = 1 :var b = 2 (+ a b) #+end_src However it is now required to remove the whitespace: #+begin_src emacs-lisp :var a=1 :var b=2 (+ a b) #+end_src I haven't noticed any announcement of a change in terms of whitespace use, so I'm mentioning it in case it is actually a regression, or is it by design? If the change has been announced, then I apologize in advance for the noise. Best, Martyn -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [org-babel] [PATCH] Improve ditta.jar finding heuristics
Hi Andrey,
The variable `org-ditaa-jar-path' can be used to specify a non-standard
location for the ditaa jar file. Org-mode has *many* customization
variables, and for most problems a variable will exist to solve the
problem, the `apropos' command can be very useful for finding these
variables.
Best -- Eric
ps. I agree that it is annoying that Emacs does not allow the cl
functions to be used by core packages.
Andrey Smirnov andrew.smir...@gmail.com writes:
Hi everybody,
I've been using org-mode for quite a while but only recently found
myself in need of using ditaa to draw some simple diagram. As it turns
out my installation of emacs(Ubuntu 10.10, emacs-snapshot from
https://launchpad.net/~cassou/+archive/emacs) doesn't come with
ditta.jar pre-bundled, although I'm not sure if it should. Anyway, despite
my installation of ditta with help of apt-get, org-babel kept
unsuccessfully trying to locate
/usr/share/emacs/24.0.91/lisp/contrib/ditta.jar, leaving me without any
diagrams produced.
So to alleviate the problem I cloned git repository and wrote a small
patch implementing very crude algorithm, which is, nonetheless, in my
opinion, still an improvement on default behavior. For more details see
commit message.
Andrey Smirnov
From 03b434347e02c2fc95f38a7a4e87850eb5f87f56 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov andrew.smir...@gmail.com
Date: Sun, 20 Nov 2011 19:40:32 +0700
Subject: [PATCH] org-babel: Add simple ditaa.jar searching heuristics
lisp/ob-ditaa.el: Add two functions `org-ditaa-try-find-file-in' and
`org-ditaa-delete-if-not' and more complicated algorithm for setting
the value of `org-ditaa-jar-path'.
Prior to this the algorithm used to locate ditaa.jar was to look for
it in ${ob-ditaa.el path}/../contrib/ but that approach fails if said 'jar'
doesn't come pre-bundled with user's emacs install and even if it does
it precludes user from using system-wide installed(via apt-get or any
such tool) instance of ditaa in favor of pre-bundled one.
New heuristics does the following:
1. Looks in the predefined set of locations, right now it is
- /usr/share/ditaa/ (Location where it is installed in
Ubuntu)
- ${ob-ditaa.el path}/../contrib/
2. If previous set yeilds no results it tryies to locate said
ditta.jar in either /usr/share/ or /usr/lib/
---
lisp/ob-ditaa.el | 72
+-
1 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
index 0aba9a6..15b3fbe 100644
--- a/lisp/ob-ditaa.el
+++ b/lisp/ob-ditaa.el
@@ -42,7 +42,77 @@
'((:results . file) (:exports . results) (:java .
-Dfile.encoding=UTF-8))
Default arguments for evaluating a ditaa source block.)
-(defvar org-ditaa-jar-path)
+;;; Not having delete-if-not from cl package is rather annoying,
+;;; but, alright, we'll do it live.
+(defun org-ditaa-delete-if-not (pred seq)
+ Destructively remove all elements of SEQ that do not satisfy predicat
PRED
+ (dolist (elt seq seq)
+(when (not (apply pred (list elt)))
+ (setq seq (delete elt seq)
+
+(defun org-ditaa-try-find-file-in (dir filename)
+ Traverse directory tree supplied in DIR and search for FILENAME.
+Return full path to FILENAME if found.
+ (let ((candidate-file (expand-file-name filename dir)))
+(cond ((file-exists-p candidate-file)
+candidate-file)
+ ((file-directory-p dir)
+(do ((path-to-file nil)
+ ;; List of sub-directories with . , .. and all
+ ;; items that are not directories filtered out
+ (subdir-list
+ (org-ditaa-delete-if-not
+ (lambda (e) (file-directory-p
+ (file-name-as-directory
+(expand-file-name e dir
+ (delete
+..
+(delete
+ .
+ ;; Access to some directories might result in
+ ;; Permission denied file error. Wrap the call
+ ;; in condition-case to avoid that
+ (condition-case ex
+ (directory-files dir)
+ ('file-error)
+ (setq subdir-list (cdr subdir-list
+((or (not subdir-list)
+ path-to-file) path-to-file)
+ (when subdir-list
+(let ((subdir (file-name-as-directory
+ (expand-file-name (car subdir-list) dir
+ (setq path-to-file (when (and subdir
+(file-directory-p subdir))
+ (org-ditaa-try-find-file-in subdir
filename)))
+ (t
+nil
+
+;;; When looking for ditaa.jar go through predefined list of most
+;;; likely places to have it, then if else fails try to find it
+;;; somwhere in
Re: [O] [BUG] Inconsistency in src block hiding
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, In the following example (latest Org), with point at |, when TAB is pressed, block gets hidden at the name level. |#+name: test #+begin_src emacs-lisp test #+end_src It is because `org-babel-result-regexp' is matched in `org-babel-hide-result-toggle-maybe'. But, should it be the case? In particular, if I look at `org-babel-data-names', upon which `org-babel-result-regexp' is built, I'm not sure that name keyword should define a result line. As such, I would guess that it should be removed from that list. Hi Nicolas, name is and should be an element of the `org-babel-data-names' list as it is the preferred way to name data in an Org-mode file, e.g., #+name: foo - 1 - 2 - 3 The only reason that tblname and results are included in the list are because tblname is used by other parts of Org-mode, and results was retained because it was felt that a name line without an actual name (e.g., as the results of an un-named code block) would look funny. I don't view the results style hiding as inconsistent, however if others do, it wouldn't be difficult to insert a check for a special case in the code that hides results to inhibit the behavior if the data following name happens to be a code block. Best -- Eric Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [BUG] Inconsistency in src block hiding
Eric Schulte schulte.e...@gmail.com writes: name is and should be an element of the `org-babel-data-names' list as it is the preferred way to name data in an Org-mode file, e.g., #+name: foo - 1 - 2 - 3 I agree. The only reason that tblname and results are included in the list are because tblname is used by other parts of Org-mode, and results was retained because it was felt that a name line without an actual name (e.g., as the results of an un-named code block) would look funny. I don't view the results style hiding as inconsistent It is inconsistent when keywords stack on top of each other. If you have only a #+name: keyword, block with fold at the #+name: level. If you have both #+name: and, for example #+results below, block will fold at the #+result: level and TAB will not respond at #+name:. If you have, from top to bottom, name, results header, nothing will fold. In all those cases, I think a consistent behaviour could be to hide the block, with any number of keywords above, and TAB pressed at any of them. I'm not sure that #+results: or #+name: keywords should allow to hide whole parts of the buffer. I realize that toggling #+results: visibility has been in core for a while. But now that every Org blob can have a #+name attached to it, one can hide almost anything in the buffer. Until now we could hide contents with headlines, blocks, drawers, and items (with an option to prevent it). And we had a global mechanism to handle visibility toggling just fine (namely S-TAB with different numbers of prefixes). But hiding independently each list, table or paragraph with no possibility to make them appear in groups just doesn't sound right. Hence, I suggest to think again about it: we can live happily with outlines, blocks and drawers as folding entities. Moreover, there is another problem related to that. `org-export-blocks-preprocess' will remove all #+name: keywords in the buffer. It mustn't: again #+name: is a general naming mechanism for almost any Org syntax. It may/will be also used for other purpose than Babel. That information is important even after blocks have been processed. Regards, -- Nicolas Goaziou
Re: [O] [org-babel] [PATCH] Improve ditta.jar finding heuristics
Eric Schulte schulte.e...@gmail.com writes: Hi Andrey, The variable `org-ditaa-jar-path' can be used to specify a non-standard location for the ditaa jar file. True, but my patch is not about doing away with `org-ditaa-jar-path' variable, it is about broadening the definition of standard location so to speak. Right now, being defined relatively to ob-ditaa.el, aforementioned standard location is at the mercy of what/whoever that is responsible for deciding where all the stuff belonging to emacs and org-mode goes. IMHO, that floating filesystem location is hardly more standard than the place where Distro X's package management tools place ditta.jar after installation. Org-mode has *many* customization variables, and for most problems a variable will exist to solve the problem, I understand where you're coming from. True, it is not possible to handle all obscure and arcane cases, that's what all these variables are for, but I don't think that a situation where user installs ditaa and later emacs, both via the package management system and find themselves unable to draw awesome ditaa diagrams without looking a variable up in documentation, adding appropriate code to his configuration file and hitting C-x C-e is some sort of a fringe use-case. If only myself and maybe another person has ever hit that roadblock, than I agree, it is not worth adding any additional code, and I rest my case. the `apropos' command can be very useful for finding these variables. Thanks for the tip, didn't know about that particular command. I usually use combination of C-h v and good old M-x download-the-source-and-look-how-the-thing-works :-). Andrey Smirnov
[O] [beamer] Can I just export one frame?
It takes long to export the whole file when it contains many babel stuff. And in many cases, I just want to check if the current frame is arranged as expected. SO I just want to know if there is some convenient way to export just one frame without tagging all the other frames as :noexport.
