Re: [O] [babel] Commenting out src blocks for tangling
schulte.e...@gmail.com writes: > Alan Schmitt writes: > >> Hi Eric, >> >> schulte.e...@gmail.com writes: >> I see that "hello subtree" is tangled. Does it mean that to comment a whole tree I need to comment every subtree (recursively)? Thanks, Alan >>> >>> I just pushed up a fix, thanks for catching this bug. >> >> I'm sorry, but I think there is a bug with the fix. When I tangle a >> file, I get an error: >> >> org-babel-under-commented-heading-p: Symbol's function definition is void: >> org-babel-under-commented-headline-p >> >> I also see a failure with the tests: >> >> 1 unexpected results: >>FAILED ob-tangle/continued-code-blocks-w-noweb-ref >> >> I just did a git pull before trying this. >> > > This should be fixed now, thanks for pointing it out. It's working, thanks a lot! Alan
Re: [O] src code switches via properties
My apologies, I misread your email. Please disregard my previous response. Setting switches in the same way as header arguments is not (to my knowledge) possible. Switches are handled seperately from header arguments in org-src.el instead of ob-core.el. Best, Eric Schulte writes: > This is addressed by the following section of the manual. > > http://orgmode.org/manual/Using-header-arguments.html#Using-header-arguments > > (info "(org)Using header arguments") > > MGJT writes: > >> Dear all, >> >> >> Is there any way to specify src code switches, e.g. #+begin_src maxima +n >> -r, via a property for the subtree, as one can do for header arguments? >> >> I have taken a look at ob-core.el. I found that the function >> org-babel-params-from-properties makes use of the >> variable org-babel-common-header-args-w-values, which defines a list of >> only header arguments. (Org-mode version 8.0.5) >> >> If not via a property, any suggestion (perhaps an in-buffer setting)? >> >> Your help is much appreciated. >> >> >> Cheers, >> >> Manuel GJT -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] src code switches via properties
This is addressed by the following section of the manual. http://orgmode.org/manual/Using-header-arguments.html#Using-header-arguments (info "(org)Using header arguments") MGJT writes: > Dear all, > > > Is there any way to specify src code switches, e.g. #+begin_src maxima +n > -r, via a property for the subtree, as one can do for header arguments? > > I have taken a look at ob-core.el. I found that the function > org-babel-params-from-properties makes use of the > variable org-babel-common-header-args-w-values, which defines a list of > only header arguments. (Org-mode version 8.0.5) > > If not via a property, any suggestion (perhaps an in-buffer setting)? > > Your help is much appreciated. > > > Cheers, > > Manuel GJT -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] Slight l10n annoyances in Org, switching to Ubuntu 13.10
Hi, my fellow Orgers. I got annoyances in Org while switching to Ubuntu 13.10, and am sharing there here, in case others would inherit them, to save them some time. English users are not affected. The following problems are not pertaining to Org per se, they just show in there. The strange thing is that these problems have been reported years ago according to Google, and so, are apparently resurrecting. - Under the Unity window manager (maybe GNOME as well, I did not try), dead keys for applying diacritics stop working. One has to resort to the compose key or Emacs specific commands to type them. The problem is partly alleviated by adding this line in Emacs: (require 'iso-transl) but not completely: for example, the cedilla still does not work. Everything seems to work fine in applications other than Emacs, or using other window managers (I only tried spectrwm). - Within Org dates, the abbreviation of weekday is shown in English, while it used to be shown in French, which is appropriate in my case. Sebastien Vauban provided a solution: (setq system-time-locale (getenv "LANG")) François P.S. I still have that my browser preference is not obeyed anymore despite I think I declared it, and will soon try to understand why.
Re: [O] [babel] Commenting out src blocks for tangling
Alan Schmitt writes: > Hi Eric, > > schulte.e...@gmail.com writes: > >>> I see that "hello subtree" is tangled. Does it mean that to comment a >>> whole tree I need to comment every subtree (recursively)? >>> >>> Thanks, >>> >>> Alan >> >> I just pushed up a fix, thanks for catching this bug. > > I'm sorry, but I think there is a bug with the fix. When I tangle a > file, I get an error: > > org-babel-under-commented-heading-p: Symbol's function definition is void: > org-babel-under-commented-headline-p > > I also see a failure with the tests: > > 1 unexpected results: >FAILED ob-tangle/continued-code-blocks-w-noweb-ref > > I just did a git pull before trying this. > This should be fixed now, thanks for pointing it out. Best, > > Alan -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] src code switches via properties
Dear all, Is there any way to specify src code switches, e.g. #+begin_src maxima +n -r, via a property for the subtree, as one can do for header arguments? I have taken a look at ob-core.el. I found that the function org-babel-params-from-properties makes use of the variable org-babel-common-header-args-w-values, which defines a list of only header arguments. (Org-mode version 8.0.5) If not via a property, any suggestion (perhaps an in-buffer setting)? Your help is much appreciated. Cheers, Manuel GJT
Re: [O] rotate tables
>> "Michael" == Michael Brand writes: > Hi Uwe > On Sun, Oct 20, 2013 at 10:12 PM, Uwe Brauer wrote: >> | 1 | 2 | 3 | >> | 4 | 3 | 4 | >> >> becomes >> >> | 4 | 1 | >> | 3 | 2 | >> | 4 | 3 | > 1) mark table > 2) M-x reverse-region > 3) with point in the table: M-x org-table-transpose-table-at-point > Michael Cool thanks!!! Uwe smime.p7s Description: S/MIME cryptographic signature
Re: [O] Drag images from Firefox to org-mode
Oleh writes: > This can be fixed with a platform-aware function that checks both the > clipboard and the cut-buffer. I suggest to ask for a string with (read-string "URL: " nil nil default), offering the content of the clipboard/kill ring/selections as the DEFAULT. I think it's better to be explicit when downloading content, and there isn't much overhead in asking for a confirmation. > This can be fixed by adding `org-download-max-filename-length`. When > it > overflows, just resort to `default-directory' and provide a > message/option to fix. I suggest that the right place for those files is as attachment, and that's where customization should happen. The function choosing the right place (i.e. org-download--dir) could be turned into a defvar or defcustom which could then be set either to #'org-download--dir or #'org-attach-dir. > By the way, which system doesn't allow for spaces in directory names? ISTR that MSDOS (except the latest versions) didn't allow spaces in filenames :) Anyway, I tend to avoid spaces as much as I can in filenames (including dirs) > If you want the ability to create arbitrary output directories > based > on document context, the customization can be made to accept a > function (lambda) as a value, which could then return a directory > prefix. > This isn't an option for users with no elisp skills. It is an option if there are enough examples/built-ins that can be used. e.g. message-send-mail-function can be customized in this way, its docstring gives a list of meaningful values. -- Nico.
Re: [O] rotate tables
Hi Uwe On Sun, Oct 20, 2013 at 10:12 PM, Uwe Brauer wrote: > | 1 | 2 | 3 | > | 4 | 3 | 4 | > > becomes > > | 4 | 1 | > | 3 | 2 | > | 4 | 3 | 1) mark table 2) M-x reverse-region 3) with point in the table: M-x org-table-transpose-table-at-point Michael
[O] rotate tables
Hi I googled a bit but found no solution to the problem of rotating a table such that | 1 | 2 | 3 | | 4 | 3 | 4 | becomes | 4 | 1 | | 3 | 2 | | 4 | 3 | Thanks Uwe Brauer
Re: [O] [RFC] Change some defcustoms into defcont
Hi Nicolas, I think this change breaks user setups. I don't know how many people do change these keywords, but I know some do, if only for localization purposes. I myself have modified the archive keyword in some cases, if I use this feature for a different purpose. You probably want to do this to make Org syntax less fragile. A good goal. However, I think it can also be achieved by leaving these as defcustom and discouraging changes in the docstring with a standard sentence about about deprecation. Your most important argument to me seems about efficiency of cashing. We can fix this by providing :set methods for the customize entries that will trigger global cache erasing, so that you do not need to programmatically check this all the time. Regards - Carsten On 20.10.2013, at 10:47, Nicolas Goaziou wrote: > Hello, > > I'd like to suggest changing the following defcustom variables into > defconst: > > - org-deadline-string > - org-scheduled-string > - org-closed-string > - org-clock-string > - org-comment-string > - org-quote-string > - org-effort-property > - org-archive-tag > > There's no fundamental reason to change these, as they belong to Org > syntax, much like star character for headlines and ":END:" closing > string for drawers. > > They can also introduce bugs in code when modified (e.g. modifying > `org-effort-property' breaks `ox-taskjuggler'). Of course, this can be > avoided with careful checks, but this puts an extra burden on developers > for a tiny benefit for the user. > > Eventually, they can be costly, since changing any of them implies that > cache in every Org buffer must be erased. > > Allowing customization is generally good, but I think Org syntax should > never be a moving target. > > Note that this shouldn't introduce much backward incompatibility (unless > user changes them through customize interface) since a defconst can > still be setq'ed and variables will still be used in code base. > > Opinions? > > > Regards, > > -- > Nicolas Goaziou >
[O] Bug dragging lines in tag-restricted agenda
Hello, Org mode hackers. I'm using Org-mode version 8.2 (`release_8.2-157-g1e018e' @ `/src/org-mode/lisp/') and GNU Emacs 24.3.1 (`x86_64-unknown-linux-gnu', X toolkit, Xaw3d scroll bars) of 2013-09-21. I started Emacs with `emacs -Q -l setup.el' (file attached). This opened a day agenda view. , | Day-agenda (W42): | Friday 18 October 2013 | test-case: Scheduled: TODO Pick up package from post office :errands: | test-case: Scheduled: TODO Clean stovetop | test-case: Scheduled: TODO Buy water at store :errands: ` I typed `/ TAB errands RET' to restrict it to items with the tag `errands'. The restricted view looked like this: , | Day-agenda (W42): | Friday 18 October 2013 | test-case: Scheduled: TODO Pick up package from post office :errands: | test-case: Scheduled: TODO Buy water at store :errands: ` I moved point to the line containing "Pick up package" and typed `M-' to drag the line forward. Since there was a hidden line, "Clean stovetop", between the other two, I expected no visible change, or even better, that "Pick up package" would move below "Buy water", like this: , | Day-agenda (W42): | Friday 18 October 2013 | test-case: Scheduled: TODO Buy water at store :errands: | test-case: Scheduled: TODO Pick up package from post office :errands: ` Instead, "Clean stovetop" was made visible and "Pick up package" was moved below it: , | Day-agenda (W42): | Friday 18 October 2013 | test-case: Scheduled: TODO Clean stovetop | test-case: Scheduled: TODO Pick up package from post office :errands: | test-case: Scheduled: TODO Buy water at store :errands: ` I believe it is a bug for `M-' to make an item visible that doesn't match the tag in a tag-narrowed view, and I think the most useful thing to do is to move the line beyond the next visible item. Thanks, Thomas setup.el Description: application/emacs-lisp #+TITLE: Bug dragging lines in tag-restricted agenda * TODO Pick up package from post office :errands: SCHEDULED: <2013-10-18 Fri> * TODO Clean stovetop SCHEDULED: <2013-10-18 Fri> * TODO Buy water at store :errands: SCHEDULED: <2013-10-18 Fri>
Re: [O] [RFC] Do not declare drawers to use them
Hello Nicolas, I think one objection agains this patch is that, I think, MobileOrg relies on #+DRAWERS lines to be present to define drawers. Maybe the MobileOrg maintainers for both Android and iOS can chime in here? Otherwise I don't have a significant objection against this change. I am wondering if it is going to introduce spurious drawers and parsing errors if someone happens to have a string :xxx: on a line by itself in the buffer. This might be unlikely, but I am not really sure. Comments? - Carsten On 20.10.2013, at 15:38, Nicolas Goaziou wrote: > Hello, > > At the moment, in order to use a drawer, one has to declare its name > through `org-drawers' variable or DRAWERS keyword first. > > I'd like to simplify a bit the process and let the user create drawers > on the fly instead. A valid name includes any word constituent, hyphen > and underscore characters. Case isn't significant. > > It also cleans the internals (i.e. some dynamically scoped variables are > removed) and makes syntax more portable. But we lose completion for > drawer names. > > This patch is backward compatible, as long as previously user-defined > drawers didn't include forbidden characters within their names. > > WDYT? > > > Regards, > > -- > Nicolas Goaziou > <0001-Remove-need-to-declare-drawers-before-using-them.patch>
Re: [O] [babel] Commenting out src blocks for tangling
Hi Eric, schulte.e...@gmail.com writes: >> I see that "hello subtree" is tangled. Does it mean that to comment a >> whole tree I need to comment every subtree (recursively)? >> >> Thanks, >> >> Alan > > I just pushed up a fix, thanks for catching this bug. I'm sorry, but I think there is a bug with the fix. When I tangle a file, I get an error: org-babel-under-commented-heading-p: Symbol's function definition is void: org-babel-under-commented-headline-p I also see a failure with the tests: 1 unexpected results: FAILED ob-tangle/continued-code-blocks-w-noweb-ref I just did a git pull before trying this. Alan
Re: [O] Create sub-directories and files from within org
I don't understand what you are trying to do here. you could write a lisp function that you run in the ** project name heading that creates a directory by that name. But what would the txt files in that directory be? John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Fri, Oct 18, 2013 at 10:35 PM, Chris Henderson wrote: > If I create a project with ** project name, is there any way to create a > sub-directory at *** level in ~/projects/project name and create txt files > in that directory - all from within org? > > Thanks. >
[O] [RFC] Do not declare drawers to use them
Hello,
At the moment, in order to use a drawer, one has to declare its name
through `org-drawers' variable or DRAWERS keyword first.
I'd like to simplify a bit the process and let the user create drawers
on the fly instead. A valid name includes any word constituent, hyphen
and underscore characters. Case isn't significant.
It also cleans the internals (i.e. some dynamically scoped variables are
removed) and makes syntax more portable. But we lose completion for
drawer names.
This patch is backward compatible, as long as previously user-defined
drawers didn't include forbidden characters within their names.
WDYT?
Regards,
--
Nicolas Goaziou
>From 8a2dad690caec96e6daf86097ff0cb062ac348f8 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Sun, 20 Oct 2013 14:40:09 +0200
Subject: [PATCH] Remove need to declare drawers before using them
* lisp/org-agenda.el (org-agenda-prepare): Remove reference to
`org-drawers-for-agenda'.
(org-agenda-show-1): Remove reference to `org-drawers'.
* lisp/org-clock.el (org-clock-remove-empty-clock-drawer,
org-clock-cancel): Apply signature change to
`org-remove-empty-drawer-at'.
* lisp/org-element.el (org-element--list-struct): Use
`org-drawer-regexp' instead of `org-drawers'.
* lisp/org-feed.el (org-feed-drawer): Update docstring according to
change.
* lisp/org-list.el (org-in-item-p, org-list-context): Use
`org-drawer-regexp' instead of `org-drawers'.
* lisp/org-mobile.el (org-mobile-create-index-file): Remove reference
to `org-drawers-for-agenda'.
* lisp/org-pcomplete.el (pcomplete/org-mode/drawer): Remove function.
* lisp/org.el (org-drawer-regexp): Make variable global.
(org-drawers): Remove variable.
(org-set-regexps-and-options): Ignore DRAWER keyword.
(org-cycle): Use `org-drawer-regexp' instead of `org-drawers'.
(org-cycle-hide-drawers): Add an optional argument to ignore some
drawers.
(org-remove-empty-drawer-at): Remove second argument. Rewrite
function.
(org-clone-subtree-with-time-shift): Apply signature change to
`org-remove-empty-drawer-at'.
(org-toggle-ordered-property): Apply `org-delete-property' signature
change.
(org-map-entries): Remove reference to `org-drawers-for-agenda'.
(org-entry-delete): Remove optional argument. Small refactoring.
(org-insert-drawer): Remove reference to `org-drawers'.
(org-delete-property): Apply `org-entry-delete' signature change.
(org-in-drawer-p): Rewrite function.
* testing/lisp/test-org-element.el: Update tests.
* testing/lisp/test-org.el: Update tests.
* testing/lisp/test-ox.el: Update tests.
---
lisp/org-agenda.el | 15 ++---
lisp/org-clock.el| 6 +-
lisp/org-element.el | 5 +-
lisp/org-feed.el | 5 +-
lisp/org-list.el | 25 ++-
lisp/org-mobile.el | 4 +-
lisp/org-pcomplete.el| 19 --
lisp/org.el | 141 ++-
testing/lisp/test-org-element.el | 57 ++--
testing/lisp/test-org.el | 22 +++---
testing/lisp/test-ox.el | 28
11 files changed, 109 insertions(+), 218 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 0bfba27..fe4c2d4 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3642,7 +3642,6 @@ generating a new one."
(or org-agenda-multi (org-agenda-fit-window-to-buffer))
(throw 'exit "Sticky Agenda buffer, use `r' to refresh"))
(setq org-todo-keywords-for-agenda nil)
-(setq org-drawers-for-agenda nil)
(unless org-agenda-persistent-filter
(setq org-agenda-tag-filter nil
org-agenda-category-filter nil
@@ -3682,7 +3681,6 @@ generating a new one."
(org-uniquify org-todo-keywords-for-agenda))
(setq org-done-keywords-for-agenda
(org-uniquify org-done-keywords-for-agenda))
- (setq org-drawers-for-agenda (org-uniquify org-drawers-for-agenda))
(setq org-agenda-last-prefix-arg current-prefix-arg)
(setq org-agenda-this-buffer-name org-agenda-buffer-name)
(and name (not org-agenda-name)
@@ -8627,15 +8625,10 @@ if it was hidden in the outline."
(run-hook-with-args 'org-cycle-hook 'subtree))
(message "Remote: SUBTREE"))
((= more 4)
- (let* ((org-drawers (delete "LOGBOOK" (copy-sequence org-drawers)))
- (org-drawer-regexp
- (concat "^[ \t]*:\\("
- (mapconcat 'regexp-quote org-drawers "\\|")
- "\\):[ \t]*$")))
- (show-subtree)
- (save-excursion
- (org-back-to-heading)
- (org-cycle-hide-drawers 'subtree)))
+ (show-subtree)
+ (save-excursion
+ (org-back-to-heading)
+ (org-cycle-hide-drawers 'subtree '("LOGBOOK")))
(message "Remote: SUBTREE AND LOGBOOK"))
((> more 4)
(show-subtree)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 3195dc1..1cdbdc1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1589,7 +1589,7 @@ to, overriding the existing value of `org-clock-out-switch-to-state'."
(while (and (< (po
[O] [RFC] Change some defcustoms into defcont
Hello, I'd like to suggest changing the following defcustom variables into defconst: - org-deadline-string - org-scheduled-string - org-closed-string - org-clock-string - org-comment-string - org-quote-string - org-effort-property - org-archive-tag There's no fundamental reason to change these, as they belong to Org syntax, much like star character for headlines and ":END:" closing string for drawers. They can also introduce bugs in code when modified (e.g. modifying `org-effort-property' breaks `ox-taskjuggler'). Of course, this can be avoided with careful checks, but this puts an extra burden on developers for a tiny benefit for the user. Eventually, they can be costly, since changing any of them implies that cache in every Org buffer must be erased. Allowing customization is generally good, but I think Org syntax should never be a moving target. Note that this shouldn't introduce much backward incompatibility (unless user changes them through customize interface) since a defconst can still be setq'ed and variables will still be used in code base. Opinions? Regards, -- Nicolas Goaziou
