Re: [O] BeOrg
"as a GNU package, we're not allowed to mention proprietary software"
-- how is that consistent with GNU prominently distributing Emacs for
Windows from its own website? I think this shows that the guideline
is not absolute. And it's specifically phrased as a guideline
("should"), not as a requirement.
To _mention_ is not the same as to _endorse_. One can mention a
non-free program, along with a link to GNU's reasoning against such
programs, and let users decide. Deciding for them is paternalistic.
It also looks like simple protectionism: rather than writing a free
program superior to the non-free one, mentioning both and letting
users decide, we'll just hide the non-free one.
I don't see why not to write beOrg at all is perfectly ethical, but to
write it without making it free is unethical. What freedoms does a
non-existing program give users?
On Tue, Jan 2, 2018 at 9:06 PM, Ian Dunn wrote:
>> "Peter" == Peter Davis writes:
>
> Peter> If we refuse to provide useful information just because it
> Peter> violates some purist idea of what is or is not acceptably
> Peter> unencumbered, then we’re just denying users potential helpful
> Peter> capabilities that may make the difference between using
> Peter> org-mode or abandoning it completely in favor of some
> Peter> commercial, cross-platform solution.
>
> Nicolas mentioned that as a GNU package, we're not allowed to mention
> proprietary software[1]. My understanding is that the reasoning behind
> this is that we don't want to appear to endorse proprietary software.
> The GNU project finds proprietary software unethical, so they will not
> see it as providing useful information, but endorsing an unethical
> solution.
>
> Peter, I understand your reasoning; the LGPL was designed specifically
> for this purpose, i.e. allowing a non-free solution built upon a free
> one. However, I don't believe we should encourage use of such solutions
> without evidence that people are turned away from Org mode because of a
> mobile solution they don't like.
>
> [1] https://www.gnu.org/prep/standards/html_node/References.html#References
>
> --
> Ian Dunn
Re: [O] BeOrg
>as GNU software, we should not suggest to use non-free software But, clearly, we already do: suggesting to use MobileOrg necessarily suggests to use iOS. Besides, some of the main critiques of non-free software do not apply here: e.g. beorg doesn't lock the user into some proprietary format. And while it may be unethical to lure unsophisticated computer users into freedom-relinquishing decisions the consequences of which they may not fully grasp, most Org users are sophisticated enough to make an intelligent and informed choice. GNU itself distributes Emacs for Windows from its main site ( http://ftp.gnu.org/gnu/emacs/windows/ ), so there's a balance of considerations. I think here the balance tips in favor of mentioning beOrg. I've tried MobileOrg and gave up on it, while beOrg is more usable; judging by the reviews, others had a similar impression. On Tue, Jan 2, 2018 at 2:20 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > ilya shlyakhter <ilya...@gmail.com> writes: > >> Neither is iOS or MATLAB, and yet the Org manual mentions both. > > We have good reasons for that. The former is because MobileOrg, which > uses "org-mobile.el", provided by Org, and therefore, documented. The > latter is because "ob-matab.el", which is free software. > > OTOH, as GNU software, we should not suggest to use non-free software. > Besides, it is not related to any library in our source code. > > Regards, > > -- > Nicolas Goaziou
Re: [O] BeOrg
>This may be because the app is not open source? Neither is iOS or MATLAB, and yet the Org manual mentions both. On Tue, Jan 2, 2018 at 12:39 PM, Eric S Fraga <esfli...@gmail.com> wrote: > On Tuesday, 2 Jan 2018 at 12:32, Ilya Shlyakhter wrote: >> The org features page at https://orgmode.org/features.html, and the >> Org manual, mention MobileOrg, but not the newer BeOrg app >> ( http://beorgapp.com/ ). Maybe add a reference to it? > > This may be because the app is not open source? > > -- > Eric S Fraga via Emacs 27.0.50, Org release_9.1.6
[O] BeOrg
The org features page at https://orgmode.org/features.html, and the Org manual, mention MobileOrg, but not the newer BeOrg app ( http://beorgapp.com/ ). Maybe add a reference to it?
[O] org-timeline documentation
The org-timeline documentation at http://orgmode.org/manual/Timeline.html seems no longer correct? (also, I think it's unfortunate that the timeline agenda mode was removed -- I found it quite useful.)
[O] broken links to gmane on orgmode.org
At http://orgmode.org/community.html the links to browse or search emacs-orgmode through Gmane are broken. Maybe, remove them until Gmane is fixed? Is there another service similar to Gmane?
[O] gmane link broken
The link "Browse org-mode mailing list through Gmane" at http://orgmode.org/community.html seems broken.
[O] bug report: "File mode specification error: (error "before first heading")
When loading any org file, I'm getting "File mode specification error: (error "before first heading")" . This happens starting with release_8.3.3 ; with release_8.3.2 , no error. Emacs version is GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.6) of 2015-03-26 on scs-build-rhel6 .
Re: [O] Preserve formatting when copy/pasting from HTML
torys.ander...@gmail.com (Tory S. Anderson) writes: We often read online articles with headings and sometimes subheadings. They may also include bold, italic, and hyperlinks, all of which are supported by Org. Is there any way to preserve this formatting if I copy-paste into org/emacs, the same way it's preserved when I paste into Word or into a Google Document/email? Or is this fundamentally difficult in emacs? It would be a tremendous feature. There is an extension for doing this when copying from emacs-w3m into org: http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=lisp/org-w3m.el;hb=HEAD
Re: [O] [RFC] Org Minor Mode?
Bastien b...@gnu.org writes: We should absolutely avoid advice in code. Fully agree. (I was thinking of using an flet-like construct to temporarily rebind functions for the duration of calls, rather than permanent advice -- see elu-flet in https://github.com/notestaff/elu/blob/master/elu.el -- but, still agree.) What would be the downside of abstracting away the headline syntax in the Org code? (Other than the admittedly significant issue of disturbing well-tested core code. On the other hand, abstracted code would be more readable maintainable; see e.g. Org syntax defined with an rx-like extension: https://github.com/notestaff/elu/blob/master/rxx-org.el , or with Thorsten's drx.el ) Obviously this would be a lot of work, but the upside of having a full Org minor mode (in particular for outshine-type use) would make it worth it, for me at least.
Re: [O] [RFC] Org Minor Mode?
On 4/19/2014 8:57 AM, Bastien wrote: Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: In summary, its about: 1. generalize the regexp constants and vars (allow for comment-syntax, when org-minor-mode) 2. deal with hardcoded regexp-snippets in functions (my proposoal: replace ^ with org-BOL, $ with org-EOL, \\* with org-STAR) 3. outcomment new lines after calls to Org commands. I still think there is a simpler way, I'll explore this and I'll let you know. What about using advice on regexp functions to transform the regexps (when invoked in org-minor-mode buffers) so that $ is replaced with ; $ etc? One other issue is the use of the number of stars to determine outline level.
Re: [O] [RFC] Org Minor Mode?
On 4/10/2014 3:19 PM, Nicolas Goaziou wrote: I don't see why you would need the full power of Org-mode (whatever that means) in mere comments. There are actually many uses, especially if it becomes possible to treat language elements (functions, classes etc) as outline elements (cf. https://github.com/notestaff/outshine/blob/outshine-lang/outshine-lang.el ). Sparse trees and agenda views could be used to find all code elements related to a particular aspect of functionality, if items related to that aspect are tagged with a tag. Sparse trees could show just the public (interface) elements. Basically, outshine with the full power of Org and the ability to treat language elements as outline headings would add up to the first literate programming system I'd call usable.
Re: [O] OrgStruct for Python source code
On 3/19/2014 3:39 PM, Karl Voit wrote: I am evaluating methods to fold Python source code. simply turn on orgstruct-mode in a python buffer and try M-x org-cycle RET on a def: it will fold it. Another option is to use Thorsten Jolitz's excellent outshine mode ( http://orgmode.org/worg/org-tutorials/org-outside-org.html ). I've written a small extension that allows it to fold language elements: http://www.broadinstitute.org/~ilya/outshine-python.el
Re: [O] OrgStruct for Python source code
On 3/19/2014 9:19 PM, Ilya Shlyakhter wrote: Another option is to use Thorsten Jolitz's excellent outshine mode ( http://orgmode.org/worg/org-tutorials/org-outside-org.html ). I've written a small extension that allows it to fold language elements: http://www.broadinstitute.org/~ilya/outshine-python.el Apologies, correct link is https://github.com/notestaff/outshine/blob/outshine-lang/outshine-lang.el
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
Thanks Bastien. Property API documentation could be made more precise in some places. From the documentation of org-entry-get (both the docstring and the Org manual), it would seem that unless the inherit argument is non-nil, file-wide and system-wide property settings should not be checked at all? The Org manual seems especially clear: By default, this only looks at properties defined locally in the entry. Logically, it makes sense to think of file-wide properties as being on an implicit level 0 headline under which all headlines in the file are grouped, and system-wide properties as being on an implicit level -1 headline under which all level-0 headlines are grouped. But, existing code and Org files might rely on org-entry-get without inheritance considering file-wide and system-wide properties? Documentation of the variable org-use-property-inheritance also can be read to mean that it controls the inheritance of file-wide and system-wide properties, though currently it does not (When nil, only the properties directly given in the current entry count.) For org-entry-properties, it says Get all properties of the entry -- but it returns only properties explicitly defined at the entry, not anything inherited from up the hierarchy or file-wide or system-wide, right? It also says, Keys may occur multiple times if the property key was used several times. -- but the manual also says that a property can only have one entry per Drawer. Also, #+PROPERTY: lines have an effect no matter where they are in the file, but what happens when several of them set the same property isn't fully specified; I assume they're processed top-to-bottom, and later settings overwrite earlier ones, just as later prop+ settings append to earlier ones? (So in this sense it does matter where in the file a #+PROPERTY line is). It might also be useful to clarify that even if a subtree is archived, global property settings in that subtree continue to have an effect (because they aren't really in a subtree). Manual says that #+PROPERTY lines specify properties that can be inherited by any entry in a file; more precise would be that they specify property settings inherited by every entry? Likewise for the variable org-global-properties. On Tue, Mar 18, 2014 at 11:14 AM, Bastien b...@gnu.org wrote: Bastien b...@gnu.org writes: Ilya Shlyakhter ilya_...@alum.mit.edu writes: When I open emacs with this file, move to the emacs-lisp block, and evaluate it, I get aaa. I can reproduce your problem now, I'm on it, and the problem is real, but I need to make sure all tests pass fine before fixing this. Okay, so I committed a different fix in maint and master. Please test it and let me know. Thanks, PS: You may want to read the commit message: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=42ee862d -- Bastien
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
In the current master branch, doing the example from the patch (reproduced below again) gives aaa, because the line (let (org-file-properties org-global-properties org-global-properties-fixed) has been removed from org-entry-get-with-inheritance . I agree that patching a function as core as this should be done with care; however, I'm pretty positive that there was a bug, as explained in the patch message. org-entry-get-with-inheritance calls org-entry-get for each entry going up the tree, to read the property at that entry _without_ inheritance; however, unless the let line above is included, this reading actually happens _with_ inheritance -- of global properties. So a property can appear to be set at a node during up-the-tree traversal, when in fact it is only set as a global property. If org-entry-get-with-inheritance see a property set at a node during up-the-tree traversal, it stops the traversal right there, ignoring any settings of this property further up the tree -- which should override any global settings of the same property. Here is the test case again: #+PROPERTY: myprop aaa * headline A :PROPERTIES: :myprop: bbb :END: *** headline B :PROPERTIES: :otherprop: ccc :END: #+BEGIN_SRC emacs-lisp (message (org-entry-get-with-inheritance myprop)) #} #+RESULTS: : aaa On Mon, Mar 17, 2014 at 4:35 PM, Bastien b...@gnu.org wrote: Achim Gratz strom...@nexgo.de writes: I meant: can you tell me how the tests fail? They don't produce the result they are supposed to produce. Thanks for this explanation. I'm interested in the answer. make BTEST_RE='\\(header-arg-defaults\\|property-accumulation\\)' test-dirty Thanks! If the patch is good and the tests are outdated, I'd rather fix the tests than revert the patch to re-revert it again. No, the patch is bad, otherwise it wouldn't break the tests. Sorry, I don't buy this. I'm not selling anything. What I meant is this: broken tests are not a sufficient reason to revert a commit. You need to show the commit is wrong and the tests are not outdated. In this case, I made the error of reproduce Ilya's solution, not Ilya's problem, so I wrong assumed his patch was the problem to his problem. Ilya: from the maint and master branch, I get bbb as a result for the example you placed in your commit message. Do you have aaa as a result with Org from maint or master? If so, can you provide a recipe? Thanks, -- Bastien
Re: [O] [PATCH] Fixed bug in org-entry-get-with-inheritance
On 3/17/14 5:43 PM, Achim Gratz wrote: The test case doesn't work as posted. A working test case produces the Try http://ilya.cc/testcase.org When I open emacs with this file, move to the emacs-lisp block, and evaluate it, I get aaa. I could easily be wrong re: the logic of the code, but can you help me see where I'm wrong in the explanation of the patch? Thanks, ilya
Re: [O] Is anyone spending money for Org-mode?
On 3/12/14 2:14 PM, Joost Helberg wrote: back in the time when me and my friend created and sold the Snow Linux Distribution, we donated all excess money to the FSF. If people wanted to give to the FSF, they would have done it directly. I've donated to Org in the past not to defray expenses but as a small token of thanks to Carsten the principal maintainers. Putting the donations to whatever personal use they want was the intention.
Re: [O] Links in tables: could the plain text also look good?
On 3/6/14 2:00 PM, Oleh wrote: I was just committing a single line change to an org-mode table into git, and the diff isn't good at all: the whole table appears to have changed. Well, not really - just a few spaces were added on each table line because the single new line caused a need to re-align the whole table. You can tell diff to ignore whitespace-only changes by using the -w option: https://www.kernel.org/pub/software/scm/git/docs/git-diff.html -w --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.
Re: [O] inline source code blocks
I think code blocks work well for non-inline code.
For a series of one-liners interspersed with comments, code block
boundaries triple the number of lines. E.g. the example in the manual
at http://orgmode.org/org.html#noweb_002dref
+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh
fullest-disk
#+END_SRC
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
#+BEGIN_SRC sh
df \
#+END_SRC
** strip the header row
#+BEGIN_SRC sh
|sed '1d' \
#+END_SRC
** sort by the percent full
#+BEGIN_SRC sh
awk '{print $5 $6}'|sort -n |tail -1 \
#+END_SRC
** extract the mount point
#+BEGIN_SRC sh
|awk '{print $2}'
#+END_SRC
could be shortened to
#+PROPERTY: ob-default-lang sh
#+HEADER: :tangle yes :noweb yes :shebang #!/bin/sh
: fullest-disk
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
: df \
** strip the header row
: |sed '1d' \
** sort by the percent full
: |awk '{print $5 $6}'|sort -n |tail -1 \
** extract the mount point
: |awk '{print $2}'
i.e. where the (inherited) property ob-default-lang exists, literal
examples become code blocks in that language.
Or in a list of C++ declarations:
#+PROPERTY: ob-default-lang c++
...
* class MyClass
Does X, Y and Z.
: class MyClass: public MyParent {
** Private fields
*** Field a: stores thing one
: int a;
*** Field b: stores thing two
: char *b;
** Public methods
: public:
*** Method getA: Returns the value of a.
: int getA() const { return a; }
** end class MyClass
: }
I'm finding that Org would work well as a literate programming system
for C++, if the code block starts and ends didn't get in the way so much
during frequent switching between code and prose.
I use the following to make code block syntax less intrusive
Thanks, that was helpful, didn't know about compose-region.
Still, it does not reduce the number of lines used, so a short list of
declarations interspersed with comments quickly ends up taking a lot of
vertical space. When coding it helps to be able to see many things at
once, and having many extra lines (even mostly-blank ones) makes that
difficult.
ilya
Re: [O] inline source code blocks
On 3/6/14 5:04 PM, Eric Schulte wrote:
I think code blocks work well for non-inline code.
For a series of one-liners interspersed with comments, code block
boundaries triple the number of lines. E.g. the example in the manual
at http://orgmode.org/org.html#noweb_002dref
+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh
fullest-disk
#+END_SRC
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
#+BEGIN_SRC sh
df \
#+END_SRC
** strip the header row
#+BEGIN_SRC sh
|sed '1d' \
#+END_SRC
** sort by the percent full
#+BEGIN_SRC sh
|awk '{print $5 $6}'|sort -n |tail -1 \
#+END_SRC
** extract the mount point
#+BEGIN_SRC sh
|awk '{print $2}'
#+END_SRC
could be shortened to
#+PROPERTY: ob-default-lang sh
#+HEADER: :tangle yes :noweb yes :shebang #!/bin/sh
: fullest-disk
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
: df \
** strip the header row
: |sed '1d' \
** sort by the percent full
: |awk '{print $5 $6}'|sort -n |tail -1 \
** extract the mount point
: |awk '{print $2}'
i.e. where the (inherited) property ob-default-lang exists, literal
examples become code blocks in that language.
Or in a list of C++ declarations:
#+PROPERTY: ob-default-lang c++
...
* class MyClass
Does X, Y and Z.
: class MyClass: public MyParent {
** Private fields
*** Field a: stores thing one
: int a;
*** Field b: stores thing two
: char *b;
** Public methods
: public:
*** Method getA: Returns the value of a.
: int getA() const { return a; }
** end class MyClass
:}
I'm finding that Org would work well as a literate programming system
for C++, if the code block starts and ends didn't get in the way so much
during frequent switching between code and prose.
I use the following to make code block syntax less intrusive
Thanks, that was helpful, didn't know about compose-region.
Still, it does not reduce the number of lines used, so a short list of
declarations interspersed with comments quickly ends up taking a lot of
vertical space. When coding it helps to be able to see many things at
once, and having many extra lines (even mostly-blank ones) makes that
difficult.
ilya
Re: [O] inline source code blocks
On 3/6/14 9:22 PM, Eric Schulte wrote: How about the following alternative to my previous suggestion, which will eliminate the extra lines. Looks beautiful initially, but leads to some confusing behaviors due to invisible lines. But eliminating extra lines is only important for some sections of code; in others, the extra lines (though shortened) actually help. I'll use begin_src/end_src for the former and BEGIN_SRC/END_SRC for the latter, and have your prettier-org-code-blocks fontifier match just the lowercase version. Thanks a lot, ilya
[O] [PATCH] Fixed bug in org-entry-get-with-inheritance
From bea0daf422e9ab8f27addb412aa03456c89d5844 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 7 Mar 2014 01:09:13 -0500 Subject: [PATCH] Properties: Fix property-getting with inheritance * lisp/org.el (org-entry-get-with-inheritance): Temporarily clear org-file-properties, org-global-properties and org-global-properties-fixed before calling org-entry-get on entries up the hierarchy from the queried entry. Problem was that when org-entry-get-with-inheritance went up the hierarchy of entries from a given entry, checking whether the property has been set in any of the entries, it was calling org-entry-get, which always looks at file-scope and global-scope properties. So if our property was set file-wide or system-wide, and somewhere up the hierarchy there was an entry which set some properties _other_ than the one we're looking up but did not set ours, org-entry-get would fill in the global property value and report that our property was in fact set in that entry. The search would stop, and if the property was actually set further up the hierarchy (which should override file-wide or system-wide settings), we would never get to that up-the-hierarchy setting. Illustration of fixed problem: #+PROPERTY: myprop aaa * headline A :PROPERTIES: :myprop: bbb :END: *** headline B :PROPERTIES: :otherprop: ccc :END: #+BEGIN_SRC emacs-lisp (message (org-entry-get-with-inheritance myprop)) #+END_SRC #+RESULTS: : aaa Result should be bbb, which it is after the fix. --- lisp/org.el | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 6f4b853..cd2a1c6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15548,14 +15548,15 @@ However, if LITERAL-NIL is set, return the string value \nil\ instead. (save-restriction (widen) (catch 'ex - (while t - (when (setq tmp (org-entry-get nil property nil 'literal-nil)) - (or (ignore-errors (org-back-to-heading t)) - (goto-char (point-min))) - (move-marker org-entry-property-inherited-from (point)) - (throw 'ex tmp)) - (or (ignore-errors (org-up-heading-safe)) - (throw 'ex nil)) + (let (org-file-properties org-global-properties org-global-properties-fixed) + (while t + (when (setq tmp (org-entry-get nil property nil 'literal-nil)) + (or (ignore-errors (org-back-to-heading t)) + (goto-char (point-min))) + (move-marker org-entry-property-inherited-from (point)) + (throw 'ex tmp)) + (or (ignore-errors (org-up-heading-safe)) + (throw 'ex nil))) (setq tmp (or tmp (cdr (assoc property org-file-properties)) (cdr (assoc property org-global-properties)) -- 1.8.4
[O] inline source code blocks
Some questions about inline source code blocks: - They're not fontified even when org-src-fontify-natively is true -- correct? - They're not included in tangled code; is that intended behavior? The manual does not seem to say they're different from normal code blocks, except for syntax. There are also mailing list messages that suggest they're not meant to be exported. What is the correct understanding? I can submit a patch to the manual once I understand this myself. - For very short code snippets (1-2 lines), it would be good to allow specifying (via properties) a default language for code blocks (say C) and a prefix character (say ''), after which one could write int i; and have this be the equivalent of +BEGIN_SRC c int i; +END_SRC by analogy with short literal examples : such as this Would this break any Org invariants? (Context: trying to use Org for literate programming in C++; interested in others' experience in this area). Thanks, Ilya
[O] [PATCH] When computing clock table, remove arbitrary limit on hierarchy depth.
0001-When-computing-clock-table-remove-arbitrary-limit-on.patch Description: Binary data
Re: [O] are super-hidden technical blocks required?
On 8/6/2012 2:16 PM, Allen S. Rout wrote: One common use would be to store the creation last-modification dates of each entry. I've tried various ways of doing it and they all were too obtrusive to use on _every_ entry. Time-stamping of all entries would be extremely useful, just as time-stamping of files is. But I don't want to see the timestamps during normal Org usage. As a user, if your code is decorating my tree, I want to know it. If you hide it, I'd be mad. Org is my life in plain text, not WordPerfect with reveal-codes. For decorations that change behavior, e.g. export options or inherited properties, sure. But meta-information such as creation/modification times or unique node ids, which do not change behavior and are known to be associated with every node, displaying them is a distraction. If you already know that every node has a creation time, what is added by seeing a :PROPERTIES: line for that node? If anything, it obscures nodes that do have unique properties you want to know about.
Re: [O] are super-hidden technical blocks required?
On 8/2/2012 11:10 AM, Bastien wrote: If the whole point is to make some properties less visible, why not a solution based on fontification? We could have a user-defined regexp to highlight (or dim) certain properties. That would still leave the :PROPERTIES: line visible, which is problem for universal properties assigned to every entry. I don't believe in a solution that would change the current flow of cycling through drawers. I feel that's too much. I agree. Showing hidden drawers is a rarely-used operation and should be a separate command, not part of the commonly-used cycling.
Re: [O] are super-hidden technical blocks required?
On Mon, Aug 6, 2012 at 8:12 AM, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com wrote: The issue I can see with completely hiding :PROPERTIES: line is that you would then run the risk of adding text at the wrong location (between the headline and the drawer for example). At the moment when the drawer is folded you know if the point is before, within or after the drawer (even though you still can remove parts of :end: by accident with backspaces), if it isn't visible at all you don't have that ability. Maybe, Org should allow text between the headline and the drawer? Is there a reason not to? Alternately, if a UNIVERSAL_PROPERTIES drawer was always on the line immediately following the headline, there would be no way to place text between it and the headilne. Also, maybe a hidden drawer could be protected by setting character properties on it to make it unmodifiable?
Re: [O] are super-hidden technical blocks required?
On 8/5/2012 5:16 AM, Bastien wrote: Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: But I don't want to see the timestamps during normal Org usage. What do you think of hiding them by having a new face for properties matching a custom regexp? This has the advantage of letting the user decide what to do with such properties: either hiding or highlighting them. This is also easier to implement. Then _every_ entry will still have a PROPERTIES drawer. The problem wasn't what's in the drawer (which you hardly ever open), but having to see (and step around) that PROPERTIES line on every entry. What about a HIDDEN_PROPERTIES drawer that, when folded, folds completely (so that its title line is hidden too), and have a key to reveal such drawers (the way M-tab opens archived entries)?
Re: [O] are super-hidden technical blocks required?
On Sun, Aug 5, 2012 at 6:20 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: What about a HIDDEN_PROPERTIES drawer that, when folded, folds completely (so that its title line is hidden too), and have a key to reveal such drawers (the way M-tab opens archived entries)? This is begging for problems. At some point, an user will start to notice weird behaviour he cannot explain from, let's say, the exporter, because he will have completely forgotten about one totally hidden drawer setting export options. I don't think anything should be made totally invisible. There should always be visual clues for such things. But if _every_ entry has a visible PROPERTIES drawer (because a creation and last-modification dates of the entry are stored there), then entries for which custom export options were set no longer stand out. Just as, if you BOLD every word in a document, BOLD no longer acts as a highlight. So, I agree that unique customizations should lead to a visible indicator. But for properties that aren't really customizations ( creation date, modification date, unique ID ), a visible indicator only clutters things without acting as a useful highlight. So, what about making a UNIVERSAL_PROPERTIES drawer that is normally completely hidden, unless you explicitly reveal it?
Re: [O] are super-hidden technical blocks required?
On Sun, Aug 5, 2012 at 10:46 PM, Torsten Wagner torsten.wag...@gmail.com wrote: I can see the point that the property drawer header can be annoying too. Actually, when I used orgmobile for the first time I was not too happy to see all this property drawers suddenly appearing in my files. Alternatively to a new kind of drawer, I would think of the HIDDEN_PROP: line and an additional method which hides a drawer even more if it only contains hidden property elements. That could be done, for example, by the already mentioned custom face. That is, a drawer is clearly visible if it contains properties intend to be read/changed by the user (not marked invisible). A drawer is less visible, if it contains only properties marked as hidden. That would be great. Except, if a PROPERTIES drawer holds only hidden properties, it would be best to completely hide the :PROPERTIES: line (using outline-flag-region), rather than display it in a dimmed font. So that, unless you explicitly ask to reveal these lines, you edit the file as if they weren't there.
Re: [O] are super-hidden technical blocks required?
On 7/31/2012 9:23 AM, Robert Horn wrote: I agree. The real use needs more clarification. Things like ID are already well hidden as :PROPERTIES: until the user explicitly opens the drawer for viewing. I don't understand the need to hide those further, so a better explanation of why is needed. One common use would be to store the creation last-modification dates of each entry. I've tried various ways of doing it and they all were too obtrusive to use on _every_ entry. Time-stamping of all entries would be extremely useful, just as time-stamping of files is. But I don't want to see the timestamps during normal Org usage.
[O] syntax highlighting of inline LaTeX fragments
dear org-moders,
is it possible to syntax-highlight inline LaTeX fragments,
such as $V$ or \cite{smith2012generating} ?
I know you can highlight LaTeX code blocks, but I'm looking specifically
for highlighting of inline fragments.
thanks for help,
ilya
[O] [babel] using babel for regression testing
Is there a babel command to do the following: evaluate all code blocks; for those for which the result is not yet recorded in the org file, record the result; for those for which the result was already recorded, compare the new result with the old result; flag blocks where there is a difference. thanks, ilya
[O] [PATCH] Time specifications: Allow specifying relative times
When specifying times in the tags/properties matcher you can use relative time notation, such as yesterday or -1w. This patch allows this to be used in other places, such as the :tstart and :tend parameters of clocktable. Btw, I couldn't quite understand the exact meaning of :block, :tstart and :tend as decribed in the manual. Is there a better explanation somewhere? thanks, ilya From d19778b3fc624e14237d69cc76a4aa9cb8450697 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 30 Mar 2012 21:19:12 -0400 Subject: [PATCH] Time specifications: Allow specifying relative times * org.el (org-parse-time-string): Allow strings supported by tags/properties matcher (eg now, yesterday, -7d) if the time starts with and ends with . This means that e.g. in the clocktable parameters you can specify :tstart -1w :tend now. TINYCHANGE --- lisp/org.el | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4d2ae87..995dffd 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16016,16 +16016,19 @@ When SHOW-ALL is nil, only return the current occurrence of a time stamp. This should be a lot faster than the normal `parse-time-string'. If time is not given, defaults to 0:00. However, with optional NODEFAULT, hour and minute fields will be nil if not given. - (if (string-match org-ts-regexp0 s) - (list 0 - (if (or (match-beginning 8) (not nodefault)) - (string-to-number (or (match-string 8 s) 0))) - (if (or (match-beginning 7) (not nodefault)) - (string-to-number (or (match-string 7 s) 0))) - (string-to-number (match-string 4 s)) - (string-to-number (match-string 3 s)) - (string-to-number (match-string 2 s)) - nil nil nil) + (cond + ((string-match ^.+$ s) +(decode-time (seconds-to-time (org-matcher-time s + ((string-match org-ts-regexp0 s) +(list 0 + (if (or (match-beginning 8) (not nodefault)) + (string-to-number (or (match-string 8 s) 0))) + (if (or (match-beginning 7) (not nodefault)) + (string-to-number (or (match-string 7 s) 0))) + (string-to-number (match-string 4 s)) + (string-to-number (match-string 3 s)) + (string-to-number (match-string 2 s)) + nil nil nil)) (error Not a standard Org-mode time string: %s s))) (defun org-timestamp-up (optional arg) -- 1.7.9.3
[O] [PATCH] Testing: Corrected the command to run batch tests given in testing/README
Added some details for how to run the test suite in batch mode. From 2cf6b6f529748a2a39927ccfdfa583d7f00cc9df Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 30 Mar 2012 22:11:22 -0400 Subject: [PATCH] Testing: Corrected the command to run batch tests given in README testing/README (running batch tests): Added missing paths to the command. Make sure to load the org-mode code from the git checkout rather than whatever Org is installed in Emacs directories. TINYCHANGE --- testing/README | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/testing/README b/testing/README index 4a68174..f4253c7 100644 --- a/testing/README +++ b/testing/README @@ -12,10 +12,13 @@ repository]]. The simplest way to run the Org-mode test suite is from the command line with the following invocation. Note that the paths below are relative to the base of the Org-mode directory. -#+BEGIN_SRC sh - emacs -Q --batch -l lisp/org.el -l testing/org-test.el \ - --eval (progn (org-reload) (setq org-confirm-babel-evaluate nil)) \ - -f org-test-run-batch-tests +#+BEGIN_SRC sh :dir (expand-file-name ..) + # For Emacs earlier than 24, add -L /path/to/ert + emacs -Q --batch \ +-L lisp/ -L testing/ -L testing/lisp -l lisp/org.el \ +-l lisp/org-id.el -l testing/org-test.el \ +--eval (progn (org-reload) (setq org-confirm-babel-evaluate nil)) \ +-f org-test-run-batch-tests #+END_SRC The options in the above command are explained below. -- 1.7.9.3
Re: [O] org-log-note-headings 'state
On 3/27/2012 9:49 PM, John J Foerch wrote: These thoughts lead me to suggest that maybe org-log-note-headings is no longer sufficient to its original purpose, because extensions wish to parse state changes, but that blocks users from configuring the formats. Perhaps it is time to replace it with something that guarantees ability to parse. I have been experimenting with parsing the format-string to build a regexp to match the generated-strings. This approach depends upon the parsability of the expansions of each of the percent-codes. As concerns org-log-note-headings, %t, %T, %d, %D, %s, %S, and %u all have parseable expansions, as far as I can tell. I'm not sure about %U, but if the rest of the string is not too complicated, it shouldn't be a problem. Format-code flag, width, and precision add some complexity to the problem of generating regexps to match the codes, and I haven't done that bit yet. Overall I think this could be a very viable approach, and I'll paste my scraps of code below: ;;; parsing state changes ;;; Thanks a lot -- I also need the ability to parse state changes for an extension I am writing. It'll be very useful if you could post the final working version of your patch for this. thanks, ilya
[O] [PATCH] Deleting properties: Fixed bug that left blank lines after, deleting properties
Patch for a bug that left blank lines in property drawer after org-delete-property-globally. From 41cbd6302e5a58ed09ec80436237c3c2f4ad8514 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Thu, 29 Mar 2012 22:31:14 -0400 Subject: [PATCH] Deleting properties: Fixed bug that left blank lines after deleting properties * lisp/org.el (org-delete-property-globally): Fixed a bug that left blank line in place of the property, instead of removing the line. TINYCHANGE --- lisp/org.el |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 4d2ae87..bb9c514 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14715,7 +14715,7 @@ in the current file. (org-re-property property) nil t) (setq cnt (1+ cnt)) - (replace-match )) + (delete-region (match-beginning 0) (1+ (point-at-eol (message Property \%s\ removed from %d entries property cnt) (defvar org-columns-current-fmt-compiled) ; defined in org-colview.el -- 1.7.9.3
Re: [O] org-babel tangling + ascii export
Yes this is possible, see the org argument to the comment header argument http://orgmode.org/manual/comments.html. Right, I saw that, but it has the following limitation: The text is picked from the leading context of the tangled code and is limited by the nearest headline or source block as the case may be. I want all text from the Org file included, not just leading context up to nearest headline. I also want the hierarchical structure of the included text preserved, as done by ASCII export. (E.g. I want to include high-level documentation and description, as goes at the top of an elisp file, and which can be broken into sections/subsections/etc -- not just local documentation before a given code block). Is that possible? thanks, ilya On Mon, Mar 26, 2012 at 7:22 AM, Eric Schulte eric.schu...@gmx.com wrote: Yes this is possible, see the org argument to the comment header argument http://orgmode.org/manual/comments.html. Cheers, Ilya Shlyakhter ilya_...@alum.mit.edu writes: Is it possible to combine org-babel tangling with ASCII export, so that the tangled file would have ALL of the Org-file's content as comments (preserving indentation etc as the ASCII export does), with the code blocks inserted as non-comments? Basically I want to write the program in literate-programming form in Org mode, but be able to export it into an executable form that's independent of Org but still has all the information (not just the text immediately before each code block). Thanks for help, ilya -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] org-babel tangling + ascii export
The text is picked from the leading context of the tangled code and is
limited by the nearest headline or source block as the case may be.
I want all text from the Org file included, not just leading context up to
nearest headline.
The above text means per code block, so the entire file is exported.
I also want the hierarchical structure of the included text preserved,
as done by ASCII export.
Please try to tangle the attached file, I believe it is what you want.
Not quite: in the file you sent, This is a the top of an Org-mode
file. is not included in the tangled file. Also, in the slightly
expanded version of your example I'm attaching, the high-level comments
at the top of the file are not included. Also, when I nest another
headline inside Headline 1, only the content of that headline --
not of Headline 1 -- is included.
I'm attaching the current result of tangling, as well as what I ideally
want. example-idea.el was produced by doing an ASCII export, then
commenting everything in it except the code blocks. The resulting file
is both fully executable and contains everything from the original org
file, so it stands on its own and is independent of Emacs/Org.
Thanks for help,
ilya
#+Property: comments both
#+Property: tangle example.el
This is a the top of an Org-mode file.
* This is some high-level documentation
This file does X and Y.
*** Section A
High-level documentation for functionality A.
*** Section B
High-level documentation for functionality B.
* Headline 1
This is content inside of a headline.
*** And this is the info about the block.
| 1 |
| 2 |
| 3 |
| 4 |
#+begin_src emacs-lisp
(message code block 1)
#+end_src
* Headline 2
This is content inside of a secondary headline.
#+begin_src emacs-lisp
(message code block 1)
#+end_src
;; And this is the info about the block.
;; | 1 |
;; | 2 |
;; | 3 |
;; | 4 |
;;
[[git:/cvar/selection/sweep2/nsvn/Tools/org/devel2/org-mode/something.org::fix-colview-todo-by-itself@{2012-03-26}][And-this-is-the-info-about-the-block\.:1]]
(message code block 1)
;; And-this-is-the-info-about-the-block\.:1 ends here
;; Headline 2
;; This is content inside of a secondary headline.
;;
[[git:/cvar/selection/sweep2/nsvn/Tools/org/devel2/org-mode/something.org::fix-colview-todo-by-itself@{2012-03-26}][Headline-2:1]]
(message code block 1)
;; Headline-2:1 ends here
;; This is a the top of an Org-mode
file.
;;
==
;;
;; Author: Ilya Shlyakhter
;; Date: 2012-03-26 11:50:40 EDT
;;
;;
;;
;; Table of Contents
;; =
;; 1 This is some high-level documentation
;;1.1 Section A
;;1.2 Section B
;; 2 Headline 1
;;2.1 And this is the info about the block.
;; 3 Headline 2
;;
;;
;; 1 This is some high-level documentation
;;
;;
;; This file does X and Y.
;;
;; 1.1 Section A
;; ==
;;
;; High-level documentation for functionality A.
;;
;; 1.2 Section B
;; ==
;;
;; High-level documentation for functionality B.
;;
;; 2 Headline 1
;; -
;;
;; This is content inside of a headline.
;;
;; 2.1 And this is the info about the block.
;; ==
;;
;; 1
;; 2
;; 3
;; 4
(message code block 1)
;; 3 Headline 2
;; -
;; This is content inside of a secondary headline.
(message code block 1)
Re: [O] case sensitivity
On 3/24/2012 2:58 AM, Bastien wrote: How should case-sensitivity work in Org? The documentation doesn't specify. From past messages, it looks like tags and todo keywords are defined to be case-sensitive. What about priorities, categories, user-defined properties, regexp matching of entries, following of links-to-headlines? Other cases? If there is an issue with a syntactic element being case-(in)sensitive while (1) it should not and/or (2) docs suggests otherwise, then let's tackle the problem. Problem is, docs are cleverly silent on the issue :) So for one, it would be good if the docs specified it one way or the other at least in the above cases. But also in the code, case-fold-search is sometimes explicitly set before testing regexps and sometimes isn't. I started fixing this, then realized that there is no spec for the right behavior. So I thought I'd check with the list first. ilya
[O] [PATCH] Colview bugfix: blank headline causes a crash
A blank headline (e.g. with just a TODO keyword) caused a crash when building colview. Patch attached. From 6bb1413821a7cbf94b3abbfc6e985e187dd8d6d9 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Sat, 24 Mar 2012 12:25:59 -0400 Subject: [PATCH] Colview bugfix: A headline with just a TODO keyword and blank headline content would crash * lisp/org-colview.el (org-columns-cleanup-item): Handle case of empty headline * lisp/org-colview-xemacs.el (org-columns-cleanup-item): Handle case of empty headline TINYCHANGE --- lisp/org-colview-xemacs.el |2 +- lisp/org-colview.el|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-colview-xemacs.el b/lisp/org-colview-xemacs.el index ec892fe..b65aa18 100644 --- a/lisp/org-colview-xemacs.el +++ b/lisp/org-colview-xemacs.el @@ -516,7 +516,7 @@ This is the compiled version of the format.) 'org-whitespace (* 2 (1- (org-reduced-level (- (match-end 1) (match-beginning 1)) (and (match-end 2) (not (assoc TODO fmt)) (concat (match-string 2 item))) (and (match-end 3) (not (assoc PRIORITY fmt)) (concat (match-string 3 item))) - (save-match-data (org-columns-compact-links (match-string 4 item))) + (save-match-data (org-columns-compact-links (or (match-string 4 item) ))) (and (match-end 5) (not (assoc TAGS fmt)) (concat (match-string 5 item) (add-text-properties 0 (1+ (match-end 1)) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index 95def1c..fb15880 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -357,7 +357,7 @@ CPHR is the complex heading regexp to use for parsing ITEM. 'org-whitespace (* 2 (1- (org-reduced-level (- (match-end 1) (match-beginning 1)) (and (match-end 2) (not (assoc TODO fmt)) (concat (match-string 2 item))) (and (match-end 3) (not (assoc PRIORITY fmt)) (concat (match-string 3 item))) - (save-match-data (org-columns-compact-links (match-string 4 item))) + (save-match-data (org-columns-compact-links (or (match-string 4 item) ))) (and (match-end 5) (not (assoc TAGS fmt)) (concat (match-string 5 item) (add-text-properties 0 (1+ (match-end 1)) -- 1.7.9.3
[O] case sensitivity
How should case-sensitivity work in Org? The documentation doesn't specify. From past messages, it looks like tags and todo keywords are defined to be case-sensitive. What about priorities, categories, user-defined properties, regexp matching of entries, following of links-to-headlines? Other cases?
[O] org-babel tangling + ascii export
Is it possible to combine org-babel tangling with ASCII export, so that the tangled file would have ALL of the Org-file's content as comments (preserving indentation etc as the ASCII export does), with the code blocks inserted as non-comments? Basically I want to write the program in literate-programming form in Org mode, but be able to export it into an executable form that's independent of Org but still has all the information (not just the text immediately before each code block). Thanks for help, ilya
[O] [PATCH] Tags/properties matcher: Fixed issues with todo-only matches
Patch attached. Original problem was that org-map-entries for MYPROP2/! was not limiting itself to TODO entries, even though org-tags-view for the same matcher was. lisp/org.el (org-scan-tags): Require todo-only argument, and document that it should be the same one set by org-make-tags-matcher. Fix documentation to explain that todo-only is really not-done-todo-only. (org-make-tags-matcher): If todo part of matcher starts with /!, matcher now always checks that the TODO keyword is present and is a not-done state. This matters e.g. for org-map-entries which unlike org-scan-tags does not do its own separate todo-only filtering. Added docs to explain matcher dependencies. (org-map-entries): Make sure todo-only is correctly passed from org-make-tags-matcher to org-scan-tags. * lisp/org-clock.el: (org-clock-get-table-data): Make sure todo-only does not leak when it is set by make-org-tags-macher. * lisp/org-crypt.el: (org-encrypt-entries, org-decrypt-entries): Make sure todo-only is correctly passed from org-make-tags-matcher to org-scan-tags. * contrib/lisp/contacts.el: (org-contacts-filter) : Make sure todo-only is correctly passed from org-make-tags-matcher to org-scan-tags. From 3feb2edd3a705811824348546f4edad2f595f8bb Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Wed, 21 Mar 2012 19:49:07 -0400 Subject: [PATCH] Tags/properties matcher: Fixed issues with todo-only matches lisp/org.el (org-scan-tags): Require todo-only argument, and document that it should be the same one set by org-make-tags-matcher. Fix documentation to explain that todo-only is really not-done-todo-only. (org-make-tags-matcher): If todo part of matcher starts with /!, matcher now always checks that the TODO keyword is present and is a not-done state. This matters e.g. for org-map-entries which unlike org-scan-tags does not do its own separate todo-only filtering. Added docs to explain matcher dependencies. (org-map-entries): Make sure todo-only is correctly passed from org-make-tags-matcher to org-scan-tags. * lisp/org-clock.el: (org-clock-get-table-data): Make sure todo-only does not leak when it is set by make-org-tags-macher. * lisp/org-crypt.el: (org-encrypt-entries, org-decrypt-entries): Make sure todo-only is correctly passed from org-make-tags-matcher to org-scan-tags. * contrib/lisp/contacts.el: (org-contacts-filter) : Make sure todo-only is correctly passed from org-make-tags-matcher to org-scan-tags. --- contrib/lisp/org-contacts.el |6 -- lisp/org-clock.el|1 + lisp/org-crypt.el| 16 +-- lisp/org.el | 44 -- 4 files changed, 49 insertions(+), 18 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index bdd9996..b6d9e50 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -143,7 +143,8 @@ This overrides `org-email-link-description-format' if set. (defun org-contacts-filter (optional name-match tags-match) Search for a contact maching NAME-MATCH and TAGS-MATCH. If both match values are nil, return all contacts. - (let ((tags-matcher + (let* (todo-only + (tags-matcher (if tags-match (cdr (org-make-tags-matcher tags-match)) t)) @@ -161,7 +162,8 @@ If both match values are nil, return all contacts. (error File %s is no in `org-mode' file)) (org-scan-tags '(add-to-list 'markers (set-marker (make-marker) (point))) - `(and ,contacts-matcher ,tags-matcher ,name-matcher + `(and ,contacts-matcher ,tags-matcher ,name-matcher) +todo-only))) (dolist (marker markers result) (org-with-point-at marker (add-to-list 'result diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 46d9af8..5fca941 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2441,6 +2441,7 @@ TIME: The sum of all time spend in this tree, in minutes. This time (tags (plist-get params :tags)) (properties (plist-get params :properties)) (inherit-property-p (plist-get params :inherit-props)) +todo-only (matcher (if tags (cdr (org-make-tags-matcher tags cc range-text st p time level hdl props tsp tbl) diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el index f60c61e..7e7ba30 100644 --- a/lisp/org-crypt.el +++ b/lisp/org-crypt.el @@ -237,16 +237,20 @@ See `org-crypt-disable-auto-save'. (defun org-encrypt-entries () Encrypt all top-level entries in the current buffer. (interactive) - (org-scan-tags - 'org-encrypt-entry - (cdr (org-make-tags-matcher org-crypt-tag-matcher + (let (todo-only) +(org-scan-tags + 'org-encrypt-entry + (cdr (org-make-tags-matcher org-crypt-tag-matcher)) + todo-only))) (defun org-decrypt-entries () Decrypt all entries in the current buffer. (interactive) - (org-scan-tags - 'org-decrypt-entry - (cdr
Re: [O] [PATCH] tags search: faster tags matcher by trusting scanner tags
On 3/16/2012 2:10 AM, Nick Dokos wrote: One more thing that you'll need to do is put your patches in attachments of a type that will allow patchwork to snag the patch: Thanks, I was wondering why they're not showing up. Here is another try (attached) for the org.el patch. ilya From 95c38b06803aec0787bc2eaab3d0062221390292 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 16 Mar 2012 00:10:25 -0400 Subject: [PATCH 2/2] Tags/properties matcher: faster matching by trusting org-scanner-tags * lisp/org.el (org-scan-tags): Bind org-trust-scanner-tags to t while evaluating the matcher, since the matcher is always evaluated at the current entry. TINYCHANGE --- lisp/org.el |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index ad63213..951f692 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12906,7 +12906,8 @@ headlines matching this string. ;; eval matcher only when the todo condition is OK (and (or (not todo-only) (member todo org-not-done-keywords)) - (let ((case-fold-search t)) (eval matcher))) + (let ((case-fold-search t) (org-trust-scanner-tags t)) + (eval matcher))) ;; Call the skipper, but return t if it does not skip, ;; so that the `and' form continues evaluating -- 1.7.9.3
Re: [O] [PATCH] tags search: faster tags matcher by trusting scanner tags
On 3/16/2012 2:10 AM, Nick Dokos wrote: One more thing that you'll need to do is put your patches in attachments of a type that will allow patchwork to snag the patch: And here is the org-clock.el patch again. From 4f7f91ae62d425f7a89738b28006b1743a6bea4d Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 16 Mar 2012 00:25:18 -0400 Subject: [PATCH 3/3] Clocking work time: faster filtering of clock entries by trusting org-scanner-tags * lisp/org-clock.el (org-clock-get-table-data): Bind org-scanner-tags to tags-list and org-trust-scanner-tags to t while evaluating the matcher, since the matcher is always evaluated at the current entry. TINYCHANGE --- lisp/org-clock.el |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 9206608..46d9af8 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2463,7 +2463,9 @@ TIME: The sum of all time spend in this tree, in minutes. This time (org-clock-sum ts te (unless (null matcher) (lambda () -(let ((tags-list (org-get-tags-at))) +(let* ((tags-list (org-get-tags-at)) + (org-scanner-tags tags-list) + (org-trust-scanner-tags t)) (eval matcher) (goto-char (point-min)) (setq st t) -- 1.7.9.3
[O] [PATCH] Fixed compiler warnings including one small bug in ob-lilypond
Re-sending the patch as a correct attachment type. One of the warnings indicated an actual (small) bug. From d0579b6e104b82ec7d3255086384ff8dee0d4e0e Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 16 Mar 2012 01:52:03 -0400 Subject: [PATCH] Fixed compiler warnings, including one small bug in ob-lilypond * lisp/ob-lilypond.el (ly-compile-lilyfile): Fixed misplaced comma in a quoting expression. * lisp/org-pcomplete.el: added missing defvar definitions for org vars * lisp/org-src.el: added declare-function line for org-babel-tangle * lisp/ob.el (org-scan-tags): protected the variable tags-list with a let (other) added missing defvar declarations. TINYCHANGE --- lisp/ob-lilypond.el |2 +- lisp/org-pcomplete.el |5 + lisp/org-src.el |2 ++ lisp/org.el |9 +++-- 4 files changed, 15 insertions(+), 3 deletions(-) diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el index a008b2d..0e9b0c6 100644 --- a/lisp/ob-lilypond.el +++ b/lisp/ob-lilypond.el @@ -223,7 +223,7 @@ FILE-NAME is full path to lilypond (.ly) file (arg-11 file-name)) (if test `(,arg-1 ,arg-2 ,arg-3 ,arg-4 ,arg-5 ,arg-6 - ,arg-7 ,arg-8 ,arg-9 ,arg-10, arg-11) + ,arg-7 ,arg-8 ,arg-9 ,arg-10 ,arg-11) (call-process arg-1 arg-2 arg-3 arg-4 arg-5 arg-6 arg-7 arg-8 arg-9 arg-10 arg-11 diff --git a/lisp/org-pcomplete.el b/lisp/org-pcomplete.el index c475bcc..7a4dc0d 100644 --- a/lisp/org-pcomplete.el +++ b/lisp/org-pcomplete.el @@ -50,6 +50,9 @@ :tag Org :group 'org) +(defvar org-drawer-regexp) +(defvar org-property-re) + (defun org-thing-at-point () Examine the thing at point and let the caller know what it is. The return value is a string naming the thing at point. @@ -247,6 +250,8 @@ This needs more work, to handle headings with lots of spaces in them. lst)) (substring pcomplete-stub 1))) +(defvar org-drawers) + (defun pcomplete/org-mode/drawer () Complete a drawer name. (let ((spc (save-excursion diff --git a/lisp/org-src.el b/lisp/org-src.el index 88217cd..cc5a6ca 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -686,6 +686,8 @@ the language, a switch telling if the content should be in a single line. (interactive) (org-src-in-org-buffer (save-buffer))) +(declare-function org-babel-tangle ob-tangle (optional only-this-block target-file lang)) + (defun org-src-tangle (arg) Tangle the parent buffer. (interactive) diff --git a/lisp/org.el b/lisp/org.el index 951f692..7f8eddb 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -76,6 +76,7 @@ (require 'gnus-sum)) (require 'calendar) +(require 'format-spec) ;; Emacs 22 calendar compatibility: Make sure the new variables are available (when (fboundp 'defvaralias) @@ -4930,6 +4931,8 @@ sure that we are at the beginning of the line.) Matches an headline, putting stars and text into groups. Stars are put in group 1 and the trimmed body in group 2.) +(defvar bidi-paragraph-direction) + ;;;###autoload (define-derived-mode org-mode outline-mode Org Outline-based notes management and organizer, alias @@ -12854,7 +12857,7 @@ headlines matching this string. (buffer-name (buffer-base-buffer))) (case-fold-search nil) (org-map-continue-from nil) - lspos tags + lspos tags tags-list (tags-alist (list (cons 0 org-file-tags))) (llast 0) rtn rtn1 level category i txt todo marker entry priority) @@ -14986,6 +14989,7 @@ So these are more for recording a certain time/date. (defvar org-read-date-final-answer nil) (defvar org-read-date-analyze-futurep nil) (defvar org-read-date-analyze-forced-year nil) +(defvar org-read-date-inactive) (defun org-read-date (optional with-time to-time from-string prompt default-time default-input inactive) @@ -15185,7 +15189,6 @@ user. (defvar def) (defvar defdecode) (defvar with-time) -(defvar org-read-date-inactive) (defun org-read-date-display () Display the current date prompt interpretation in the minibuffer. (when org-read-date-display-live @@ -17008,6 +17011,8 @@ Some of the options can be changed using the variable (error Unknown conversion type %s for latex fragments processing-type) +(declare-function format-spec format-spec (format specification)) + (defun org-create-math-formula (latex-frag optional mathml-file) Convert LATEX-FRAG to MathML and store it in MATHML-FILE. Use `org-latex-to-mathml-convert-command'. If the conversion is -- 1.7.9.3
[O] [PATCH] documentation patch clarifying ITEM special property
Documentation patch clarifying that ITEM refers to the headline not the
contents of an entry, and that it currently isn't supported for
tags/property searchers. Added a footnote pointing to a partial
workaround using org-agenda-skip-entry-if.
From 33ccb4f2d3dc352e54c18b7bb88b1be90f6067cf Mon Sep 17 00:00:00 2001
From: Ilya Shlyakhter ilya_...@alum.mit.edu
Date: Fri, 16 Mar 2012 17:33:36 -0400
Subject: [PATCH 2/2] Documentation: Clarified current role of ITEM special
property
doc/org.texi (section on Special Properties) Clarified that ITEM refers
to the headline of the entry not the whole entry text.
(section on Matching Tags and Properties) Clarified that matching on
the value of ITEM special property is not currently supported,
and added a footnote about a partial workaround.
Also added missing -if suffix to references to org-agenda-skip-entry-if.
TINYCHANGE
---
doc/org.texi | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 181ccd9..2c6168a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -4953,7 +4953,7 @@ TIMESTAMP_IA @r{The first inactive timestamp in the
entry.}
CLOCKSUM @r{The sum of CLOCK intervals in the subtree.
@code{org-clock-sum}}
@r{must be run first to compute the values in the current buffer.}
BLOCKED @r{t if task is currently blocked by children or siblings}
-ITEM @r{The content of the entry.}
+ITEM @r{The headline of the entry.}
FILE @r{The filename the entry is located in.}
@end example
@@ -7536,6 +7536,9 @@ So a search @samp{+LEVEL=3+boss-TODO=DONE} lists all
level three headlines
that have the tag @samp{boss} and are @emph{not} marked with the TODO keyword
DONE. In buffers with @code{org-odd-levels-only} set, @samp{LEVEL} does not
count the number of stars, but @samp{LEVEL=2} will correspond to 3 stars etc.
+The ITEM special property cannot currently be used in tags/property
+searches@footnote{But @pxref{x-agenda-skip-entry-regexp,
+,skipping entries based on regexp}.}.
Here are more examples:
@table @samp
@@ -15876,9 +15879,10 @@ Skip current entry if the TODO keyword is TODO or
WAITING.
Skip current entry if the TODO keyword marks a DONE state.
@item (org-agenda-skip-entry-if 'timestamp)
Skip current entry if it has any timestamp, may also be deadline or scheduled.
-@item (org-agenda-skip-entry 'regexp regular expression)
+@anchor{x-agenda-skip-entry-regexp}
+@item (org-agenda-skip-entry-if 'regexp regular expression)
Skip current entry if the regular expression matches in the entry.
-@item (org-agenda-skip-entry 'notregexp regular expression)
+@item (org-agenda-skip-entry-if 'notregexp regular expression)
Skip current entry unless the regular expression matches.
@item (org-agenda-skip-subtree-if 'regexp regular expression)
Same as above, but check and skip the entire subtree.
--
1.7.9.3
[O] [PATCH] tags search: faster tags matcher by trusting scanner tags
The attached patch speeds up tags matching ( 50s -- 5s for my most common search ), by turning on org-trust-scanner-tags within the matcher. (When it's off, getting a non-inherited property's value causes a call to org-entry-properties to fetch all properties into a cache, including ALLTAGS; fetching ALLTAGS involves calling (org-get-tags-at), which is slow when org-trust-scanner-tags is off.) Can this cause problems / was this off for a reason? thanks, ilya 0022-Tags-matcher-turned-on-org-trust-scanner-tags-within.patch Description: Binary data
Re: [O] [PATCH] tags search: faster tags matcher by trusting scanner tags
, | If your function needs to retrieve the tags including inherited tags | at the *current* entry, 'Function' here refers to the FUNC parameter of org-map-entries, not the MATCHER parameter. The matcher is constructed by org-make-tags-matcher, so we know everything it does -- it does not move around and only asks about the current entry's tags and properties. org-scan-tags only invokes the matcher at the current entry, and sets org-scanner-tags correctly for that call. But, you're right that there is a problem: while org-scan-tags sets org-scanner-tags correctly before (eval matcher), other users of the matcher -- e.g. org-clock-get-table-data -- might not. So, org-trust-scanner-tags should be set not in the matcher, but in the function that calls the matcher. A corrected patch is attached. thanks, ilya On Thu, Mar 15, 2012 at 11:13 PM, Nick Dokos nicholas.do...@hp.com wrote: Ilya Shlyakhter ilya_...@alum.mit.edu wrote: The attached patch speeds up tags matching ( 50s -- 5s for my most common search ), by turning on org-trust-scanner-tags within the matcher. (When it's off, getting a non-inherited property's value causes a call to org-entry-properties to fetch all properties into a cache, including ALLTAGS; fetching ALLTAGS involves calling (org-get-tags-at), which is slow when org-trust-scanner-tags is off.) Can this cause problems / was this off for a reason? I haven't looked at your patch carefully enough to know if it will or will not cause problems, but check the doc for org-map-entries: it has some guidelines about where the technique can be used and where it cannot: , | If your function needs to retrieve the tags including inherited tags | at the *current* entry, you can use the value of the variable | `org-scanner-tags' which will be much faster than getting the value | with `org-get-tags-at'. If your function gets properties with | `org-entry-properties' at the *current* entry, bind `org-trust-scanner-tags' | to t around the call to `org-entry-properties' to get the same speedup. | Note that if your function moves around to retrieve tags and properties at | a *different* entry, you cannot use these techniques. ` There are warnings that this variable is for internal dynamical scoping only, so I suspect you should not mess with the default. If your search can make the needed guarantees, then you can just wrap it in a let to get the speedup. Otherwise, it probably should be left alone. Nick 0002-Tags-properties-matcher-faster-matching-by-trusting-.patch Description: Binary data
Re: [O] [PATCH] tags search: faster tags matcher by trusting scanner tags
Here is a similar patch for org-clock's use of tags/properties matcher. On Fri, Mar 16, 2012 at 12:31 AM, Ilya Shlyakhter ilya_...@alum.mit.eduwrote: , | If your function needs to retrieve the tags including inherited tags | at the *current* entry, 'Function' here refers to the FUNC parameter of org-map-entries, not the MATCHER parameter. The matcher is constructed by org-make-tags-matcher, so we know everything it does -- it does not move around and only asks about the current entry's tags and properties. org-scan-tags only invokes the matcher at the current entry, and sets org-scanner-tags correctly for that call. But, you're right that there is a problem: while org-scan-tags sets org-scanner-tags correctly before (eval matcher), other users of the matcher -- e.g. org-clock-get-table-data -- might not. So, org-trust-scanner-tags should be set not in the matcher, but in the function that calls the matcher. A corrected patch is attached. thanks, ilya On Thu, Mar 15, 2012 at 11:13 PM, Nick Dokos nicholas.do...@hp.comwrote: Ilya Shlyakhter ilya_...@alum.mit.edu wrote: The attached patch speeds up tags matching ( 50s -- 5s for my most common search ), by turning on org-trust-scanner-tags within the matcher. (When it's off, getting a non-inherited property's value causes a call to org-entry-properties to fetch all properties into a cache, including ALLTAGS; fetching ALLTAGS involves calling (org-get-tags-at), which is slow when org-trust-scanner-tags is off.) Can this cause problems / was this off for a reason? I haven't looked at your patch carefully enough to know if it will or will not cause problems, but check the doc for org-map-entries: it has some guidelines about where the technique can be used and where it cannot: , | If your function needs to retrieve the tags including inherited tags | at the *current* entry, you can use the value of the variable | `org-scanner-tags' which will be much faster than getting the value | with `org-get-tags-at'. If your function gets properties with | `org-entry-properties' at the *current* entry, bind `org-trust-scanner-tags' | to t around the call to `org-entry-properties' to get the same speedup. | Note that if your function moves around to retrieve tags and properties at | a *different* entry, you cannot use these techniques. ` There are warnings that this variable is for internal dynamical scoping only, so I suspect you should not mess with the default. If your search can make the needed guarantees, then you can just wrap it in a let to get the speedup. Otherwise, it probably should be left alone. Nick 0003-Clocking-work-time-faster-filtering-of-clock-entries.patch Description: Binary data
[O] [PATCH] Fixed compiler warnings including typo in ob-lilypond
Fixed compiler warnings, including one typo in ob-lilypond * lisp/ob-lilypond.el (ly-compile-lilyfile): Fixed misplaced comma in a quoting expression. * lisp/org-pcomplete.el: added missing defvar definitions for org vars * lisp/org-src.el: added declare-function line for org-babel-tangle * lisp/ob.el (org-scan-tags): protected the variable tags-list with a let (other) added missing defvar declarations. 0001-Fixed-compiler-warnings-including-one-typo-in-ob-lil.patch Description: Binary data
[O] ITEM special property
Is the following correct: - the ITEM special property returns the _headline_ of an entry (not the content); - ITEM can't be used in tag/match queries, only in column view formats. thanks, ilya
Re: [O] suggestion for the manual: mention the #+BEGIN_SRC org trick when describing drawers and plainlists
On 3/8/2012 2:32 AM, Sebastien Vauban wrote: In Org, entry text can't have substructure (other than drawers and plain lists): you can't have an entry that has some text, then a subtree, then more text. Take a look at inline tasks. I think that's more what you're after... Thanks -- looked at inline tasks and at http://orgmode.org/worg/org-faq.html#closing-outline-sections but that's not quite what I want. I really do want a nested org -- something like a drawer or a plainlist, which is fully part of the entry and can be org-cycled but has substructure. Inline tasks do not nest. Using #+BEGIN_SRC org / #+END_SRC does exactly what I want during editing -- lets me enter a side note that can be easily folded away (like a drawer), is completely within the entry (unlike solutions from org-faq that add extra headlines), can have substructure (like plain lists) but is a full-featured org without plainlists' limitations. Two problems with this so far: - org-store-link does not work when editing this nested org block under C-' . Ideally, it would store a link that when followed would open this source block for editing in its native org-mode (as with C-') and then find the link within that. - when exporting to HTML, I want to run the HTML exporter on the nested org buffer and insert its results -- rather than inserting a boxed version of the Org source. (This boxed version shows the hidden asterisks in outlines, and its colors do not quite match the ones in the Emacs buffer, among other things.) thanks for help, ilya
Re: [O] suggestion for the manual: mention the #+BEGIN_SRC org trick when describing drawers and plainlists
On 3/8/2012 7:53 AM, Ilya Shlyakhter wrote: - when exporting to HTML, I want to run the HTML exporter on the nested org buffer and insert its results -- rather than inserting a boxed version of the Org source. p.s. one solution could be to run the HTML exporter on the nested org and show the result inside an IFRAME within the main org's HTML export.
[O] [PATCH] imenu: Added a check that looking-at succeeds before using the match results.
* lisp/org.el (org-imenu-get-tree): Check that looking-at succeeds before using match results. TINYCHANGE --- lisp/org.el |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ad63213..e4fb497 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21250,8 +21250,8 @@ Show the heading too, if it is currently invisible. (goto-char (point-max)) (while (re-search-backward re nil t) (setq level (org-reduced-level (funcall outline-level))) - (when (= level n) - (looking-at org-complex-heading-regexp) + (when (and (= level n) +(looking-at org-complex-heading-regexp)) (setq head (org-link-display-format (org-match-string-no-properties 4)) m (org-imenu-new-marker)) -- 1.7.9.3
Re: [O] [PATCH] imenu: Added a check that looking-at succeeds before using the match results.
On 3/8/2012 2:39 PM, Achim Gratz wrote: Your patch got completely mangled, try again as an attachment of type (text/plain). here, also at http://ilya.cc/imenu.patch From e3e6e7135663fb34a5318565e5663dd27fa7ce45 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Thu, 8 Mar 2012 14:15:12 -0500 Subject: [PATCH] imenu: Added a check that looking-at succeeds before using the match results. * lisp/org.el (org-imenu-get-tree): Check that looking-at succeeds before using match results. TINYCHANGE --- lisp/org.el |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ad63213..e4fb497 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21250,8 +21250,8 @@ Show the heading too, if it is currently invisible. (goto-char (point-max)) (while (re-search-backward re nil t) (setq level (org-reduced-level (funcall outline-level))) - (when (= level n) - (looking-at org-complex-heading-regexp) + (when (and (= level n) +(looking-at org-complex-heading-regexp)) (setq head (org-link-display-format (org-match-string-no-properties 4)) m (org-imenu-new-marker)) -- 1.7.9.3
[O] [PATCH] org-store-link: Fixed a bug where source block edit buffers were not recognized
attached. From 134c2ba772081ee7ca356b0dcabeb131bcb41b3b Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Thu, 8 Mar 2012 17:25:18 -0500 Subject: [PATCH 2/2] org-store-link: Fixed a bug where source block edit buffers were not recognized * lisp/org.el (org-store-link): Use a new predicate from org-src.el to test whether we're in a source block edit buffer. * lisp/org-src.el (org-src-edit-buffer-p): New predicate to tell if we're in a source block edit buffer. TINYCHANGE --- lisp/org-src.el |9 + lisp/org.el |2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 9cd56d2..e08fe89 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -374,6 +374,15 @@ buffer. Construct the buffer name for a source editing buffer. (concat *Org Src org-buffer-name [ lang ]*)) +(defun org-src-edit-buffer-p (optional buffer) + Test whether BUFFER (or the current buffer if BUFFER is nil) +is a source block editing buffer. + (let ((buffer (org-base-buffer (or buffer (current-buffer) +(and (buffer-name buffer) +(string-match \\`*Org Src (buffer-name buffer)) +(local-variable-p 'org-edit-src-beg-marker buffer) +(local-variable-p 'org-edit-src-end-marker buffer + (defun org-edit-src-find-buffer (beg end) Find a source editing buffer that is already editing the region BEG to END. (catch 'exit diff --git a/lisp/org.el b/lisp/org.el index e4fb497..6074a01 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8684,7 +8684,7 @@ For file links, arg negates `org-context-in-file-links'. (setq link (plist-get org-store-link-plist :link) desc (or (plist-get org-store-link-plist :description) link))) - ((equal (buffer-name) *Org Edit Src Example*) + ((org-src-edit-buffer-p) (let (label gc) (while (or (not label) (save-excursion -- 1.7.9.3
[O] suggestion for the manual: mention the #+BEGIN_SRC org trick when describing drawers and plainlists
In Org, entry text can't have substructure (other than drawers and plain lists): you can't have an entry that has some text, then a subtree, then more text. I just (re-)discovered that you can get around that by using #+BEGIN_SRC org to include arbitrary org subtrees in the middle of entry text. That's useful not just when writing in Org about Org, but anytime you want to insert an extended sidenote in the middle of an entry. As with all source blocks, you edit it in its native (Org) mode and it exports correctly. You can copy links from the main Org and past them into the nested Org. Just wish I'd learned this sooner :) So, maybe mention this in the manual in the sections on drawers and plainlists. ilya
Re: [O] suggestion for the manual: mention the #+BEGIN_SRC org trick when describing drawers and plainlists
p.s. it _would_ be good to have an option, when exporting a #+BEGIN_SRC org block, to use the Org export settings from the main Org file, rather than exporting a fontified copy of the Org buffer for the block. Is there a way to do that currently? On Wed, Mar 7, 2012 at 8:13 PM, Ilya Shlyakhter ilya_...@alum.mit.eduwrote: In Org, entry text can't have substructure (other than drawers and plain lists): you can't have an entry that has some text, then a subtree, then more text. I just (re-)discovered that you can get around that by using #+BEGIN_SRC org to include arbitrary org subtrees in the middle of entry text. That's useful not just when writing in Org about Org, but anytime you want to insert an extended sidenote in the middle of an entry. As with all source blocks, you edit it in its native (Org) mode and it exports correctly. You can copy links from the main Org and past them into the nested Org. Just wish I'd learned this sooner :) So, maybe mention this in the manual in the sections on drawers and plainlists. ilya
[O] suggestion: sparse tree heatmaps
Suggestion: Currently, the sparse tree shows entries in proper context but not in order (e.g. by due date); the agenda shows them in order but out of context. To get both, show a sparse tree but indicate the relative order of the entries by a heatmap color (e.g. blue to red) that would correspond to the entry's position in the corresponding agenda.
[O] bug report: org-delete-property-globally
org-delete-property-globally leaves a blank line in place of each property line it deletes. (by contrast, org-delete-property correctly removes the property line).
[O] bug report: org-imenu-get-tree
In org-imenu-get-tree, (when (= level n) (looking-at org-complex-heading-regexp) (setq head (org-link-display-format (org-match-string-no-properties 4)) m (org-imenu-new-marker)) should probably be (when (and (= level n) (looking-at org-complex-heading-regexp)) (setq head (org-link-display-format (org-match-string-no-properties 4)) m (org-imenu-new-marker)) ... i had an headling which (accidentally) consisted of just a todo keyword, making (org-match-string-no-properties 4) nil.
[O] bug report: agenda timeline crashes
In the head revision, if the org file has headlines that start with a timestamp, the command to create a timeline of the file (C-a L) crashes. * things *** 2011-10-06 Thu 22:24 some text mapcar: Args out of range: #( 0 2 (org-category mt3 tags nil org-highest-priority 65 org-lowest-priority 69 time-of-day 2224 ...)), 0, 37 thanks, ilya
Re: [Orgmode] org-scan-tags
Thanks for catching this, Carsten! This could perhaps be fixed by doing a full lookup of the tags up the hierarchy, rather than relying on the cached tags. This is more expensive, but if fewer entries actually have to be looked at (because the search only stops at TODO entries), it might be faster overall. One general way to speed up searches would be to move as much work as possible into Emacs' built-in regexp matcher. When parsing a search expression, right now it is parsed into an elisp form that is evaluated at each entry and says whether the entry matches. Each clause of a search expression could instead be parsed into an elisp form _and_ a regexp, such that matching the regexp would be a necessary (but not sufficient) condition for the entry to match. E.g. if looking for entries with property PROP equal to 1, you could construct a regexp that would match only that. Some things aren't expressible in regexp language so they'd still have to be checked in lisp. And tag lookups could not use the cache. But if most of the filtering is done by Emacs' regexp matcher, and only a bit of lisp filtering on top of that, overall searches might be faster. On Thu, Feb 3, 2011 at 11:37 AM, Bastien bastien.gue...@wikimedia.fr wrote: Carsten Dominik carsten.domi...@gmail.com writes: OK, here is an example where it really does fail: * heading ** one :tag1: *** two *** two :tag2: *** TODO two :tag2: *** two :tag2: Fold up the tree, then do C-c / m +tag1/! RET This should find the TODO two, but it does not, because the new regexp moves right past the one line and so tag1 is overlooked. Right, thanks for the detailed example. I reverted the commit, it should be fine again. -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: New clocktable code
However, your proposal still sounds abstract - do you have concrete examples in mind? You could see a breakdown of your budget e.g. how much money you've spent on various areas of life in a given period, if you record money spent as a property and immediately CLOSE the entry on the date the money is spent. You could count how many tasks you have closed in each area of your life / for each project its sub-project in a given period, if you make an inherited property with the default value of 1. For harder / more important tasks that are worth several simpler tasks, you could override the default value of the property to be greater than one. You could also filter by kind of task, e.g. if you have unpleasant tasks to do and want to make sure you do at least a few a week, you would include only headlines tagged :unpleasant: in the sum. I'm writing an org-goals package that lets you set check goals of the form, under this subtree, i want to spend at least 3 hours per week or at most 100 dollars per month etc. Being able to view what you've spent in a given period using a clocktable would be a nice complement. ilya p.s. the package isn't ready for release, but if you want to take a peek, it's at http://sourceforge.net/projects/org-balance/ On Tue, Nov 2, 2010 at 6:11 PM, Carsten Dominik carsten.domi...@gmail.com wrote: On Nov 2, 2010, at 8:35 PM, Ilya Shlyakhter wrote: Carsten Dominik carsten.dominik at gmail.com writes: I have just pushed a rewrite of the clocktable code. Thanks Carsten! Maybe, the code could also be extended to display a summary of any variable, rather than just clocksum? E.g. the number of tasks done, or the amount of money spent. The sum for a given period would include the sum of a specified property in entries that were CLOSED within the specified period. Hi Ilya, I think thiswould now be easier to implement - even though this code is geared towar the clocking functionality. However, your proposal still sounds abstract - do you have concrete examples in mind? - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: New clocktable code
Carsten Dominik carsten.dominik at gmail.com writes: I have just pushed a rewrite of the clocktable code. Thanks Carsten! Maybe, the code could also be extended to display a summary of any variable, rather than just clocksum? E.g. the number of tasks done, or the amount of money spent. The sum for a given period would include the sum of a specified property in entries that were CLOSED within the specified period. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] xemacs compatibility
The following functions used in org-mode don't seem to exist in the development version of xemacs: booleanp decompose-region restore-buffer-modified-p Maybe, include versions of them with org-mode sources? ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-freemind.el and rx
- bad news org-freemind does not compile when (require 'rx) is used, error message is attached. I've made some more changes to rx.el for xemacs compatibility. Please try the new version: http://broadinstitute.org/~ilya/rx.el . Also, org-freemind.el uses delete-trailing-whitespace, which is present in Emacs but not in xemacs -- needs to be brought over. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Adding tags, grouping tags
Karl Maihofer ignoramus at gmx.de writes: Besides that I have tags in other contexts, e.g. GTD-related tags etc. So it would be very useful to be able to group the tags as it is possible for agenda commands. I think that a way to define logical groups of tags (or even a hierarchy of tags -- say with a subtree of tag names?) would be a very useful addition. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-freemind.el and rx
I think the solution is to do rx (I sure hate textual regexps) - which is on my list, but will likely be a while. Here is an initial attempt at porting rx to xemacs: http://www.broadinstitute.org/~ilya/rx.el Not fully tested so please test it. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-7 under Xemacs
| !! File error ((Cannot open load file rx)) | Error occurred processing lisp/org-freemind.el: Cannot open load file: rx xemacs does not include the 'rx' macro, unfortunately. Carsten: maybe, you could ask xemacs maintainers to include 'rx'? I'd like to use it in code as well. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Tracking time with MobileOrg
Richard Moreland rlm at ncogni.to writes: My plan for the UI is this: Thanks a lot for working on this. It would also be useful to have commands to adjust the clock log: delete a clock entry, subtract some duration from it (if you got distracted with another task for a while), adjust its endpoints. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Tracking time with MobileOrg
Can the current version of MobileOrg be used for a simple time tracking workflow? (i.e. does it have an easy clock in and clock out?) I very much second the request to support time tracking in MobileOrg. For me, this would be the single most useful extension of MobileOrg. ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] saving property values when archiving
When an item is archived to a new location, inherited tags are saved, but inherited properties are not. Was there a reason for this, or just not yet implemented? Thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Sparse trees and searching for multiple words
For example, I'd like to see entries which contains the words 'cat' and 'dog' in any order. Or 'apple', 'orange', 'melon', 'plum' and 'pear' in any order. Maybe this will help: http://www.emacswiki.org/emacs/StringPermutations ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-scan-tags
Another question: if org-map-continue-from is used to skip parts of the file, could that affect the correctness of org-scanner-tags? I.e. is any code that sets org-map-continue-from also responsible for updating org-scanner-tags? thanks, ilya On Tue, Sep 14, 2010 at 11:19 PM, Ilya Shlyakhter ilya_...@alum.mit.edu wrote: In org-scan-tags, if todo-only is t, would it be possible to speed things up by changingthe regexp go to just the lines with a TODO keyword? I.e. in (let* ((re (concat ^ outline-regexp *\\(( (mapconcat 'regexp-quote org-todo-keywords-1 \\|) (org-re )\\)? *\\(.*?\\)\\(:[[:alnum:]_@:]+:\\)?[ \t]*$))) remove the first ? if todo-only is t. Also, regexp-opt might make a more efficient regexp than mapconcat with regexp-quote. Reason for request: I'm writing an extension of org for setting checking goals, and want to quickly find entries with headlines of the form GOAL of which there may be relatively few in a large file. So, stepping through all entries and then checking them for the GOAL keyword is very inefficient. It would be much faster if the regexp included the GOAL as a keyword. It would be good if the parameter todo-only could be a list of strings, and org-scan-tags would return only the headlines where the todo keyword is from this list. It could use regexp-opt to make an efficient regexp for this. There also seem to be other opportunities for speeding up org-scan-tags in this way: e.g. if the match string includes +mytag, the regexp for the headline could include this as well. Similarly for properties. Maybe, org-make-tags-matcher could return a list of tags and properties that must appear in any matching entry. It would also help if the tags matcher expression could refer to text properties stored on the headline -- perhaps, with conditions such as :myprop=X (i.e. same as for org properties, but property name must be a keyword). It already does this for the 'org-category text property. Then one can e.g. mark entries representing unmet goals with text properties, and then use a regular org-tags-view to browse them in a sparsetree or an agenda. Thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-scan-tags
On Tue, Sep 14, 2010 at 11:19 PM, Ilya Shlyakhter ilya_...@alum.mit.edu wrote: There also seem to be other opportunities for speeding up org-scan-tags in this way: e.g. if the match string includes +mytag, the regexp for the headline could include this as well. Similarly for properties. Maybe, org-make-tags-matcher could return a list of tags and properties that must appear in any matching entry. Correction: org-make-tags-matcher would also need to return the list of _all_ tags/properties mentioned in the matcher, whose values should be inherited. The headline regexp would then need to match the mention of these tags/properties in entries, as well. It would also be good if org-scan-tags could be told to skip selected subtrees entirely (selected either by another matcher or a predicate passed in). ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-scan-tags
In org-scan-tags, if todo-only is t, would it be possible to speed things up by changingthe regexp go to just the lines with a TODO keyword? I.e. in (let* ((re (concat ^ outline-regexp *\\(( (mapconcat 'regexp-quote org-todo-keywords-1 \\|) (org-re )\\)? *\\(.*?\\)\\(:[[:alnum:]_@:]+:\\)?[ \t]*$))) remove the first ? if todo-only is t. Also, regexp-opt might make a more efficient regexp than mapconcat with regexp-quote. Reason for request: I'm writing an extension of org for setting checking goals, and want to quickly find entries with headlines of the form GOAL of which there may be relatively few in a large file. So, stepping through all entries and then checking them for the GOAL keyword is very inefficient. It would be much faster if the regexp included the GOAL as a keyword. It would be good if the parameter todo-only could be a list of strings, and org-scan-tags would return only the headlines where the todo keyword is from this list. It could use regexp-opt to make an efficient regexp for this. There also seem to be other opportunities for speeding up org-scan-tags in this way: e.g. if the match string includes +mytag, the regexp for the headline could include this as well. Similarly for properties. Maybe, org-make-tags-matcher could return a list of tags and properties that must appear in any matching entry. It would also help if the tags matcher expression could refer to text properties stored on the headline -- perhaps, with conditions such as :myprop=X (i.e. same as for org properties, but property name must be a keyword). It already does this for the 'org-category text property. Then one can e.g. mark entries representing unmet goals with text properties, and then use a regular org-tags-view to browse them in a sparsetree or an agenda. Thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-get-local-archive-location
In the routine org-get-local-archive-location, is the call to (match-string 1) at the end extraneous? Seems like you want to return org-archive-location in this case. (defun org-get-local-archive-location () Get the archive location applicable at point. (let ((re ^#\\+ARCHIVE:[ \t]+\\(\\S-.*\\S-\\)[ \t]*$) prop) (save-excursion (save-restriction (widen) (setq prop (org-entry-get nil ARCHIVE 'inherit)) (cond ((and prop (string-match \\S- prop)) prop) ((or (re-search-backward re nil t) (re-search-forward re nil t)) (match-string 1)) (t org-archive-location (match-string 1))) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] bug report: archiving an indirect buffer
org-archive-subtree calls (abbreviate-file-name (buffer-file-name)) but the buffer file name is nil for indirect buffers. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] custom sorting of agenda items
The problem here is that I would have to insert a call to the hook in many different places as there are many different functions that collect entries for the agenda. in org-finalize-agenda-entries, when you call org-agenda-before-sorting-filter-function, could you save-excursion and move to the original org entry before each call? It might be, but there is a possibility that updating the line after say a TODO state change will not work exactly like you wanted. that's ok in my case, the agenda items i'm collecting aren't todo items. thanks! maybe, document this in the docstring of org-agenda-before-sorting-filter-function . On Wed, Aug 18, 2010 at 3:35 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On Aug 17, 2010, at 6:40 PM, Ilya Shlyakhter wrote: Thanks Carsten, org-agenda-before-sorting-filter-function does what I need. It would be better if it was called with the point already on the corresponding headline in the corresponding buffer. This would also be faster as you could call it for all entries in one buffer at a time, avoiding a separate excursion for each entry. The problem here is that I would have to insert a call to the hook in many different places as there are many different functions that collect entries for the agenda. It seems that _appending_ text to the agenda line should be safe. Is that correct? It might be, but there is a possibility that updating the line after say a TODO state change will not work exactly like you wanted. - Carsten thanks, ilya On Mon, Aug 16, 2010 at 9:40 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On Aug 16, 2010, at 2:59 PM, Ilya Shlyakhter wrote: Thanks! Would things work faster if there was a user-defined hook that was called at each agenda entry at the same time the 'org-hd-marker property gets stored, so it could store any other things it needs from the entry as text properties for later use by user-defined entry sorting routine? Please pull and take a look at the new variable `org-agenda-before-sorting-filter-function'. Martin, I think you could use this variable also for your filtering application. - Carsten ilya On Mon, Aug 16, 2010 at 8:54 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On Aug 5, 2010, at 1:01 AM, Ilya Shlyakhter wrote: When giving a user-defined function for org-agenda-cmp-user-defined, the function gets two agenda entries. Is there a way from an agenda entry to get to the original org entry? Yes, the marker that points to the original entry is stored in text properties. You can take it and then go to the entry, for example with (org-with-point-at (org-get-at-bol 'org-hd-marker) ;; do here what you need to do at the location of the entry ) You could do this in org-finalize-agenda-hook for all entries, for example. Might slow things down, of cause. HTH - Carsten Best would be if, besides a user-defined sort function, you could also provide a function that takes the org entry and the agenda item (i.e. is run with point on the org entry and is passed the agenda item), and can then store anything it wants about the org entry as text properties on the agenda item. The companion user-defined sorting function could then use these stored text properties for ordering the agenda items. Could you add such a hook? thanks, ilya On Wed, Aug 4, 2010 at 6:51 PM, Bastien bastien.gue...@wikimedia.fr wrote: Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: I'd like to sort agenda entries in a custom agenda view by the value of a text property that I put on the headlines. Is there a way to do that? Well, no. Maybe playing around with org-map-entries could yield some result. -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten - Carsten - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] custom sorting of agenda items
Thanks Carsten, org-agenda-before-sorting-filter-function does what I need. It would be better if it was called with the point already on the corresponding headline in the corresponding buffer. This would also be faster as you could call it for all entries in one buffer at a time, avoiding a separate excursion for each entry. It seems that _appending_ text to the agenda line should be safe. Is that correct? thanks, ilya On Mon, Aug 16, 2010 at 9:40 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On Aug 16, 2010, at 2:59 PM, Ilya Shlyakhter wrote: Thanks! Would things work faster if there was a user-defined hook that was called at each agenda entry at the same time the 'org-hd-marker property gets stored, so it could store any other things it needs from the entry as text properties for later use by user-defined entry sorting routine? Please pull and take a look at the new variable `org-agenda-before-sorting-filter-function'. Martin, I think you could use this variable also for your filtering application. - Carsten ilya On Mon, Aug 16, 2010 at 8:54 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On Aug 5, 2010, at 1:01 AM, Ilya Shlyakhter wrote: When giving a user-defined function for org-agenda-cmp-user-defined, the function gets two agenda entries. Is there a way from an agenda entry to get to the original org entry? Yes, the marker that points to the original entry is stored in text properties. You can take it and then go to the entry, for example with (org-with-point-at (org-get-at-bol 'org-hd-marker) ;; do here what you need to do at the location of the entry ) You could do this in org-finalize-agenda-hook for all entries, for example. Might slow things down, of cause. HTH - Carsten Best would be if, besides a user-defined sort function, you could also provide a function that takes the org entry and the agenda item (i.e. is run with point on the org entry and is passed the agenda item), and can then store anything it wants about the org entry as text properties on the agenda item. The companion user-defined sorting function could then use these stored text properties for ordering the agenda items. Could you add such a hook? thanks, ilya On Wed, Aug 4, 2010 at 6:51 PM, Bastien bastien.gue...@wikimedia.fr wrote: Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: I'd like to sort agenda entries in a custom agenda view by the value of a text property that I put on the headlines. Is there a way to do that? Well, no. Maybe playing around with org-map-entries could yield some result. -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] tag or property names with dashes
When doing an agenda tags match for tags or properties with dashes in their name, the dashes become negation operators: my-prop0 means entries that have the tag 'my' and do not have a positive property 'prop', rather than entries that have a positive property 'my-prop'. Is there a way to escape the dashes to get the latter meaning? thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] custom sorting of agenda items
Thanks! Would things work faster if there was a user-defined hook that was called at each agenda entry at the same time the 'org-hd-marker property gets stored, so it could store any other things it needs from the entry as text properties for later use by user-defined entry sorting routine? ilya On Mon, Aug 16, 2010 at 8:54 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On Aug 5, 2010, at 1:01 AM, Ilya Shlyakhter wrote: When giving a user-defined function for org-agenda-cmp-user-defined, the function gets two agenda entries. Is there a way from an agenda entry to get to the original org entry? Yes, the marker that points to the original entry is stored in text properties. You can take it and then go to the entry, for example with (org-with-point-at (org-get-at-bol 'org-hd-marker) ;; do here what you need to do at the location of the entry ) You could do this in org-finalize-agenda-hook for all entries, for example. Might slow things down, of cause. HTH - Carsten Best would be if, besides a user-defined sort function, you could also provide a function that takes the org entry and the agenda item (i.e. is run with point on the org entry and is passed the agenda item), and can then store anything it wants about the org entry as text properties on the agenda item. The companion user-defined sorting function could then use these stored text properties for ordering the agenda items. Could you add such a hook? thanks, ilya On Wed, Aug 4, 2010 at 6:51 PM, Bastien bastien.gue...@wikimedia.fr wrote: Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: I'd like to sort agenda entries in a custom agenda view by the value of a text property that I put on the headlines. Is there a way to do that? Well, no. Maybe playing around with org-map-entries could yield some result. -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] hiding PROPERTIES line
to 100% hide the :PROPERTIES: drawer while giving the user a hint that there is one... What about a command to hide/unhide _all_ :PROPERTY: lines? Then they're out-of-the-way in ordinary use, and you can do the command and see if there's a property drawer on a given entry. Better, you would hide all :PROPERTY: drawers that contain only specified properties. Then you could have tree-wide properties (such as entry creation or modification times) for every entry, without cluttering the tree. You could set the entry creation property at creation time, and entry modification property at save time (by seeing which entries have changed since last save). Then you could quickly find recently-modified entries either globally or in a given subtree. Also, it would be good to have a command to hide :LOGBOOK: lines in the same way. Usually they're only needed for computing time totals spent under each tree branch, but you don't care about the details recorded in a given :LOGBOOK: drawer. More generally, you could have a list of hideable drawers that are completely hidden/revealed by the command, unless they meet a condition specified by a callback function. Would that be hard to add? thanks, ilya On Wed, Aug 4, 2010 at 12:47 AM, Bastien bastien.gue...@wikimedia.fr wrote: Ilya Shlyakhter ilya_...@alum.mit.edu writes: Is there a way to hide/show the :PROPERTIES: line representing the properties locker, either globally or for a subtree? Nope. Well, every UI element you hide must be partly visible, so that the user knows how to unhide (or unfold) it. I cannot think of a reasonable way to 100% hide the :PROPERTIES: drawer while giving the user a hint that there is one... -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] custom sorting of agenda items
I'd like to sort agenda entries in a custom agenda view by the value of a text property that I put on the headlines. Is there a way to do that? thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] custom sorting of agenda items
When giving a user-defined function for org-agenda-cmp-user-defined, the function gets two agenda entries. Is there a way from an agenda entry to get to the original org entry? Best would be if, besides a user-defined sort function, you could also provide a function that takes the org entry and the agenda item (i.e. is run with point on the org entry and is passed the agenda item), and can then store anything it wants about the org entry as text properties on the agenda item. The companion user-defined sorting function could then use these stored text properties for ordering the agenda items. Could you add such a hook? thanks, ilya On Wed, Aug 4, 2010 at 6:51 PM, Bastien bastien.gue...@wikimedia.fr wrote: Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: I'd like to sort agenda entries in a custom agenda view by the value of a text property that I put on the headlines. Is there a way to do that? Well, no. Maybe playing around with org-map-entries could yield some result. -- Bastien ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] column view asterisks
In the Column View, the asterisks are showing even though I've enabled clean view that hides the asterisks normally. Is there a way to hide them? thanks, ilya p.s. since the Column View can take a while to construct, it might be good to display a status message saying creating column view while it's working. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] hiding PROPERTIES line
Is there a way to hide/show the :PROPERTIES: line representing the properties locker, either globally or for a subtree? I'd like to store some properties for every entry (e.g. its creation time), but then the :PROPERTIES: lines add too much clutter, even in the drawer-collapsed state. Is there a way to hide/show them just like the closed outline subtrees are hidden/shown? thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] suggestion: HTML frames option
It would be good if the HTML exporter had an option to create a web page with two frames: in the top frame would be the original exported HTML, and in the bottom frame would display the targets of all external links in the org file. Within-orgfile links would still be shown in the top frame. Then, the org file could serve as an index for organizing a variety of information, and one could browse the org file in the top frame and quickly see the targets of external links in the bottom frame, without having to switch tabs or windows in the browser. There would be an option to have the index on the left, instead of on the top. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] html export: specifying meta tags
Is there a way to specify code to be inserted as meta tags in the head.../head section of the exported HTML document? E.g. I'd like to insert the lines META HTTP-EQUIV=Expires CONTENT=Thu, 1 June 2000 23:59:00 GMT META HTTP-EQUIV=pragma CONTENT=no-cache to force a frequently-updated document to be reloaded every time, rather than being cached by the browser. If there isn't a way to do that I'd like to propose this as a feature. Thanks, ilya ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] suggestion: automatically recording entry creation date
A frequently-needed task is to find recently created entries. Right now I do this by manually pasting a date into each entry, and using the timeline agenda. Maybe, there are better ways? E.g. have the option to automatically record a property, Creation-date, when an entry is created. There would be much clutter if every entry had a :PROPERTIES: line. But maybe there could be an option to hide the :PROPERTIES: lines completely, unless it contained some user-defined properties. Or, creation date could be stored as a text property, to avoid clutter, for long-running emacs sessions. But it would be lost when the file is closed. Maybe at file-closing time it could be converted to a normal property in the :PROPERTIES: drawer. Or maybe there are other options? ilya ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] suggestion: options for chronological agenda
Ah, didn't know about that. Things have changed since I last read the full manual :) Thanks for help! ilya On Mon, Sep 28, 2009 at 4:10 PM, Carsten Dominik carsten.domi...@gmail.com wrote: Hi Ilya, have you tried C-a a to get the agenda, and then v [ to include inactive time stamps? HTH - Carsten On Sep 26, 2009, at 6:02 AM, Ilya Shlyakhter wrote: I often need to find recently modified entries. I try to timestamp entries I work on with the active timestamps (in angular brackets), and use the C-x a L command. This mostly works, but is imperfect: - when i use time logging, it inserts inactive timestamps that are not found this way. so, i can't use this to find recently worked on entries. - it looks at the _first_ timestamp in an entry, rather than the _last_ timestamp - it is limited to one file . would be much better if it could be made to work across the entire agenda. - it would be fine to have the option to limit it to entries within the last, say, week, if that would speed it up. The suggestion is to enhance the timeline agenda with options to: - recognize inactive timestamps ([in square brackets]) - use last, rather than first, timestamp in an entry - search the entire agenda, rather than just the current file - limit the agenda to entries within the last (say) week. The timeview agenda was of course originally designed for another use case -- as a personal calendar/diary. But I'm finding myself repeatedly using it this way: organize the entries by hierarchical subject, and use the timeline agenda to generate a chronological listing. It would also be _really_ great if the chronological listing could be filtered to contain only entries matching a certain tag/property query. Then you could e.g. get a chronological list of important entries, or entries on a certain subject. ilya ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] suggestion: options for chronological agenda
I often need to find recently modified entries. I try to timestamp entries I work on with the active timestamps (in angular brackets), and use the C-x a L command. This mostly works, but is imperfect: - when i use time logging, it inserts inactive timestamps that are not found this way. so, i can't use this to find recently worked on entries. - it looks at the _first_ timestamp in an entry, rather than the _last_ timestamp - it is limited to one file . would be much better if it could be made to work across the entire agenda. - it would be fine to have the option to limit it to entries within the last, say, week, if that would speed it up. The suggestion is to enhance the timeline agenda with options to: - recognize inactive timestamps ([in square brackets]) - use last, rather than first, timestamp in an entry - search the entire agenda, rather than just the current file - limit the agenda to entries within the last (say) week. The timeview agenda was of course originally designed for another use case -- as a personal calendar/diary. But I'm finding myself repeatedly using it this way: organize the entries by hierarchical subject, and use the timeline agenda to generate a chronological listing. It would also be _really_ great if the chronological listing could be filtered to contain only entries matching a certain tag/property query. Then you could e.g. get a chronological list of important entries, or entries on a certain subject. ilya ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] broken link
The link from orgmode.org to http://sachachua.com/wp/2008/01/18/outlining-your-notes-with-org/ is broken. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] broken link
hmm, works now, must have been a transient problem on my end -- sorry. On Wed, Aug 19, 2009 at 2:29 PM, Greg Newmang...@20seven.org wrote: works for me On Wed, Aug 19, 2009 at 2:24 PM, Ilya Shlyakhter ilya_...@alum.mit.edu wrote: The link from orgmode.org to http://sachachua.com/wp/2008/01/18/outlining-your-notes-with-org/ is broken. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] suggestion: native orgmode XML export (and import?)
Out of curiosity, how would you want to handle textual content? Pass it through unchanged with org's wiki-like markup in tact, or somehow xml-ified?: *foo* -- *foo* *foo* -- strongfoo/strong Probably the latter, since converting XMLified content to wiki markup (or any other form) is easy and does not require manual parsing, while the other direction is harder. But for a first version, just leaving the markup as text would be fine too. What would help a lot is, if XML content could be imported as a subtree. Then you could have python plugins that take a subtree (or an entire orgfile) converted to XML, process it into updated XML, and then that updated XML gets imported back into org and replaces the original subtree. This would make it easy for users to implement something like http://tinyurl.com/nskzs8 , and probably other custom functions. On Sun, Aug 9, 2009 at 3:19 PM, B Smith-Mannschottbsmith.o...@gmail.com wrote: On Sat, Aug 8, 2009 at 22:25, Ilya Shlyakhterilya_...@alum.mit.edu wrote: In the meantime, it would be useful to describe what kind of XML output do you want, because XML does not really describe anything per se. I'm looking for XML output that would closely mirror the logical structure of the org file, and that would contain all the information in the orgfile (since it's easy to ignore the parts you don't need during XML processing). So, something like orgfile entry headlineTasks/headline bodyHere are the tasks I need to do/body children entry headlineBuy bread/headline todo-statusDONE/todo-status tagstagfood/tagtagerrands/tag/tags properties propertynameImportance/namevalue1/value/property propertynameDeadline/namevaluedateday07/daymonth08/monthyear09/year/date/value/property /properties /entry /children /entry /orgfile The details of the XML schema can of course change. But it should let you process org file data without having to parse any elements of the org file (ideally, even dates) -- it would all be parsed by orgmode's native parsing code and put into XML elements. If there are questions about how to represent specific org elements in XML I can try to write a more detailed spec. Out of curiosity, how would you want to handle textual content? Pass it through unchanged with org's wiki-like markup in tact, or somehow xml-ified?: *foo* -- *foo* *foo* -- strongfoo/strong // Ben ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] suggestion: native orgmode XML export (and import?)
In the meantime, it would be useful to describe what kind of XML output do you want, because XML does not really describe anything per se. I'm looking for XML output that would closely mirror the logical structure of the org file, and that would contain all the information in the orgfile (since it's easy to ignore the parts you don't need during XML processing). So, something like orgfile entry headlineTasks/headline bodyHere are the tasks I need to do/body children entry headlineBuy bread/headline todo-statusDONE/todo-status tagstagfood/tagtagerrands/tag/tags properties propertynameImportance/namevalue1/value/property propertynameDeadline/namevaluedateday07/daymonth08/monthyear09/year/date/value/property /properties /entry /children /entry /orgfile The details of the XML schema can of course change. But it should let you process org file data without having to parse any elements of the org file (ideally, even dates) -- it would all be parsed by orgmode's native parsing code and put into XML elements. If there are questions about how to represent specific org elements in XML I can try to write a more detailed spec. thanks, ilya On Sat, Aug 8, 2009 at 7:48 AM, Bastienbastiengue...@googlemail.com wrote: Ilya Shlyakhter ilya_...@alum.mit.edu writes: That's great, thanks! I should be able to take it from there. It would be great if at some point this became official, and also included an XML exporter and specification. FYI, I'll upload a slightly improved version of org-export.el next week, together with documentation on how to write an exporter. But the basic structure of the parsed buffer is the same, you can use it safely. In the meantime, it would be useful to describe what kind of XML output do you want, because XML does not really describe anything per se. Best, -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
