Re: [O] Web site bug
Bastien writes: No, (require 'org-loaddefs) is never needed IMHO. It is if you are using Org from Git and you only want the autoload definitions pulled in on startup and not the whole of Org plus most of its dependencies. This is what a (require 'org-install) did before the change to org-loaddefs.el. You can't rely on some older Org version in Emacs or whereever to supply the correct autoload definitions, so you eitehr need to (require 'org-loaddefs) which is horribly wrong in case you're not sing Org from Git; or (require 'org) which is pulling in too much stuff on startup. Org from Git is currently missing the first-level autoloads file that was implicitly introduced for all other use-cases with that change (loaddefs.el for vanilla Emacs and org-autoloads.el for package manager). I propose to re-introduce org-install.el for this purpose for standalone Org. From 6b2d3f7689078f836cf1dbd8ee508131e8b22ef5 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Sun, 28 Oct 2012 08:23:22 +0100 Subject: [PATCH] Re-introduce org-install.el * lisp/org-install.el: Delete from version control, is autogenerated again. An empty file should be provided in Emacs and for ELPA as before. * mk/org-fixup.el (org-make-org-loaddefs): Arrange for org-install to collect the first-level autoload definitions for standalone Org (like loaddefs.el for Emacs and org-autoloads.el for package manager). The autoloads in org-loaddefs.el will be identical second-level for all installations. The first-level autoload definitions are automatically loaded by EMacs or package manager, respectively. For standalone Org, the user has to (require 'org-install), as has been customary. FIXME: this implementation does not support XEmacs. --- lisp/org-install.el | 13 - mk/org-fixup.el | 15 --- 2 files changed, 4 insertions(+), 24 deletions(-) delete mode 100644 lisp/org-install.el diff --git a/lisp/org-install.el b/lisp/org-install.el deleted file mode 100644 index a31d8b7..000 --- a/lisp/org-install.el +++ /dev/null @@ -1,13 +0,0 @@ -;;; org-install.el --- autogenerated file, do not edit -;; -;;; Code: -(warn The file org-install is obsolete. -Please change your configuration to (require 'org) instead.) - -(provide 'org-install) - -;; Local Variables: -;; no-byte-compile: t -;; coding: utf-8 -;; End: -;;; org-install.el ends here diff --git a/mk/org-fixup.el b/mk/org-fixup.el index 7b59efb..e5dee9a 100644 --- a/mk/org-fixup.el +++ b/mk/org-fixup.el @@ -67,17 +67,10 @@ (defun org-make-org-loaddefs () be used by foreign build systems or installers to produce this file in the installation directory of org-mode. Org will not work correctly if this file is not up-to-date. - (with-temp-buffer -(set-visited-file-name org-loaddefs.el) -(insert ;;; org-loaddefs.el --- autogenerated file, do not edit\n;;\n;;; Code:\n) -(let ((files (directory-files default-directory nil ^\\(org\\|ob\\)\\(-.*\\)?\\.el$))) - (mapc (lambda (f) (generate-file-autoloads f)) files)) -(insert \f\n(provide 'org-loaddefs)\n) -(insert \f\n;; Local Variables:\n;; version-control: never\n) -(insert ;; no-byte-compile: t\n;; no-update-autoloads: t\n) -(insert ;; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n) -(toggle-read-only 0) -(save-buffer))) + (write-region (autoload-rubric org-install.el nil org-install) nil org-install.el) + (write-region (autoload-rubric org-loaddefs.el nil org-loaddefs) nil org-install.el) + (let ((generated-autoload-file (expand-file-name org-install.el default-directory))) +(update-directory-autoloads (file-name-directory generated-autoload-file (defun org-make-autoloads (optional compile force) Make the files org-loaddefs.el and org-version.el in the install directory. -- 1.8.0 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] Contradiction between code and doc as regards commented lines
Rafael Laboissiere raf...@laboissiere.net writes: You might be interested in applying the patch attached below, which fixes the comments in the *Remember* buffer, allowing them to get correctly fontified. Applied, thanks! -- Bastien
Re: [O] Patch: org-agenda-skip-deadline-prewarning-if-scheduled prior to scheduled date
Hello, justus-b...@piater.name writes: My current solution (see the patch) involves some minor refactoring at the price of an extra (if ds ...) that I don't see a way to get rid of, but I find the result quite readable. It looks good. I would have integrated the (if ds ...) within the cond (i.e (cond ((not ds) nil) ...)) but it doesn't matter much. I signed the FSF GNU EMACS copyright assignment form a few years ago. Do I need to do something else for org-mode? No, it should be fine. I've applied your patch. Thank you for your contribution. Regards, -- Nicolas Goaziou
Re: [O] Web site bug
Hi Achim, Achim Gratz strom...@nexgo.de writes: It is if you are using Org from Git and you only want the autoload definitions pulled in on startup and not the whole of Org plus most of its dependencies. This is what a (require 'org-install) did before the change to org-loaddefs.el. You can't rely on some older Org version in Emacs or whereever to supply the correct autoload definitions, so you eitehr need to (require 'org-loaddefs) which is horribly wrong in case you're not using Org from Git; You mean in case users install Org from a tar/zip archive that does not contain org-loaddefs.el? For now the tar/zip archives does not contain org-loaddefs.el but it will starting from Org 7.9.3. (require 'org-loaddefs) is wrong in case users who cloned Org from Git forget to make or make autoloads. It is just as wrong as (require 'org-install) was previously. No? or (require 'org) which is pulling in too much stuff on startup. Org from Git is currently missing the first-level autoloads file that was implicitly introduced for all other use-cases with that change (loaddefs.el for vanilla Emacs and org-autoloads.el for package manager). You mean Org from Git is missing the org-loaddefs.el that is produced by make or make autoloads? Yes, I don't think this is a problem. I propose to re-introduce org-install.el for this purpose for standalone Org. I don't really understand what this is supposed to fix... ? From 6b2d3f7689078f836cf1dbd8ee508131e8b22ef5 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Sun, 28 Oct 2012 08:23:22 +0100 Subject: [PATCH] Re-introduce org-install.el * lisp/org-install.el: Delete from version control, is autogenerated again. An empty file should be provided in Emacs and for ELPA as before. * mk/org-fixup.el (org-make-org-loaddefs): Arrange for org-install to collect the first-level autoload definitions for standalone Org (like loaddefs.el for Emacs and org-autoloads.el for package manager). The autoloads in org-loaddefs.el will be identical second-level for all installations. The first-level autoload definitions are automatically loaded by EMacs or package manager, respectively. For standalone Org, the user has to (require 'org-install), as has been customary. FIXME: this implementation does not support XEmacs. --- lisp/org-install.el | 13 - mk/org-fixup.el | 15 --- 2 files changed, 4 insertions(+), 24 deletions(-) delete mode 100644 lisp/org-install.el diff --git a/lisp/org-install.el b/lisp/org-install.el deleted file mode 100644 index a31d8b7..000 --- a/lisp/org-install.el +++ /dev/null @@ -1,13 +0,0 @@ -;;; org-install.el --- autogenerated file, do not edit -;; -;;; Code: -(warn The file org-install is obsolete. -Please change your configuration to (require 'org) instead.) - -(provide 'org-install) - -;; Local Variables: -;; no-byte-compile: t -;; coding: utf-8 -;; End: -;;; org-install.el ends here diff --git a/mk/org-fixup.el b/mk/org-fixup.el index 7b59efb..e5dee9a 100644 --- a/mk/org-fixup.el +++ b/mk/org-fixup.el @@ -67,17 +67,10 @@ (defun org-make-org-loaddefs () be used by foreign build systems or installers to produce this file in the installation directory of org-mode. Org will not work correctly if this file is not up-to-date. - (with-temp-buffer -(set-visited-file-name org-loaddefs.el) -(insert ;;; org-loaddefs.el --- autogenerated file, do not edit\n;;\n;;; Code:\n) -(let ((files (directory-files default-directory nil ^\\(org\\|ob\\)\\(-.*\\)?\\.el$))) - (mapc (lambda (f) (generate-file-autoloads f)) files)) -(insert \f\n(provide 'org-loaddefs)\n) -(insert \f\n;; Local Variables:\n;; version-control: never\n) -(insert ;; no-byte-compile: t\n;; no-update-autoloads: t\n) -(insert ;; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n) -(toggle-read-only 0) -(save-buffer))) + (write-region (autoload-rubric org-install.el nil org-install) nil org-install.el) + (write-region (autoload-rubric org-loaddefs.el nil org-loaddefs) nil org-install.el) ^^^ I don't know what autoload-rubric is. Hint? Thanks, -- Bastien
[O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hello, with an up to date org, I cannot get the attached minimal example to export using the new exporter. I have try exporting to latex-pdf, in case that matters. The (line-length truncated) error trace is: --8---cut here---start-8--- Debugger entered--Lisp error: (wrong-type-argument stringp nil) file-readable-p(nil) (not (file-readable-p file)) (cond ((not (file-readable-p file)) (error Cannot include file %s file)) (let* ((value (match-string 1)) (ind (org-get-indentation)) (file (and (st (progn (beginning-of-line) (let* ((value (match-string 1)) (ind (org-get-i (if (eq (org-element-type (save-match-data (org-element-at-point))) (quote (when (eq (org-element-type (save-match-data (org-element-at-point))) (quo (while (re-search-forward ^[ ]*#\\+INCLUDE: \\(.*\\) nil t) (whe (let ((case-fold-search t)) (goto-char (point-min)) (while (re-search-forw org-export-expand-include-keyword() [...] --8---cut here---end---8--- Note that the uml.org file referred to by the #+include exists. Also note that the old exporter works. I am not entirely sure what the semantics for included files in the new exporter are. For instance, is an include statement /within/ a non-exported headline meant to be processed? Regardless, the fact that it fails to export is a bug, I guess. Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.1.1 and Org release_7.9.2-516-g796fca # -*- org-confirm-babel-evaluate: nil; -*- #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga #+EMAIL: e.fr...@ucl.ac.uk #+DATE: 2012-01-09 Mon #+EXPORT_EXCLUDE_TAGS: noexport * introduction This is some text that should be exported * conclusions :noexport: This is some text that will not be exported. It includes some text from another file. The presence of this include causes the new exporter to fail. #+include: uml.org
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hi Eric, You have: #+include: uml.org I think it should be: #+include: uml.org I have haven't tried it though. Myles Eric S Fraga writes: Hello, with an up to date org, I cannot get the attached minimal example to export using the new exporter. I have try exporting to latex-pdf, in case that matters. The (line-length truncated) error trace is: --8---cut here---start-8--- Debugger entered--Lisp error: (wrong-type-argument stringp nil) file-readable-p(nil) (not (file-readable-p file)) (cond ((not (file-readable-p file)) (error Cannot include file %s file)) (let* ((value (match-string 1)) (ind (org-get-indentation)) (file (and (st (progn (beginning-of-line) (let* ((value (match-string 1)) (ind (org-get-i (if (eq (org-element-type (save-match-data (org-element-at-point))) (quote (when (eq (org-element-type (save-match-data (org-element-at-point))) (quo (while (re-search-forward ^[ ]*#\\+INCLUDE: \\(.*\\) nil t) (whe (let ((case-fold-search t)) (goto-char (point-min)) (while (re-search-forw org-export-expand-include-keyword() [...] --8---cut here---end---8--- Note that the uml.org file referred to by the #+include exists. Also note that the old exporter works. I am not entirely sure what the semantics for included files in the new exporter are. For instance, is an include statement /within/ a non-exported headline meant to be processed? Regardless, the fact that it fails to export is a bug, I guess. Thanks, eric
[O] Filter weekly/daily agenda by tag
Hello, this is my first post on the mailing list and i am not quite sure if i do everything right. If i screw something up, please let me know, so i can fix it and do it right next time. To the problem I'm facing: My setup: I have a single org file with appointments as sub trees. Each appointment has an active timestamp assigned to it, so it appears in the weekly agenda view. It also has one or more tags assigned to it. The agenda view i want to create: I would like to have a weekly agenda view filtered by the tags assigned to the events. Now, i searched the org-mode list archives and found this post: http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00812.html where Bernt Hansen writes You should be able to achieve this by setting the variable org-agenda-filter.. Where does this variable org-agenda-filter come from? If i want to describe it in emacs, i cannot find it. So i think this is a setting which can be passed to commands in org-agenda-custom-commands. (btw: is there a place where all the settings i can pass to these commands is documented?) I created my own agenda-command in my .emacs, but it did not filter the weekly agenda view as described above. This is my code: (setq org-agenda-custom-commands '((d Test Tag Filter ((agenda ((org-agenda-files '(~/org/WeeklyFilterTest.org)) (org-agenda-filter -EXCL))) And this is my ~/org/WeeklyFilterTest.org: * Events :PROPERTIES: :CATEGORY: Event :END: ** Event1 :INCL: 2012-10-29 Mon ** Event2 :INCL: 2012-10-30 Tue ** Event3 :EXCL: 2012-10-30 Tue 18:00 ** Event4 :INCL: 2012-10-30 Tue 19:00 To explain what i want to achieve regarding this example: I want a weekly agenda view only displaying Event1, Event2 and Event4 but not Event3 as it should be excluded by its tag. Any help is appreciated. Regards Alexander
Re: [O] Patch: org-agenda-skip-deadline-prewarning-if-scheduled prior to scheduled date
Nicolas Goaziou n.goaz...@gmail.com wrote on Sun, 28 Oct 2012 11:20:15 +0100: I would have integrated the (if ds ...) within the cond (i.e (cond ((not ds) nil) ...)) Oh yes! Please do :-) Justus
Re: [O] Filter weekly/daily agenda by tag
Hi Alexander, Alexander Baier lexi.ba...@gmail.com writes: (setq org-agenda-custom-commands '((d Test Tag Filter ((agenda ((org-agenda-files '(~/org/WeeklyFilterTest.org)) (org-agenda-filter -EXCL))) You need to locally bind `org-agenda-tag-filter-preset' to a list of tags like '(-EXCL). I did not test, but this should be okay: (setq org-agenda-custom-commands '((d Test Tag Filter ((agenda ((org-agenda-files '(~/org/WeeklyFilterTest.org)) (org-agenda-tag-filter-preset '(-EXCL PS: You're right that org-agenda-filter does not exist. -- Bastien
Re: [O] Filter weekly/daily agenda by tag
On 10/28/2012 12:58 PM, Alexander Baier wrote: To explain what i want to achieve regarding this example: I want a weekly agenda view only displaying Event1, Event2 and Event4 but not Event3 as it should be excluded by its tag. Any help is appreciated. FWIW, my agenda is constructed like this: (w work week agenda agenda ((org-agenda-span 'week) (org-agenda-start-on-weekday 1) ;; work - begin on monday (org-agenda-tag-filter-preset '(+@work)) ;; no OR (phd | @work) possible here! (org-agenda-hide-tags-regexp @work) (org-agenda-compact-blocks t) )) Using the tag-filter-preset allows to change the tags inside the agenda view because it filters the view, not the construction of the agenda. Excluding might work like this: (org-agenda-tag-filter-preset '(+like -dislike)) but I haven't tested this combination. I'm also hiding the @work tag as the other tags (if any) are more relevant then. HTH, Simon Regards Alexander
Re: [O] [ANN] Editable HTML export of Org-mode files
Simon Thum simon.t...@gmx.de writes: On 10/22/2012 10:38 PM, Eric Schulte wrote: Simon Thumsimon.t...@gmx.de writes: --8---cut here---start-8--- foo bar --8---cut here---end---8--- all of the spaces and newlines are inserted into the Org-mode file. However, when that Org-mode file is re-exported, it uses the normal html exporter (which *does* ignore whitespace by default). So, if you are not having the spaces inserted into your Org-mode file that is a problem with org-ehtml, but if you *are* having the spaces appear in your .org file (server-side), but they are not appearing in the exported HTML, that is expected behavior. I meant when editing in the HTML page via the server call-back. Changing the WS means all lines change, regardless of whether I edited them. From your description I assume the edit box content comes out of the export, too? I guess that needs to change for this to work reliably. Yes, the content of the edit boxes does come from the exported html. For each portion of the Org-mode document (as delimited by org-elements), both the raw Org-mode text and the HTML are exported side-by-side, then the raw Org-mode text is hidden and the HTML is displayed, until the [edit] button is pushed at which point JavaScript is used to hide the HTML and to expose the raw Org-mode text in an edit box. When edits are committed they are committed one portion (edit-box) at a time. Does this make sense? Why would something need to change for this to be reliable? Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Filter weekly/daily agenda by tag
2012/10/28 Bastien b...@altern.org: Hi Alexander, Alexander Baier lexi.ba...@gmail.com writes: (setq org-agenda-custom-commands '((d Test Tag Filter ((agenda ((org-agenda-files '(~/org/WeeklyFilterTest.org)) (org-agenda-filter -EXCL))) You need to locally bind `org-agenda-tag-filter-preset' to a list of tags like '(-EXCL). I did not test, but this should be okay: (setq org-agenda-custom-commands '((d Test Tag Filter ((agenda ((org-agenda-files '(~/org/WeeklyFilterTest.org)) (org-agenda-tag-filter-preset '(-EXCL PS: You're right that org-agenda-filter does not exist. -- Bastien This works as wanted it to, thank you! Another question: Do you know if there is any documentation on the settings i can pass to the commands in org-agenda-custom-commands? Regards Alexander
Re: [O] [new exporter] two unexpected behaviours of an #+INCLUDEd #+call
Hello, Myles English mylesengl...@gmail.com writes: Given the situation below, I would expect that the block named xxx would never be evaluated: #- file b.org --- #+TITLE: b.org #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport * A heading :noexport: #+INCLUDE: c.org #- file c.org --- * A Heading in c.org #+name: xxx #+BEGIN_SRC sh echo Evaluated c.out #+END_SRC #+call: xxx() # :noexport: doesn't mean Babel blocks within shouldn't be evaluated. It just means contents will eventually be ignored. And maybe it isn't evaluated but the call is still processed to some extent upon latex export: #+BEGIN_SRC sh :shebang #!/usr/bin/env bash :tangle eval_bug.sh emacs -Q --batch --eval (progn (add-to-list 'load-path (expand-file-name \./lisp/\)) (add-to-list 'load-path (expand-file-name \./contrib/lisp/\ t)) (require 'org-e-latex) (org-babel-do-load-languages 'org-babel-load-languages '((sh . t))) (find-file \b.org\) (org-e-latex-export-to-latex)) #+END_SRC $ ./eval_bug.sh Loading /home/myles/.emacs.d/plugins/org-mode/lisp/org-loaddefs.el (source)... OVERVIEW Loading vc-git... OVERVIEW OVERVIEW Reference 'xxx' not found in this buffer Removing the :noexport: results in the same message as above, removing the #+call causes c.org to be included but even adding these line to the batch function above will not cause the block to be evaluated (i.e. there is no c.out written): This should be fixed in master. Thank you for the report. Regards, -- Nicolas Goaziou
Re: [O] [ANN] Editable HTML export of Org-mode files
On 10/28/2012 04:19 PM, Eric Schulte wrote: Yes, the content of the edit boxes does come from the exported html. For each portion of the Org-mode document (as delimited by org-elements), both the raw Org-mode text and the HTML are exported side-by-side, then the raw Org-mode text is hidden and the HTML is displayed, until the [edit] button is pushed at which point JavaScript is used to hide the HTML and to expose the raw Org-mode text in an edit box. When edits are committed they are committed one portion (edit-box) at a time. Does this make sense? Why would something need to change for this to be reliable? No, that sounds correct in principle. But my whitespace got eaten nonetheless ;( I'll be investigating further. Cheers, Simon
Re: [O] Filter weekly/daily agenda by tag
2012/10/28 Simon Thum simon.t...@gmx.de: On 10/28/2012 12:58 PM, Alexander Baier wrote: To explain what i want to achieve regarding this example: I want a weekly agenda view only displaying Event1, Event2 and Event4 but not Event3 as it should be excluded by its tag. Any help is appreciated. FWIW, my agenda is constructed like this: (w work week agenda agenda ((org-agenda-span 'week) (org-agenda-start-on-weekday 1) ;; work - begin on monday (org-agenda-tag-filter-preset '(+@work)) ;; no OR (phd | @work) possible here! (org-agenda-hide-tags-regexp @work) (org-agenda-compact-blocks t) )) Do you know if there is another filter/setting that allows for more complex filtering? (like the OR expression you pointed out) Using the tag-filter-preset allows to change the tags inside the agenda view because it filters the view, not the construction of the agenda. Excluding might work like this: (org-agenda-tag-filter-preset '(+like -dislike)) This works like i wanted, thanks! Regards Alexander
Re: [O] New exporter: no custom timestamps
Nicolas Goaziou n.goaz...@gmail.com writes: I tend to think that :raw-value would be a good option. Timestamps properties could be enriched. Besides common properties (:begin, :end, :post-blank) timestamps objects may accept : - :type - :year-start - :year-end - :month-start - :month-end - :day-start - :day-end - :hour-start - :hour-end - :minute-start - :minute-end - :repeater-type (a symbol among: `cumulative', 'catch-up', 'restart' corresponding to, respectively +, ++ .+ repeater marks) - :repeater-value - :raw-value :*-end properties would be the same as :*-start properties when timestamp isn't a range. Both would be nil (along with :repeater-*) when type is `diary'. By default back-ends would use :raw-value and `org-translate-time'. :range-end property would be removed. Done. I've also added :repeater-unit for good measure. Regards,
[O] [patch] fix bug introduced in commit aba9e2b9
This commit broke editing any source section with blank lines. Patch included. -- Le org-src.el.diff Description: Binary data
Re: [O] Web site bug
Bastien writes: You mean in case users install Org from a tar/zip archive that does not contain org-loaddefs.el? For now the tar/zip archives does not contain org-loaddefs.el but it will starting from Org 7.9.3. (require 'org-loaddefs) is wrong in case users who cloned Org from Git forget to make or make autoloads. It is just as wrong as (require 'org-install) was previously. No? No, (require 'org-loaddefs) is wrong, plain and simple. Except of course when you want to just get the autoloads for an Org from Git installation, since then _all_ autoloads for Org are in this file. You mean Org from Git is missing the org-loaddefs.el that is produced by make or make autoloads? No, it has _all_ autoloads in the same file, all other installations split the autoloads between two files (and automatically load the first and you never need to take care about the second). Yes, I don't think this is a problem. But it is a problem. I don't really understand what this is supposed to fix... ? It splits the autoload definitions into two files like all other installations. Almost everybody can then safely forget about org-loaddefs (since it is taken care of in org itself) and only needs to load org-install for Org from Git. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Contradiction between code and doc as regards commented lines
* Bastien b...@altern.org [2012-10-28 11:10]: Rafael Laboissiere raf...@laboissiere.net writes: You might be interested in applying the patch attached below, which fixes the comments in the *Remember* buffer, allowing them to get correctly fontified. Applied, thanks! Thanks. I just noticed that my patch have a bad side effect, since the commented lines at the beginning of the *Remember* buffer are not filtered out before inclusion into the destination org file. The patch attached below fixes this. Also, the org-remember-handler function attempts to strip comment lines at the end of the buffer. I changed the code such that only lines that really respect the definition of comment lines (as per the documentation) are actually stripped. Rafael From 72ad3f6f97a87da5b5dfd0df03ca2aed147a61af Mon Sep 17 00:00:00 2001 From: Rafael Laboissiere raf...@laboissiere.net Date: Sun, 28 Oct 2012 17:38:19 +0100 Subject: [PATCH 2/2] org-remember.el: Correctly strip the comment lines in remember buffer * org-remember.el (org-remember-handler): Correctly strip the comment lines in the temporary buffer *Remember* when handling a remember note. --- lisp/org-remember.el |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-remember.el b/lisp/org-remember.el index bfbca73..5cfe70f 100644 --- a/lisp/org-remember.el +++ b/lisp/org-remember.el @@ -840,12 +840,12 @@ See also the variable `org-reverse-note-order'. (if (= end beg) (setq beg (1- beg))) (put-text-property beg end 'org-position-cursor t))) (goto-char (point-min)) - (while (looking-at ^[ \t]*\n\\|^##.*\n) + (while (looking-at ^[ \t]*\n\\|^# .*\n) (replace-match )) (when org-remember-delete-empty-lines-at-end (goto-char (point-max)) (beginning-of-line 1) -(while (and (looking-at [ \t]*$\\|##.*) ( (point) 1)) +(while (and (looking-at [ \t]*$\\|[ \t]*# .*) ( (point) 1)) (delete-region (1- (point)) (point-max)) (beginning-of-line 1))) (catch 'quit -- 1.7.10.4
Re: [O] Running babel blocks in :noexport: sections
On Sat, Oct 27, 2012 at 5:57 PM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: For papers and beamer presentations, I sometimes hide more universal babel blocks inside a sort of setup headline. I thought I'd done this before, but perhaps not... The idea would be like so: * Data setup :noexport: #+begin_src R :session r load libraries read data files do universal operations #+end_src * Slide #+begin_src R :session r :exports results :results output graphics subset(larger_data_set_from_above) processing plot something #+end_src I noticed today that my :noexport: setup sections (I had a couple) were not updating. I re-defined a variable name further down in my file and it was re-using the definition from an above setup section (tagged with :noexport:). Just because I don't want it export doesn't mean I don't want to have useful stuff in the headline... Is this a bug/inappropriate setting, desirable based on how others use :noexport: headlines, or would others see value in executing babel blocks in :noexport: headlines? If I /didn't/ want it executed, I'd use :execute no. Thanks for any input, John Instead of tagging the headline as :noexport: you can add the COMMENT flag to it. This should result in your desired behavior. See the attached example. Brilliant. That'll do just fine. Never knew about that! John -- Eric Schulte http://cs.unm.edu/~eschulte
[O] Tangling to Multiple Files
Hi, how does one tangle a single code block to multiple files? I thought the following might work, but unfortunately it does not. Set the frame size. #+HEADERS: :tangle user-host-a.el user-host-b.el #+BEGIN_SRC emacs-lisp (setq initial-frame-alist '((width . 80) (height . 38))) #+END_SRC To provide some background, I'm using =org-babel-load-file= in my init.el file to load up my Emacs configuration from an Org file—call it user.org. I'd like to use just one user.org file across multiple computers, however, meaning I'd like user.org to tangle into user-host-a.el and user-host-b.el, for instance. The configurations are only slightly different, so I'd like to be able to selectively indicate to Org-mode which code blocks to tangle into.
Re: [O] Running babel blocks in :noexport: sections
Just kidding... just checked *Messages* buffer, and all the headlines I converted to COMMENT headlines are *not* executing the enclosed babel blocks. Is there a setting for this you have and I don't? John On Sun, Oct 28, 2012 at 12:23 PM, John Hendy jw.he...@gmail.com wrote: On Sat, Oct 27, 2012 at 5:57 PM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: For papers and beamer presentations, I sometimes hide more universal babel blocks inside a sort of setup headline. I thought I'd done this before, but perhaps not... The idea would be like so: * Data setup :noexport: #+begin_src R :session r load libraries read data files do universal operations #+end_src * Slide #+begin_src R :session r :exports results :results output graphics subset(larger_data_set_from_above) processing plot something #+end_src I noticed today that my :noexport: setup sections (I had a couple) were not updating. I re-defined a variable name further down in my file and it was re-using the definition from an above setup section (tagged with :noexport:). Just because I don't want it export doesn't mean I don't want to have useful stuff in the headline... Is this a bug/inappropriate setting, desirable based on how others use :noexport: headlines, or would others see value in executing babel blocks in :noexport: headlines? If I /didn't/ want it executed, I'd use :execute no. Thanks for any input, John Instead of tagging the headline as :noexport: you can add the COMMENT flag to it. This should result in your desired behavior. See the attached example. Brilliant. That'll do just fine. Never knew about that! John -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Tangling to Multiple Files
Aloha Alan, This can be achieved with noweb references. Something like this: #+name: user-host-a #+HEADERS: :tangle user-host-a.el :noweb tangle #+BEGIN_SRC emacs-lisp initial-frame #+END_SRC #+name: user-host-b #+HEADERS: :tangle user-host-b.el :noweb tangle #+BEGIN_SRC emacs-lisp initial-frame #+END_SRC #+name: initial-frame #+BEGIN_SRC emacs-lisp (setq initial-frame-alist '((width . 80) (height . 38))) #+END_SRC hth, Tom Alan Lue alan@gmail.com writes: Hi, how does one tangle a single code block to multiple files? I thought the following might work, but unfortunately it does not. Set the frame size. #+HEADERS: :tangle user-host-a.el user-host-b.el #+BEGIN_SRC emacs-lisp (setq initial-frame-alist '((width . 80) (height . 38))) #+END_SRC To provide some background, I'm using =org-babel-load-file= in my init.el file to load up my Emacs configuration from an Org file—call it user.org. I'd like to use just one user.org file across multiple computers, however, meaning I'd like user.org to tangle into user-host-a.el and user-host-b.el, for instance. The configurations are only slightly different, so I'd like to be able to selectively indicate to Org-mode which code blocks to tangle into. -- Thomas S. Dye http://www.tsdye.com
Re: [O] Tangling to Multiple Files
Alan Lue alan@gmail.com writes: Hi, how does one tangle a single code block to multiple files? I thought the following might work, but unfortunately it does not. Set the frame size. #+HEADERS: :tangle user-host-a.el user-host-b.el #+BEGIN_SRC emacs-lisp (setq initial-frame-alist '((width . 80) (height . 38))) #+END_SRC To provide some background, I'm using =org-babel-load-file= in my init.el file to load up my Emacs configuration from an Org file—call it user.org. I'd like to use just one user.org file across multiple computers, however, meaning I'd like user.org to tangle into user-host-a.el and user-host-b.el, for instance. The configurations are only slightly different, so I'd like to be able to selectively indicate to Org-mode which code blocks to tangle into. You could try something like the following to tangle out to a different file on each machine. :tangle (format %s.el system-name) or :tangle (format %s.el user-login-name) Hope this helps, -- Eric Schulte http://cs.unm.edu/~eschulte
[O] New LaTeX exporter captions
Aloha Nicolas,
An example I gave on the ML a few days ago doesn't really work right.
#+name: fundamental-model
#+header: :exports results
#+header: :file fundamental-model.pdf
#+BEGIN_SRC dot
graph G
{
graph [margin=0.01];
d [label = Dated event, shape =box];
t [label = Target event];
d -- t [label = Association, dir = both, len = 2];
{rank=same; d t;}
}
#+END_SRC
#+CAPTION[The fundamental relationship of a chronological model]:
#+CAPTION: The fundamental relationship of a chronological model based on
radiometric dating.
#+ATTR_LaTeX: width=232pt
#+NAME: fig:fundamental
#+RESULTS: fundamental-model
[[file:fundamental-model.pdf]]
In particular, the short part of caption doesn't export unless the colon
is followed by some content. Is this intentional? It seems like a
reasonable restriction to me.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Running babel blocks in :noexport: sections
John Hendy jw.he...@gmail.com writes: Just kidding... just checked *Messages* buffer, and all the headlines I converted to COMMENT headlines are *not* executing the enclosed babel blocks. Is there a setting for this you have and I don't? Not that I know of. Are you using the new or the old exporter? What behavior do you get when running with emacs -Q? -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Tangling to Multiple Files
Thanks Eric, I didn't know that you could pass lisp code as header arguments. It looks like it'll be best to conditionally tangle. :tangle (if (string-match myhost system-name) yes no) Eric Schulte schulte.e...@gmail.com writes: Alan Lue alan@gmail.com writes: Hi, how does one tangle a single code block to multiple files? I thought the following might work, but unfortunately it does not. Set the frame size. #+HEADERS: :tangle user-host-a.el user-host-b.el #+BEGIN_SRC emacs-lisp (setq initial-frame-alist '((width . 80) (height . 38))) #+END_SRC To provide some background, I'm using =org-babel-load-file= in my init.el file to load up my Emacs configuration from an Org file—call it user.org. I'd like to use just one user.org file across multiple computers, however, meaning I'd like user.org to tangle into user-host-a.el and user-host-b.el, for instance. The configurations are only slightly different, so I'd like to be able to selectively indicate to Org-mode which code blocks to tangle into. You could try something like the following to tangle out to a different file on each machine. :tangle (format %s.el system-name) or :tangle (format %s.el user-login-name) Hope this helps,
Re: [O] New LaTeX exporter captions
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
An example I gave on the ML a few days ago doesn't really work right.
#+name: fundamental-model
#+header: :exports results
#+header: :file fundamental-model.pdf
#+BEGIN_SRC dot
graph G
{
graph [margin=0.01];
d [label = Dated event, shape =box];
t [label = Target event];
d -- t [label = Association, dir = both, len = 2];
{rank=same; d t;}
}
#+END_SRC
#+CAPTION[The fundamental relationship of a chronological model]:
#+CAPTION: The fundamental relationship of a chronological model based on
radiometric dating.
#+ATTR_LaTeX: width=232pt
#+NAME: fig:fundamental
#+RESULTS: fundamental-model
[[file:fundamental-model.pdf]]
In particular, the short part of caption doesn't export unless the colon
is followed by some content. Is this intentional?
At first, only one caption line was allowed. Thus, it didn't make much
sense to provide a short caption but no long caption. Now captions are
multi-lines, it may be possible to do so. I've removed the restriction
in master branch.
Note that you can also use the following:
#+CAPTION[The fundamental relationship of a chronological model]: The
fundamental
#+CAPTION: relationship of a chronological model based on radiometric dating.
Regards,
--
Nicolas Goaziou
Re: [O] New LaTeX exporter captions
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
An example I gave on the ML a few days ago doesn't really work right.
#+name: fundamental-model
#+header: :exports results
#+header: :file fundamental-model.pdf
#+BEGIN_SRC dot
graph G
{
graph [margin=0.01];
d [label = Dated event, shape =box];
t [label = Target event];
d -- t [label = Association, dir = both, len = 2];
{rank=same; d t;}
}
#+END_SRC
#+CAPTION[The fundamental relationship of a chronological model]:
#+CAPTION: The fundamental relationship of a chronological model based on
radiometric dating.
#+ATTR_LaTeX: width=232pt
#+NAME: fig:fundamental
#+RESULTS: fundamental-model
[[file:fundamental-model.pdf]]
In particular, the short part of caption doesn't export unless the colon
is followed by some content. Is this intentional?
At first, only one caption line was allowed. Thus, it didn't make much
sense to provide a short caption but no long caption. Now captions are
multi-lines, it may be possible to do so. I've removed the restriction
in master branch.
Note that you can also use the following:
#+CAPTION[The fundamental relationship of a chronological model]:
The fundamental
#+CAPTION: relationship of a chronological model based on
radiometric dating
Neat. Thanks for the help.
All the best,
Tom
--
T.S. Dye Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
[O] [new exporter] Date format string not handled for LaTeX export
When I provide a format string to the #+DATE: option, the old LaTeX exporter correctly uses it to format the current date; the new exporter just uses the format string for the date. The new HTML exporter does not have this problem.
