Re: [O] Attachments and refiling

[Gustav Wikström]

Ok. I would really like attachments to be integrated with refiling though
even if it was a non-default option. Another feature that could improve the
use of attachments is to allow links to the attached folders also via the
C-c C-l interface in a similar way as stored links (C-c l ). I.E to get the
attachment-folder as an item in the C-c C-l buffer with TAB-completion.

regards
G

2011/7/16 Darlan Cavalcante Moreira darc...@gmail.com


 I use org-attach regularly and consider it to be a great feature of
 org-mode. Since I only attach to the sub-tree (instead of to a different
 file) I have not this problem. However, sometimes a set the attach
 directory of two different headings to the same folder (when it makes
 sense) and if org always moved the attached files it would break the other
 sub-tree.

 An alternative is to change the attach directory in the archived entry to
 point to the original attach directory where the files are. When archiving
 to a file in a different folder org could ask if it should also move the
 attached files or simply change the attach directory accordingly (I would
 prefer this as the default if ask as the default was considered too
 annoying).

 --
 Darlan

 At Fri, 15 Jul 2011 16:55:06 +0200,
 Gustav Wikström gustav.e...@gmail.com wrote:
 
  [1  text/plain; ISO-8859-1 (quoted-printable)]
  Hello Bastien!
 
  To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling
 it
  file 'a').
 
  When marked with TODO item: done, headings in this file are archived to
  another file called c:\temp\archive\agenda.org_archive ('b')
 
  If i use C-c C-a to attach a file to a certain topic in 'a' and then
 refile
  this topic to 'b', when done the attachment still resides in c:\temp\data
  and will not be found when looking at the attachment in 'b'.
 
  Thus my question is if it is possible to also refile the attachment so
 the
  attachment-folder resides in c:\temp\archive\data and is avaliable in
 'b'?
 
  /Gustav
 
  2011/7/15 Bastien b...@altern.org
 
   Hi Gustav,
  
   Gustav Wikström gustav.e...@gmail.com writes:
  
Is it possible to make attachment-folders move with the headings when
refiling them to other locations?
  
   I'm not sure what you mean.
  
   Can you give an example?
  
   --
Bastien
  
  [2  text/html; ISO-8859-1 (quoted-printable)]
 

[O] iCalendar export

[Gustav Wikström]

Hello!

I like the feature that TODO-items and calendar-items can be exportet to an
iCalendar file. But one thing bugs me, I'm having trouble finding suitable
software that supports the iCalendar-standard with vtodo items...

So my question to this newsgroup is; If you use the iCalendar export
function, what software do you use to view this information? And have anyone
got this information to their mobile devices? Android? Having this
information on the go would be killer...

Regards
Gustav

Re: [O] Attachments and refiling

[Gustav Wikström]

I'm leaning towards not moving my archive to a different folder. I like
having the attachments relative.

Are archive- and refile-hooks implemented b.t.w.? This would make it
possible to hack a personal setting, or am I wrong?

/Gustav

2011/7/24 Bastien b...@altern.org

 Hi Gustav and Darlan,

 one solution I can think of is to set `org-attach-directory'
 to an absolute path instead of data/ (the current default
 value).

 This way, refiling an entry will not lose attachments.

 I'm considering using ~/.org-data/ as the default value.

 What do you think?

 --
  Bastien

Re: [O] Attachments and refiling

[Gustav Wikström]

To make org-mode look for attachments in the current sub-tree when using
org-insert-link would simplify the process of linking to attached files
(useful at least when exporting). Persistent links, in in this regard, seems
like a nice idea!

/Gustav

2011/7/24 Bastien b...@altern.org

 Hi Gustav,

 Gustav Wikström gustav.e...@gmail.com writes:

  Another feature that could improve the use of attachments is to allow
  links to the attached folders also via the C-c C-l interface in a
  similar way as stored links (C-c l ). I.E to get the attachment-folder
  as an item in the C-c C-l buffer with TAB-completion.

 You can already use (setq org-attach-store-link-p t) to create a link
 while attaching a file.

 Since links are deleted as soon as they are inserted, this will be
 usable only once.  We can imagine *persistent links* -- and links to
 attached files could be a good example of persistent links.

 What do you think?

 --
  Bastien

Re: [O] Attachments and refiling

[Gustav Wikström]

In case the not worrying about where.. in (1) is part the purpose of the
attachment functionality the idea of an absolute path seems sound. I agree
with it being a nice feature, and probably the best to have as default.

However I think it also is nice to also be able to use custom names to
attachment folders. And it would be nice be able to use some logic with
this, like automatically setting the folder name to the same as the heading
it's attached to. And to allow properties on a file/heading/sub-tree basis
which defines the base-path to where attachments to that particular
file/heading/sub-tree should reside on the system, relative or non-relative.
This would allow for more atomic solutions if i'm writing a document on the
side of my main setup and want to add some attachments in the same path.

This adds a bit to the complexity of designing the functionality, and
questions about refiling and archiving arise.. But maybe just adding a
warning for these events might be enough as a first step. Although, with
file-properties for attachment directories it might be possible to ask if
the attachment-dir should also be moved (or copied) to this new location.

But still, it is a really nice feature to have control over the
attachments. So from my point of view it seems sound to try to reason about
different solutions to this or at least keep it in mind for future
functionality.

Just some thoughts
Gustav

On Thu, Jul 28, 2011 at 9:51 AM, Bastien b...@altern.org wrote:

 Hi Darlan,

 here is how I see the situation regarding attachments:

 1. org-attach.el is nice because it makes it easy to attach a file to a
   task, while not *worrying* about where the file is on the harddrive.

 2. Adding an ATTACH_DIR property will always add an absolute path, so
   there is no problem when moving an entry with an explicit ATTACH_DIR.

 3. Refiling/archiving subtrees lose track of some attachments when the
   attach directory data/ is *relative* to the org file (which is the
   default) and when the target org file is not in the same directory.

 4. Moving an entry with an ATTACH_DIR_INHERIT will lose attachments
   when the ATTACH_DIR of the target entry is different.

 (3) and (4) are two distinct problems.

 I suggest fixing problem (3) by making `org-attach-dir' defaulting to
 ~/.org-attachments/.  I

 I suggest fixing problem (4) by explicitely replacing ATTACH_DIR_INHERIT
 with the corresponding ATTACH_DIR when the target subtree has a
 different ATTACH_DIR.

 The core idea is that I want to avoid moving files themselves: I think
 it's a risky road, and I hope the solutions above will make this road
 unnecessary.

 I'm interested in feedback and ideas about such proposed changes.

 Thanks a lot!

 --
  Bastien

Re: [O] Attachments and refiling

[Gustav Wikström]

What about being able to link to attachments in a similar way as one links
to files or web-pages? Using [[attachment:some_file.sql][some link name]] ?
Comments? Problems with this?

2011/7/25 Gustav Wikström gustav.e...@gmail.com

 To make org-mode look for attachments in the current sub-tree when using
 org-insert-link would simplify the process of linking to attached files
 (useful at least when exporting). Persistent links, in in this regard, seems
 like a nice idea!

 /Gustav

 2011/7/24 Bastien b...@altern.org

 Hi Gustav,

 Gustav Wikström gustav.e...@gmail.com writes:

  Another feature that could improve the use of attachments is to allow
  links to the attached folders also via the C-c C-l interface in a
  similar way as stored links (C-c l ). I.E to get the attachment-folder
  as an item in the C-c C-l buffer with TAB-completion.

 You can already use (setq org-attach-store-link-p t) to create a link
 while attaching a file.

 Since links are deleted as soon as they are inserted, this will be
 usable only once.  We can imagine *persistent links* -- and links to
 attached files could be a good example of persistent links.

 What do you think?

 --
  Bastien

[O] Problem: Customizing agenda-views with org-agenda-prefix-format

[Gustav Wikström]

Hello!

I've tried to customize the output in agenda-views using
org-agenda-prefix-format but I didn't get it to work properly.

I created this agenda view to illustrate my problem:

(setq org-agenda-custom-commands
  '((w Deadlines
 ;; inbox
 ((tags-todo +DEADLINE=\today\
 ((org-agenda-prefix-format  %-12c%?-12t% s)
  (org-agenda-tags-todo-honor-ignore-options t)
  (org-agenda-todo-ignore-deadlines nil)
  ))
  (tags-todo +DEADLINE=\today\
 ((org-agenda-tags-todo-honor-ignore-options t)
  (org-agenda-todo-ignore-deadlines nil)
  ))

The only thing that differs is (org-agenda-prefix-format 
%-12c%?-12t% s) which
is present in the first of the two. The output when showing this agenda is:

Headlines with TAGS match: +DEADLINE=today
 Recurring   TODO Sommarlöpning

=
Headlines with TAGS match: +DEADLINE=today
  Recurring:  TODO Sommarlöpning

There are some differences corresponding to the agenda-prefix-format
(indentation and lack of :) but all the formatting options have not been
applied. I can not see the deadline-information I should get from % s.
(From org-agenda.org: %s   Scheduling/Deadline information, a short
string)

The following is the entry in my agenda-file:

** TODO Sommarlöpning
DEADLINE: 2011-08-14 Sun 16:00 .+2d
:LOGBOOK:
- Refiled on [2011-08-15 Mon 15:45]
- State CANCELED   from TODO   [2011-08-13 Sat 19:05]
- State DONE   from TODO   [2011-08-10 Wed 19:42]
- State TODO   from[2011-08-10 Wed 09:53]
:END:
:PROPERTIES:
:LAST_REPEAT: [2011-08-13 Sat 19:05]
:END:

Any guesses on what is wrong? Can anyone reproduce my problem or is it my
settings?

Regards Gustav

Re: [O] Attachments and refiling

[Gustav Wikström]

Thanks for this. Added it to my settings for now =)

/Gustav

2011/8/2 Matt Lundin m...@imapmail.org

 Gustav Wikström gustav.e...@gmail.com writes:

  However I think it also is nice to also be able to use custom names to
  attachment folders. And it would be nice be able to use some logic with
  this, like automatically setting the folder name to the same as the
  heading it's attached to. And to allow properties on a file/heading/
  sub-tree basis which defines the base-path to where attachments to that
  particular file/heading/sub-tree should reside on the system, relative
  or non-relative. This would allow for more atomic solutions if i'm
  writing a document on the side of my main setup and want to add some
  attachments in the same path.
 
  But still, it is a really nice feature to have control over the
  attachments. So from my point of view it seems sound to try to reason
  about different solutions to this or at least keep it in mind for
  future functionality.

 One possibility is to advise the function org-attach-dir to call
 org-attach-set-directory (and, optionally, org-attach-set-inherit) if
 the entry does not already have an ATTACH_DIR property:

 --8---cut here---start-8---
 (defadvice org-attach-dir (before my-org-attach-set-dir-before-attach
 activate)
  Prompt for attachment directory (thus preempting org-get-id).
  (unless (org-entry-get nil ATTACH_DIR 'inherit)
(org-attach-set-directory)))
 --8---cut here---end---8---

 This allows one to enter the name of the directory *before* org attaches
 the file. This is the way I use org-attach, as I prefer human-readable
 directories to UUIDs.

 Best,
 Matt

[O] Bug in calculations with durations and time values in tables

[Gustav Wikström]

Hello, just a small bug-report. The following does not seem right:

|First |Second |Result |
|--+---+---|
| 00:00:00 | -00:10:10 | -01:49:50 |
#+TBLFM: $3='(+ $1..$2);T

|First |Second | Result |
|--+---+|
| 00:00:00 | -00:10:10 |  -0.17 |
#+TBLFM: $3='(+ $1..$2);t

|First |Second |Result |
|--+---+---|
| 00:00:00 | -02:01:00 | -03:59:00 |
#+TBLFM: $3='(+ $1..$2);T

|First |Second | Result |
|--+---+|
| 00:00:00 | -02:01:00 |  -2.02 |
#+TBLFM: $3='(+ $1..$2);t


Somehow, when the result of a time-calculation with minutes and seconds goes
negative the result gets an additional negative two hours added (with the
minutes and seconds removed from these two hours)... This seems to be a
problem when doing calculations with the suffix ;T.

;t works as intended in this respect.

Regards
Gustav

[O] TABLES: Remove/add cell

[Gustav Wikström]

Hello!

How do I add or remove a single cell in a table?

Example:
I have the following table:
|1 |1 |
|2 |3 |
|3 |4 |
|4 |  |

Now I want to add an empty cell in @2$2 (below the heading) and thus move
the following cells in column 2 down one step.

After:
|1 |1 |
|2 |  |
|3 |3 |
|4 |4 |

Is this doable?

Regards
Gustav

Re: [O] TABLES: Remove/add cell

[Gustav Wikström]

This is similar to the way I've done it before. It makes it cumbersome if
there are many lines below the cell that is to be inserted though..

It would be nice to have as a function that inserts or deletes a cell in the
same way as one can insert and delete rows and columns. Maybe as a prefix
to M-S-left/right and M-S-up/down ?

/Gustav

On Fri, Sep 30, 2011 at 8:50 PM, brian powell briangpowel...@gmail.comwrote:

 * May want to turn org-mode/table off temporarily (or maybe it will
 just make it easier) then you can do the rectangle edits michael was
 referring to:
 ** Go to the point just to the right of the 4.
 ** C@ ---marks the point.
 ** Go to the 3.
 ** Cxrk
 ** Go to @2$2--i.e. where the 4 used to be.
 ** Cxry
 * Emacs OrgMode makes all of this easier since it lines everything up
 for you by covering down the columns (org-table-align)---making all
 the cells easily edited by the usual rectangle-killing and
 rectangle-yanking methods.
 ** The method above can be generalized for editing OrgMode tables
 regardless of the number of symbols in the cells--since OrgMode aligns
 them for you; and, EMACS is restricted only by the amount of RAM in
 your computer.
 *** Also, if you want to edit gygabyte size files, using similar
 methods, I highly recommend QEMACS.

[O] Org-agenda-custom-commands, restrict Agenda to file/files?

[Gustav Wikström]

Hello!

I'm currently using the feature to restrict the org-agenda (C-a a) to a
certain file and then enable the log-mode. I do this to view all my clocked
time in that file. Currently this means opening the file and then open the
agenda with C-a  a l

I want to simplify this with a custom-command. And here comes my problem,
what is the option to restrict the agenda to a certain file? Changing the
org-agenda-files list does not seem to make a difference when using a custom
agenda.

It works for other custom agenda commands (see
http://orgmode.org/worg/org-tutorials/org-custom-agenda-commands.html#sec-4),
and it works interactively but I cannot get it to work with an agenda
command inside org-agenda-custom-commands.. Can someone enlighten me on this
subject?

Kind regards
Gustav

Re: [O] Agenda view side-by-side

[Gustav Wikström]

The following might be of interest:

*** Vertical Split window
Splits screen vertically if the width of the window is large enough.
Inspired by the following post:
-
http://stackoverflow.com/questions/2081577/setting-emacs-split-to-horizontal

#+begin_src emacs-lisp :tangle yes
  (setq split-height-threshold nil)
  (setq split-width-threshold 160)
#+end_src


Regards
Gustav

On Mon, Oct 17, 2011 at 11:12 AM, Johan Ekh ekh.jo...@gmail.com wrote:

 Hi all,
 when I use C-c a a to create an agenda, my emacs window is split
 horizontally and the agenda is shown in the lower
 window. I'd rather have my emacs window splitted vertically and the agenda
 shown in the right window. How can I do this?

 Best regards,
 Johan

[O] Link abbreviations, org-files with searches

[Gustav Wikström]

Hello!

When defining a link-abbreviation to an org-file with a headline search I
manage to get it to work with the following syntax:

  #+LINK: foo file:/long/path/to/file/foo.org
  [[foo*heading inside foo]]

I have to use four : to be able to search, instead of the three I would
expect (expecting three since the first : is used to declare that I want
to enter a tag and the following two are used inside the tag). Is this
intended behaviour?

Also, it only seems to work for headline-search. I cannot get the regular
search to work. Can someone confirm this behaviour?

/Gustav

Re: [O] Link abbreviations, org-files with searches

[Gustav Wikström]

Hi Suvayu!

I know about the normal links and the possibility to search with these. The
thing is that I want to use an abbreviation (see sec. 4.6 in the manual) to
not have to type the path for this particular link every time.

Instead of typing (1)

[[file:/path/to/file.org::*Heading_text][Description]]

I want to be able to add an abbreviation in the beginning of the file the
link is in, with (2):

#+LINK: foo file:/long/path/to/file/foo.org

and then use this abbreviation later in the text with (3):

[[foo][Description]]

,and also be able to use searches with this abbreviation. And it is this
syntax that seems a bit cumbersome to use when adding headline-searching to
it (requiring four :) and does not work when trying to use regular
search. Unless I'm doing something wrong.

I also know that I could add the ::%s to the link, giving (4):

#+LINK: foo file:/long/path/to/file/foo.org::%s

but this makes it unusable as a simple file link without search. I intend
to use the link in multiple places inside my document both with and without
searches, thus I'm still wondering about this syntax-issue and the
non-headline search.

Regards
Gustav

(PS. sorry for the double-mail Suvayu. )

2011/10/31 suvayu ali fatkasuvayu+li...@gmail.com

 Hello Gustav,

 2011/10/31 Gustav Wikström gustav.e...@gmail.com:
  Hello!
  When defining a link-abbreviation to an org-file with a headline search I
  manage to get it to work with the following syntax:
#+LINK: foo file:/long/path/to/file/foo.org

 AFAIK, this is not required. Support for linking to org headlines is
 already built in.

[[foo*heading inside foo]]

 This should be something like this:


 [[file:/path/to/file.org::*Heading_text][Description]]

  I have to use four : to be able to search, instead of the three I would
  expect (expecting three since the first : is used to declare that I
 want
  to enter a tag and the following two are used inside the tag). Is this
  intended behaviour?

 I am not sure what you are talking about here. Could you give an
 example to illustrate?

  Also, it only seems to work for headline-search. I cannot get the regular
  search to work. Can someone confirm this behaviour?

 For the regular search, something like this should be sufficient:

 [[file:/path/to/file.org::search_phrase][Description]]

  /Gustav

 Hope this helps.

 PS: org-mode has amazing info documentation. Please check them out. All
of these are well covered there. For tutorials, you can check the
community site Worg.

 --
 Suvayu

 Open source is the future. It sets us free.

Re: [O] Link abbreviations, org-files with searches

[Gustav Wikström]

2011/10/31 Suvayu Ali fatkasuvayu+li...@gmail.com:
...
 I also know that I could add the ::%s to the link, giving (4):

 #+LINK: foo     file:/long/path/to/file/foo.org::%s

 but this makes it unusable as a simple file link without search. I
 intend to use the link in multiple places inside my document both
 with and without searches, thus I'm still wondering about this
 syntax-issue and the non-headline search.


 How is it unusable? Shouldn't the following work with the above setting?

 [[foo:search_string][Description]]
 [[foo:*Headline_string][Description]]

 Of course I didn't have the time to test this variation, so indeed there
 could be a bug. :-p

This works when adding :: to the end of the link. But with this
setting I cannot use the link as a simple file-link, eg. the following
does not work:

#+LINK: foo     file:/long/path/to/file/foo.org::
[[foo][Description]]

When trying to follow this link I get an error saying that there is
no such file: /long/path/to/file/foo.org::

/Gustav

Re: [O] Link abbreviations, org-files with searches

[Gustav Wikström]

2011/10/31 Suvayu Ali fatkasuvayu+li...@gmail.com:
 Hi Gustav,

 On Mon, 31 Oct 2011 14:55:27 +0100
 Gustav Wikström gustav.e...@gmail.com wrote:

 This works when adding :: to the end of the link. But with this
 setting I cannot use the link as a simple file-link, eg. the following
 does not work:

 #+LINK: foo     file:/long/path/to/file/foo.org::
 [[foo][Description]]

 When trying to follow this link I get an error saying that there is
 no such file: /long/path/to/file/foo.org::

 Of course that won't work! The resulting link is not a valid link
 syntax. Since you don't specify a tag, the final link looks like this:

 [[file:/path/to/file.org::]]

 which is incorrect.

 From a test the following worked nicely.

 #+LINK: odir2 file:~/org/coding.org

 [[odir2][link to file]]

 So in conclusion, if you want to use both bare file/directory links as
 well as headline/search links, you would have to define two separate
 link shortcuts.

Yes, I'm aware of this. And this is the reason of my initial question.
Should it really be necessary to specify two separate links to the
same file when I want to both link to the file directly and link it
with a search?

Thus, this works:

  #+LINK: foo     file:/long/path/to/file/foo.org
  [[foo*heading search]]

but this does not:

 #+LINK: foo     file:/long/path/to/file/foo.org
 [[foosearch]]

I find the use of four : a bit strange, but I guess this is only a
limit of my understanding a.t.m. In my view the first colon should be
stating the start of the tag and the rest of the string the tag
itself. This leaves three colons for the tag which in my view is one
to many. But it seems to work. And this is what I'm scratching my head
about.

I also suspect a bug hidden somewhere, since headlines can be searched
for but not text inside the document.

Anyone got any input on this?
/Gustav

Re: [O] Link abbreviations, org-files with searches

[Gustav Wikström]

I did some digging and ended at the function org-link-expand-abbrev.

According to the org-documentation, abbreviations should be written with:

[[linkword:tag]]

however the regular expression doing the matching in the function also
allows the following:

[[linkword::tag]]

The greed of the regular expression makes it a requirement to use four
colons when using abbreviation and search. Also, all types of
searching works, not only the headline-search as I stated earlier.

Just wanted to clear this out
/Gustav

2011/10/31 Gustav Wikström gustav.e...@gmail.com:
 2011/10/31 Suvayu Ali fatkasuvayu+li...@gmail.com:
 Hi Gustav,

 On Mon, 31 Oct 2011 14:55:27 +0100
 Gustav Wikström gustav.e...@gmail.com wrote:

 This works when adding :: to the end of the link. But with this
 setting I cannot use the link as a simple file-link, eg. the following
 does not work:

 #+LINK: foo     file:/long/path/to/file/foo.org::
 [[foo][Description]]

 When trying to follow this link I get an error saying that there is
 no such file: /long/path/to/file/foo.org::

 Of course that won't work! The resulting link is not a valid link
 syntax. Since you don't specify a tag, the final link looks like this:

 [[file:/path/to/file.org::]]

 which is incorrect.

 From a test the following worked nicely.

 #+LINK: odir2 file:~/org/coding.org

 [[odir2][link to file]]

 So in conclusion, if you want to use both bare file/directory links as
 well as headline/search links, you would have to define two separate
 link shortcuts.

 Yes, I'm aware of this. And this is the reason of my initial question.
 Should it really be necessary to specify two separate links to the
 same file when I want to both link to the file directly and link it
 with a search?

 Thus, this works:

   #+LINK: foo     file:/long/path/to/file/foo.org
   [[foo*heading search]]

 but this does not:

  #+LINK: foo     file:/long/path/to/file/foo.org
  [[foosearch]]

 I find the use of four : a bit strange, but I guess this is only a
 limit of my understanding a.t.m. In my view the first colon should be
 stating the start of the tag and the rest of the string the tag
 itself. This leaves three colons for the tag which in my view is one
 to many. But it seems to work. And this is what I'm scratching my head
 about.

 I also suspect a bug hidden somewhere, since headlines can be searched
 for but not text inside the document.

 Anyone got any input on this?
 /Gustav

Re: [O] View inherited DEADLINEs in agenda

[Gustav Wikström]

I second this.

Tt would seem logical (to me at least) that the deadline should be
inherited. I.e. in order to finish the project in time one has to also
finish the subtasks in time.

Right now the following property is illogical from this point of view:

  (setq org-agenda-dim-blocked-tasks 'invisible)

since it hides the parent in the agenda even if the date is in the past!

/Gustav

On Mon, Nov 7, 2011 at 2:16 PM, Fabrizio Chiarello
fabrizio.chiare...@ieee.org wrote:
 On Mon, Nov 07, 2011 at 01:22:31PM +0100, suvayu ali wrote:
 On Mon, Nov 7, 2011 at 13:19, Giovanni Ridolfi
 giovanni.rido...@yahoo.it wrote:
  Fabrizio Chiarello fabrizio.chiare...@ieee.org writes:
 
 
  I have many tasks with a DEADLINE, and I wish to have their subtasks to
  inherit such DEADLINE. To this aim, I set:
 
    (setq org-use-property-inheritance (quote (DEADLINE)))
 
 
  The problem is that the agenda only shows deadlines for the tasks that
  define them
 
  is DEADLINE  a property that can be inherited?
 
  would you please post an example file?

 I don't think DEADLINE is a property at all.


 In my org 7.7 manual, in section 7.2 Special properties, DEADLINE is
 defined as a (special) property.

 By the way, consider the following example:

 * TODO parent
  DEADLINE: 2011-12-31 Sat
 ** TODO child A
 ** TODO child B
   DEADLINE: 2011-11-30 Wed
 ** TODO child C

 In my workflow, to mark parent as DONE i have to complete child A,B
 and C. And it would be nice to have child A and C inherit the DEADLINE
 from the parent, and to show up in the agenda. Any idea?

 --
 Fabrizio Chiarello fabrizio.chiare...@ieee.org
 Photonics and Electromagnetics Group
 Department of Information Engineering
 University of Padova, Italy

 Intelligence is quickness to apprehend as distinct form ability, which
 is capacity to act wisely on the thing apprehended.
  -- Alfred North Whitehead

[O] Tags grouping

[Gustav Wikström]

Hello!

I just looked at
http://lumiere.ens.fr/~guerry/emacs-orgmode-gnu-hackers-meeting-2011.html and
wanted to express my excitement about the suggested tags grouping-future
improvement!

Just out of curiosity, what is the intended functionality? Should groups be
able to be groups of groups? Is there any thought of a kind of n-depth
search through these tags? i.e. given the following tags:

  #+TAGS: contexts: home work town.
  #+TAGS: work: project_A project_B.

would a search for the tag contexts return the headings with that tag,
return the headings of all the tags in the contexts group or would it
return all the tags at n depths?

This gives reason for some interesting thoughts i.m.o

Regards
Gustav

Re: [O] back to a multiple-file configuration

[Gustav Wikström]

I've also had this problem, but this related to the use of multiple
computers and more than one OS that all needed some specific tweaks to be
able to run. I'm also using org-babel for my init. A section from my
init.org follows below (warning for wall of text). Maybe this relates to
your thoughts and if so lets hope it adds some value.

8---8

** Initialization
*** Instructions
To make literate programming work i need to first bootstrap these
settings. I'm using this system on multiple machines and OS'es there
are some other initializations that also has to be made.

The initialization of the emacs-settings can be subdivided into two
main parts:
1. Bootstraping org-mode literate programming.
2. Loading source-files:
   1. OS-specific settings.
   2. Loading computer-specific settings.
   3. Loading the default settings.
   4. Loading computer-specific settings that overrides default
  settings.

This setup makes the system very dynamic, although it might become
difficult to maintain... We'll see about that though.

The code for the initialization follows in this file. It has to be
manually folded, the first time run anyways. (Running C-c C-v t in the
buffer whilst in emacs).
*** Bootstraping
The bootstraping of org-mode literate programing is taken from
http://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming,
with some minor modicifations.
#+begin_src emacs-lisp :tangle yes
  (setq dotfiles-dir
(file-name-directory
 (or (buffer-file-name) load-file-name)))

  (setq src-dir (expand-file-name src dotfiles-dir))
  (setq org-dir (expand-file-name
 lisp (expand-file-name
 org src-dir)))
  (setq org-contrib-dir (expand-file-name
 lisp (expand-file-name
 contrib (expand-file-name
.. org-dir
  (add-to-list 'load-path src-dir)
  (add-to-list 'load-path org-dir)
  (add-to-list 'load-path org-contrib-dir)
  (require 'org-install)
  (require 'ob-tangle)
#+end_src

After this, and given that i have org installed in the right folder
given the above, code written inside org-mode documents can be called
with the function =org-babel-load-file=. This is used in the next
section, [[*Loading of settings][Loading of settings]].
*** Code tangling hook
If any of the literate-files are updated, I want to automatically
compile them when they are tangled the next time.

This, however, does not work with symbolic links. Thus, my setup using
Dropbox to sync the files between my computers and symbolically
linking these files to my home-folders will not update automatically
anyways. This is (kind of) solved, see the next section.
#+begin_src emacs-lisp :tangle yes
  (add-hook 'org-babel-post-tangle-hook
  (lambda () (progn (eval-buffer (get-file-buffer (buffer-file-name)))
(byte-compile-file (buffer-file-name)
#+end_src
*** Code tangling function
This is my temporary solution to the symbolic-link problem discussed
in the section above. First the function delete all files that have
been previously tangled. After that it tangles all .org files in the
dotfiles-dir which also automatically compiles them due to the
[[*Code%20tangling%20hook][Code
tangling hook]].

This function can be called at any time.
#+begin_src emacs-lisp :tangle yes
  (defun gw/tangle ()
Tangles all the org-files in ~/.emacs.d/
  It is a help-function when one of the source-documents are updated
  in Dropbox and the local setup also needs to be updated.
(interactive)
(mapc (lambda (file)
(delete-file (expand-file-name file dotfiles-dir)))
  (directory-files dotfiles-dir nil .*\.\\(el\\|elc\\)$))
(mapc (lambda (file)
(find-file (expand-file-name file dotfiles-dir))
(org-babel-tangle)
(kill-buffer))
  (directory-files dotfiles-dir nil .*\.org$)))
#+end_src
*** Loading of settings
 Introduction
The loading process is one single step. It checks which OS is in use
and then load the files given this system.

Add files to the org-files list if more are needed.
#+begin_src emacs-lisp :tangle yes
  (let* ((org-files (list (expand-file-name emacs.org dotfiles-dir)
  (expand-file-name custom_end.org dotfiles-dir)))
 (windows-file (expand-file-name windows.org dotfiles-dir))
 (linux-file (expand-file-name linux.org dotfiles-dir))
 (custom-start (expand-file-name custom_start.org dotfiles-dir)))
(cond
 ((eq system-type 'windows-nt)
  (if (file-exists-p windows-file)
  (mapc #'org-babel-load-file (cons windows-file
(cons custom-start
org-files)
 ((eq system-type 'gnu/linux)
  (if (file-exists-p linux-file)
  (mapc #'org-babel-load-file (cons 

Re: [O] [bug] Symbol's function definition is void: org-pop-to-buffer-same-window

[Gustav Wikström]

Just wanted to add a line here. I also encountered this problem when
upgrading to Emacs 24.0.92 on windows and started using ELPA to install the
newest release of Org.

Sebastiens comments were helpful in finding the reason for this. It seems
to relate to the fact that everything handled by ELPA doesn't load until
after the init file. Org (from ELPA) is auto-loaded first when called by
the user but the settings done in the init file still remains from the
default org-mode installation causing problems as this.

I solved it by adding the function (package-initialize) to my init file
before calling org to do things for me. I don't know if this has any bad
side-effects yet.. But please point at a better solution if one comes to
mind.

Regards
Gustav

On Wed, Dec 7, 2011 at 9:45 PM, Sebastien Vauban wxhgmqzgw...@spammotel.com
 wrote:

 Hi all,

 Sebastien Vauban wrote:
  Nick Dokos wrote:
  Shelagh Manton shelagh.man...@gmail.com wrote:
  On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
  Shelagh Manton shelagh.man...@gmail.com wrote:
  On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
  On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
  In conditions which I consider unchanged (I speak of my emacs
 config
  file), with the latest Org-mode version, I now have the message:

 There was the original mistake: conditions were changed!

let*: Symbol's function definition is void:
org-pop-to-buffer-same-window
 
  when doing, for example, `C-c C-x C-j' to jump on the currently
  clocked item.
 
  Explicitly Loading `org-compat' does cure this problem... But we
  must miss a `require' somewhere, but where?  In `org.el' itself?
 
  I've just been bitten by this as well. requiring org-compat manually
 did
  nothing. My config files have not changed, just pulled latest
 org-mode,
  did a make clean and make. Suddenly my org-drill sessions don't work.
 
  Did you restart emacs?
 
  Yes. I did just then and same thing.
 
  Do you get the error with org-drill only or do you get it in the
 instances
  that Seb and Kenny Meyer report? If the former, it may be a bug with
  org-drill. Otherwise, I throw up my hands: I certainly cannot reproduce
 it.
 
  FYI:
 
  - I don't use .elc files.
 
  - I've recently upgraded to Emacs 24.0.91.1 on Windows -- not sure if the
problem appeared directly after, or a little bit before.
 
  - I began suspecting work that I could have done in a branch, and mixed
versions that way -- as I'm not yet familiar with git and switching
 between
branches.
 
  - I've deleted all my Org directory, and cloned a fresh one
 
  But it still occurs.
 
  Though:
 
  - Requiring org-compat does cure the problem.
 
  - I see calls to org-compat in every crucial Org file -- I don't
 understand
where it could be missing.
 
  - I still must try to dissecate my .emacs, or use a minimal Emacs config
 file
to see if it's reproducible that way.

 So, what was the problem in my case?  I've been trying to use the starter
 kit approach, and have a 2-file system:

 - ~/.emacs

 - ~/emacs/site-lisp/seb-conf.el (tangled from its .txt equivalent)
  which contains add-to-load-path calls for all packages (Org, Gnus, etc.)
  and all my customization.

 In ~/.emacs, I've replaced my previous:

(require 'seb-conf)

 by

(defun starter-kit-load ...)
(defun starter-kit-compile ...)
(starter-kit-load emacs/site-lisp/seb-conf.txt)

 Doing so, as it now calls `org-babel-load-file' (in `starter-kit-load'),
 and
 as that function is autoloaded in Emacs 24, Emacs was loading the Org
 version
 bundled with Emacs 24.0.91.1 -- that is, not the latest one, not the one
 in my
 Git working copy.

 This is very tricky to spot, IMHO, as all the checks done after Emacs has
 been
 started up will give partially false answers:

(locate-library org-compat) shows my git version

 as the load-path has been updated at the very beginning of loading
 `seb-conf'.

 In summary:

 - this is explained, and due to a mistake of mine;
 - this is quite tricky to detect;
 - this is a mix of different Org versions which causes the reported
 symptom.

 Best regards,
  Seb

 --
 Sebastien Vauban

[O] Bug due to org-startup-indented

[Gustav Wikström]

Hi!

When org-startup-indented is set to true I get a fatal error when using
'org-tree-to-indirect-buffer' on a heading then using org-cycle on the same
heading in the indirect-buffer.

This bug exists in org-version 7.7  7.8.02 in  emacs 24.0.92.1 on windows.

The following commands should reproduce the error:

M-: (setq org-startup-indented t)

open an org-mode file with some headlines and text.

C-c C-x b
C-x 0
tab

Anyone got any ideas on how to fix this?

Regards
Gustav

Re: [O] Bug due to org-startup-indented

[Gustav Wikström]

Yes, unfortunately it also breaks with -q. Using toggle-debug-on-error
does not work since emacs fails. It's not reporting any error before this
failure.

I've tried to debug what happens with debug-on-entry when calling
org-cycle. What I find is that after a call to overlay-put the program
breaks.

I've also tried the same procedure without enabling org-startup-indented
and then nothing bad happens. This single change in emacs -q results in the
reported behaviour for me.

Nicolas, are you using windows and emacs 24.0.92?

Regards
Gustav

2011/12/22 Nicolas Goaziou n.goaz...@gmail.com

 Hello,

 Gustav Wikström gustav.e...@gmail.com writes:

  When org-startup-indented is set to true I get a fatal error when using
  'org-tree-to-indirect-buffer' on a heading then using org-cycle on the
 same
  heading in the indirect-buffer.
 
  This bug exists in org-version 7.7  7.8.02 in  emacs 24.0.92.1 on
 windows.
 
  The following commands should reproduce the error:
 
  M-: (setq org-startup-indented t)
 
  open an org-mode file with some headlines and text.
 
  C-c C-x b
  C-x 0
  tab

 I cannot reproduce this on 7.8.02. Does it happen with -q? Does it
 happen on every Org file?

 Also, what is the error reported (with M-x toggle-debug-on-error)?


 Regards,

 --
 Nicolas Goaziou

Re: [O] Bug due to org-startup-indented

[Gustav Wikström]

Emacs crashes. It prompts with a question to attach gdb to debug. Not much
more, sorry to say. I'm not used to gdb though, so getting a trace for the
error was to big a task a.t.m.

This should be reproducible in windows using the same emacs-version though.
So I'll make sure to send a mail to emacs-devel.

Regards
Gustav

On Thu, Dec 22, 2011 at 6:13 PM, Nick Dokos nicholas.do...@hp.com wrote:

 Nicolas Goaziou n.goaz...@gmail.com wrote:

  Gustav Wikström gustav.e...@gmail.com writes:
 
   Yes, unfortunately it also breaks with -q. Using
 toggle-debug-on-error
   does not work since emacs fails. It's not reporting any error before
 this
   failure.
  
   I've tried to debug what happens with debug-on-entry when calling
   org-cycle. What I find is that after a call to overlay-put the
 program
   breaks.
  
   I've also tried the same procedure without enabling
 org-startup-indented
   and then nothing bad happens. This single change in emacs -q results
 in the
   reported behaviour for me.
  
   Nicolas, are you using windows and emacs 24.0.92?
 
  No, I'm using GNU/Linux and Emacs 24.0.92.
 
  Anyway, if emacs crashes, whatever may be the badness of Org indent
  code, the problem should be reported to the emacs devel mailing list
  instead: all that we may come up with here would be a hack.
 
 

 FWIW, I cannot reproduce it either (GNU Emacs 24.0.90.2
 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-10-27 and
 Org-mode version 7.8.02 (release_7.8.02.2.g490d6a)) so the Windoze part
 seems essential.

 I'm not sure how much of a development environment the OP has set up on
 his box, but if gdb is available, running emacs under gdb and getting a
 stacktrace to report to the emacs devel list seems like the best route
 forward.

 BTW, is there no error message at all? emacs just dies?

 Nick

[O] Inconsistent output when logging things between org-indent-mode set to on and off

[Gustav Wikström]

Hello again!

I've found an inconsistency in org depending on if org-indent-mode is
activated or not.

When org-indent-mode is inactive i get spaces in front of schedules and
deadlines under a headline, to match the start of the text of the headline
i presume. When org-indent-mode is active I do not see this behaviour.

Example when scheduling something with org-indent-mode on and then looking
at the plain text:

* Test
SCHEDULED: 2011-12-23 Fri

Example when scheduling something without org-indent-mode and then looking
at the plain text:

* Test
  SCHEDULED: 2011-12-23 Fri

I propose is to remove the whitespace when org-indent-mode is inactive
while scheduling things. Or make it a custom setting (maybe it already is?)
with the default to not add whitespace.

I do realize that this is a minor (really minor...) inconsistency, but it
bugged me and why not report it then?

Regards
Gustav

Re: [O] Inconsistent output when logging things between org-indent-mode set to on and off

[Gustav Wikström]

Hello!

2011/12/23 Nicolas Goaziou n.goaz...@gmail.com

 Hello,

 Gustav Wikström gustav.e...@gmail.com writes:

  When org-indent-mode is inactive i get spaces in front of schedules and
  deadlines under a headline, to match the start of the text of the
 headline
  i presume. When org-indent-mode is active I do not see this behaviour.
 
  Example when scheduling something with org-indent-mode on and then
 looking
  at the plain text:
 
  * Test
  SCHEDULED: 2011-12-23 Fri

 I don't have that behaviour. C-c C-s on an headline, with Org indent
 mode active, indent (virtually) the line like:

  * Test
SCHEDULED: 2011-12-23 Fri

 How do you obtain that?


If you disable org-mode after the scheduling and just looking at the plain
text you will see no indentation. This is good (according to me ;) )

Doing the same thing from the start, without org-indent-mode, gives another
result. This is the inconsistency I mention.

Kind regards
Gustav

Re: [O] Inconsistent output when logging things between org-indent-mode set to on and off

[Gustav Wikström]

 You may want to have a look at both `org-adapt-indentation' and
 `org-indent-mode-turns-off-org-adapt-indentation' variables.



Ahh, I'll look into them. Would be nice if they defaulted to the same
behavior but being able to customize it solves the problem for me at least.
=)

Kind regards and Merry Christmas
Gustav

[O] Doing calculations on clocktable

[Gustav Wikström]

Hello!



I'm trying to do some calculations on a clocktable in org-mode. But the way
times are displayed as strings with a colon between hours and minutest makes
it a bit difficult.. Does someone have any tips on how to overcome this
obstacle?


Best regards

Gustav

Re: [O] Doing calculations on clocktable

[Gustav Wikström]

Ah, great!

Thanks
/Gustav

2011/6/7 Michael Brand michael.ch.br...@gmail.com

 Hi Gustav

 There was a discussion about that here:
 http://thread.gmane.org/gmane.emacs.orgmode/39487

 Michael

 2011/6/7 Gustav Wikström gustav.e...@gmail.com:
  I'm trying to do some calculations on a clocktable in org-mode. But the
 way
  times are displayed as strings with a colon between hours and minutest
 makes
  it a bit difficult.. Does someone have any tips on how to overcome this
  obstacle?

[O] Durations and time values combined with the clock table..

[Gustav Wikström]

Hello!

Great work with the new functions allowing time calculations in the
spreadsheet! Just a few remarks.. The default format is MM:SS and hours have
to be qualified by using three positions HH:MM:SS.

Would it not be smart if the default for this calculations is the same as
the time-format for the clock table? There the default is HH:MM - i presume
due to the superfluity of seconds.

I do not really care which format is the default but being able to use the
time calculation on my org-mode-generated time-table, without having to
manually add :SS to each string, would be great..

And another question, negative time? I realize that this sounds strange from
a philosophical point of view... but being able to use minus in time-cells
would be neat.

As an example i've attached a dummy-timetable to this mail to illustrate my
point. Column 6 and Row 2, column 5  6 is generated by the time-function.

Clock summary at [2011-07-09 Sat 11:50]

| Headline | Time || Proj Δ | Task Δ |Proj |
|--+--++++-|
| *Total time* | *359:50* || 10 |   -285 |2:13 |
|--+--++++-|
| Project 1|   287:55 ||  05:00 ||   0 |
| Task 1   |  | 239:50 ||  10:00 | 4:09:50 |
| Task 2   |  |  48:05 ||   -300 |   43:05 |
| Project 2|71:55 ||  05:00 ||   0 |
| Task 1   |  |  47:50 ||  10:00 |   57:50 |
| Task 2   |  |  24:05 ||  -5:00 |   29:05 |
#+TBLFM: $6=$3+$5;T::@2$4='(apply '+ '(@3..@8));T::@2$5=vsum(@3..@8);T::@2
$6=vsum(@3..@8);T

Also, summations over multiple columns or rows does not seem to be working
=/

Regards Gustav

[O] Attachments and refiling

[Gustav Wikström]

Is it possible to make attachment-folders move with the headings when
refiling them to other locations?

Regards
Gustav

Re: [O] Attachments and refiling

[Gustav Wikström]

Hello Bastien!

To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling it
file 'a').

When marked with TODO item: done, headings in this file are archived to
another file called c:\temp\archive\agenda.org_archive ('b')

If i use C-c C-a to attach a file to a certain topic in 'a' and then refile
this topic to 'b', when done the attachment still resides in c:\temp\data
and will not be found when looking at the attachment in 'b'.

Thus my question is if it is possible to also refile the attachment so the
attachment-folder resides in c:\temp\archive\data and is avaliable in 'b'?

/Gustav

2011/7/15 Bastien b...@altern.org

 Hi Gustav,

 Gustav Wikström gustav.e...@gmail.com writes:

  Is it possible to make attachment-folders move with the headings when
  refiling them to other locations?

 I'm not sure what you mean.

 Can you give an example?

 --
  Bastien

Re: [O] Formal description of Org files

[Gustav Wikström]

Hi again list.

There was a discussion many years back about a formal description of
Org files [1]. In some way that might be achieved now in org-elements,
but that still is heavily bound to elisp.

So my question is; have there been more discussions of constructing
such a formal grammar? Maybe in EBNF form. I suspect getting every
aspect of Org mode into such a description would be difficult. But
imagine the possibilities. Tools such as ANTLR and similar would
straight away have a way of parsing Org mode. Org mode source files
could be parsed in many other languages, simplifying the process of
expanding Org mode to other platforms ( Android  iOS, web ).

Further rant; To me Org mode should be less about Emacs and more about
the source file format. Let Emacs be the main carrier, but let Org
mode also expand into other domains. One way to simplify this might be
to provide the formal description so that other tools might be easier
to develop based on this grammar.

(For me, the biggest limitation of Org mode is lacking tools to
utilize it on the run. The aim of this is thus to feed thoughts on how
to simplify processes that can expand Org mode into those more
mobile domains).

Best regards
Gustav

[1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01282.html

 Hi Jambunathan,

 Jambunathan K address@hidden writes:

  A simple worg page that collects the low hanging fruits to begin
  with will be a good but firm first step in this direction.

 Indeed.

 It's on my todo list, but not with a high priority for now.

 If you feel like starting it, please go ahead!

 --
  Bastien

Re: [O] Formal description of Org files

[Gustav Wikström]

Hi!

 Just curious: what is it you wish to do in a mobile environment.  I have
 everything I need with MobileOrg and running full emacs + org on an
 OpenPandora.  Obviously, your needs may be different than mine.

 (email composed on train offline on my OpenPandora in Emacs with gnus ;-)

 --
 : Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.3beta-372-gdd70cf

My wish is to be able to do mostly everything related to
task-tracking, scheduling, working with references and so on. General
GTD stuff. OpenPandora sounds neat, except it's not quite the standard
tool available out there ;-) And a general idea of Emacs in your
pocket is nice, except it's not really possible without a different UI
than the keyboard. So; what way forward with GTD in Emacs Org-mode
then, while still having the wish of it to be more accessible?

Thus the idea of a more formal (and parsable) grammar in a
standardized format. My hope is that it will make Org-mode more
general than it already is. As I said already; Org-mode to me is more
than Emacs. To think BIG, Org-mode grammar could be a standard for PIM
or GTD related software. To think a bit less big, it might help
developers create software with non-Emacs tools. By using the formal
grammar to work with Org-mode source documents in more accessible
ways. Maybe with UI's available through mobile phones or tablets (and
without the use of special schedules of read/write in Emacs to keep
the mobile system synced; MobileOrg).

I have to admit I might be overstating the importance of Org-mode
formal grammar with this goal in mind. I haven't used EBNF-parsers and
don't really know how powerful they can be. Reading about those things
give high hopes though.

Best regards
Gustav

Re: [O] Formal description of Org files

[Gustav Wikström]

Ah, yes. I've seen that and I really really admire your work. :-) What
I'm aiming at is something more standardised. Something that can be
used to generate language lexers and parsers in other programming
languages.. But, as I stated a moment ago in another mail to the list
- I don't really know the power of such a standardised grammar and of
what can be done if it was there.. I only envision the possibilities.
;-)

Best regards
Gustav

On Sun, Sep 21, 2014 at 2:43 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
 Hello,

 Gustav Wikström gustav.e...@gmail.com writes:

 There was a discussion many years back about a formal description of
 Org files [1]. In some way that might be achieved now in org-elements,
 but that still is heavily bound to elisp.

 So my question is; have there been more discussions of constructing
 such a formal grammar? Maybe in EBNF form. I suspect getting every
 aspect of Org mode into such a description would be difficult. But
 imagine the possibilities. Tools such as ANTLR and similar would
 straight away have a way of parsing Org mode. Org mode source files
 could be parsed in many other languages, simplifying the process of
 expanding Org mode to other platforms ( Android  iOS, web ).

 Further rant; To me Org mode should be less about Emacs and more about
 the source file format. Let Emacs be the main carrier, but let Org
 mode also expand into other domains. One way to simplify this might be
 to provide the formal description so that other tools might be easier
 to develop based on this grammar.

 (For me, the biggest limitation of Org mode is lacking tools to
 utilize it on the run. The aim of this is thus to feed thoughts on how
 to simplify processes that can expand Org mode into those more
 mobile domains).

 See

   (info (org) Org syntax)


 Regards,

 --
 Nicolas Goaziou

[O] Versioning and releases

[Gustav Wikström]

Hi!

The information of the current release of Org, and the link to the code is
not correct on the page orgmode.org.

As of this writing, the current version on orgmode.org says 7.9.4, but
looking at the link of the zip-archive, it will download version 7.9.3f.
And the release-notes doesn't mention a version 7.9.4.

On the same note. Looking in the README in the ZIP downloaded (7.9.3f that
is), the document states that the version is 7.9.1.

To me this seems like a lot of unnecessary confusion about what is the
current state of the software, and about which version I'm really
downloading.

Please have a look at the number fragmentation, make sure the links are
correct, and that the version history (http://orgmode.org/Changes.html) of
the releases are updated to a current status.

Kind regards
Gustav

[O] Filtering in org-agenda-filter-by-category

[Gustav Wikström]

Dear list,

I'd like to propose an addition to the function
org-agenda-filter-by-category; that is, the function called when pushing
 in an agenda.

As some might know adding a C-u in front of the command filters away the
current category instead of only listing it solemnly. I've made a change in
my source to allow multiple categories to be filtered away, instead of the
current functionality where only one category could be removed at a time.
This allows for multiple categories to be removed from the agenda. Very
simple, very effective.

Maybe some kind person could look at this and incorporate in the source?

(defun org-agenda-filter-by-category (strip)
  Keep only those lines in the agenda buffer that have a specific category.
The category is that of the current line.
  (interactive P)
  (if org-agenda-filtered-by-category
  (org-agenda-filter-show-all-cat)
(let ((cat (org-no-properties (get-text-property (point)
'org-category
  (cond
   ((and cat (not strip))
(org-agenda-filter-apply
 (list (concat + cat)) 'category))
   ((and cat strip)
(org-agenda-filter-apply
 (push (concat - cat) org-agenda-category-filter) 'category))
   ((error No category at point))

/Gustav

Re: [O] Filtering in org-agenda-filter-by-category

[Gustav Wikström]

Oh, ok. Didn't realize. I did the change a long time ago in my private
installation.

One difference in my version is the visibility of the filter in the
mode-line though. Doing C-u  multiple times adds every removed
category to the display in the mode-line.

I updated to 8.0.3 recently and did some changes to my version to
correspond to the evolution in the main repository. Here comes an
updated version:

(defun org-agenda-filter-by-category (strip)
  Keep only those lines in the agenda buffer that have a specific category.
The category is that of the current line.
  (interactive P)
  (if (and org-agenda-filtered-by-category
  org-agenda-category-filter)
  (org-agenda-filter-show-all-cat)
(let ((cat (org-no-properties (get-text-property (point) 'org-category
  (cond
   ((and cat strip)
(org-agenda-filter-apply
 (push (concat - cat) org-agenda-category-filter) 'category))
   ((and cat)
(org-agenda-filter-apply
 (setq org-agenda-category-filter
  (list (concat + cat))) 'category))
   ((error No category at point))

I also attached a diff between the above and the code in 8.0.3.

Regards Gustav

On Thu, Jun 27, 2013 at 4:48 PM, Bastien b...@gnu.org wrote:

 Hi Gustav,

 (please use plain text when posting code, other the code snippet
 is often mangled and not readable... thanks!)

 Gustav Wikström gustav.e...@gmail.com writes:

  I'd like to propose an addition to the function
  org-agenda-filter-by-category; that is, the function called when pushing
   in an agenda.
 
  As some might know adding a C-u in front of the command filters away the
  current category instead of only listing it solemnly. I've made a change in
  my source to allow multiple categories to be filtered away, instead of the
  current functionality where only one category could be removed at a time.

 Using C-u  multiple times to exclude entries from multiple categories
 works here.  What version of Org are you using (M-x org-version RET)?

 Thanks,

 --
  Bastien
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index fe2c743..e1fc4ec 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7307,12 +7307,15 @@ The category is that of the current line.
   org-agenda-category-filter)
   (org-agenda-filter-show-all-cat)
 (let ((cat (org-no-properties (get-text-property (point) 'org-category
-  (if (and cat (not (string=  cat)))
- (org-agenda-filter-apply
-  (setq org-agenda-category-filter
-(list (concat (if strip - +) cat)))
-  'category)
-   (error No category at point)
+  (cond
+   ((and cat strip)
+(org-agenda-filter-apply
+ (push (concat - cat) org-agenda-category-filter) 'category))
+   ((and cat)
+(org-agenda-filter-apply
+ (setq org-agenda-category-filter
+  (list (concat + cat))) 'category))
+   ((error No category at point))
 
 (defun org-find-top-headline (optional pos)
   Find the topmost parent headline and return it.

Re: [O] Bug: org-edit-special won't let me edit a latex snippet

[Gustav Wikström]

 Hi Nicolas,

 Nicolas Richard address@hidden writes:

  I'm at commit 830e231ef1da5c5a1ab760a6a059551841952610, and notice the
  following unexpected behaviour.
 
  Starting from emacs -Q -L ~/sources/org-mode/lisp/ :
  M-x org-mode
  insert l and hit SPC
  hit C-c '
 
  = user-error: No special environment to edit here

 Fixed, thanks!

 --
  Bastien

It seems to me that in 8.0.3 this is still an issue. Both latex and
quote blocks gives the response:

user-error: No special environment to edit here

Regards
Gustav

[O] Special Properties when matching for Properties in a search

[Gustav Wikström]

Hi list!

When matching for tags and properties using C-c / m there is the
option to match for Special Properties. Is there a complete list of
these special properties somewhere?

I was thinking that 7.2 Special Properties in the manual would be
that list, but then noticed a property possible to use for searches,
but not available in that list (the LEVEL-property). Is that property
just missing from there?

/Gustav

Re: [O] Special Properties when matching for Properties in a search

[Gustav Wikström]

Ok thanks!

As I brought this up, I might just as well provide a way of clarifying
this for the manual.

On Mon, Jul 1, 2013 at 12:04 AM, Bastien b...@gnu.org wrote:
 Hi Gustav,

 Gustav Wikström gustav.e...@gmail.com writes:

 When matching for tags and properties using C-c / m there is the
 option to match for Special Properties. Is there a complete list of
 these special properties somewhere?

 I was thinking that 7.2 Special Properties in the manual would be
 that list, but then noticed a property possible to use for searches,
 but not available in that list (the LEVEL-property). Is that property
 just missing from there?

 Mhhh... no, AFAIK the LEVEL property is a special-special property:
 you can use it in search constructs, but not in column view (which is
 the primary context for the 7.2 manual section.)

 But I'd say that's the only property missing here.  I'm short of good
 ideas on how to improve the manual here.

 --
  Bastien
Modified   doc/org.texi
diff --git a/doc/org.texi b/doc/org.texi
index 5f50ef6..64553e1 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -8045,15 +8045,18 @@ You may also test for properties (@pxref{Properties and 
Columns}) at the same
 time as matching tags.  The properties may be real properties, or special
 properties that represent other metadata (@pxref{Special properties}).  For
 example, the ``property'' @code{TODO} represents the TODO keyword of the
-entry.  Or, the ``property'' @code{LEVEL} represents the level of an entry.
-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
+entry and the ``propety'' @code{PRIORITY} represents the PRIORITY keyword of
+the entry.  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}.}.

+Except the @pxref{Special properties}, one other ``property'' can also be
+used. @code{LEVEL} represents the level of an entry. 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.
+
 Here are more examples:

 @table @samp

Re: [O] Bug: org-edit-special won't let me edit a latex snippet

[Gustav Wikström]

I haven't confirmed latex blocks but I trust your words.

I have been using C-c ' for quote blocks in the past and there is a
change as it's not working any more. I'm not against it though, just
curious. From what I understand now only source-blocks (including
example-blocks) and latex-blocks are (can be) edited by C-c '.  other
blocks (verse, center, quote) are not.

Now I know, thanks!

As a side-note: I like the ability to abort an edit now, small but
nice addition!)

Regards
Gustav

On Mon, Jul 1, 2013 at 12:29 AM, Bastien b...@gnu.org wrote:
 Hi Gustav,

 Gustav Wikström gustav.e...@gmail.com writes:

 It seems to me that in 8.0.3 this is still an issue. Both latex and
 quote blocks gives the response:

 user-error: No special environment to edit here

 I can use C-c ' in #+begin_latex environments correctly with latest
 Org (release_8.0.3-309), but I don't think C-c ' was ever supported
 for quote blocs.  Does the manual suggest otherwise?

 Best,

 --
  Bastien

Re: [O] Summary Blocks Time

[Gustav Wikström]

 Esben Stien address@hidden writes:

  Any pointers as to how I can do this?

 Got it;)

 (setq org-time-clocksum-format '(:hours %d :require-hours t
  :minutes :%02d :require-minutes t))

Good find Esben!

Actually, this recent change to how clocksum is formated also brings
another problem. And that is when doing calculations with time. We have the
flags t and T to be able to do calculations in tables on times, but
with the new format presenting days calculations are no longer returning
the correct values.

Best regards
Gustav

Re: [O] link interfering with brackets when abbreviated

[Gustav Wikström]

Hi, a user signing in. Although not involved in the development of this
piece of software I'm taking the opportunity to chime in anyway.

I'd like to give Nicolas Goaziou my support in this issue. It makes it much
simpler to understand, use, develop and maintain the software if it is
congruent. A well defined syntax, and tools that respect the rules of how
to parse it, will IMO be of big importance moving forward.

About the issue of two links on the same line.. From my perspective (for
what it's worth); Trying to open a link when not being inside a link with
the mark should give the same behaviour as trying to open a link when on a
headline. It is not certain which link is intended to be opened, so why not
give the user the options available instead of guessing? Set the scope to
parse to the current paragraph, to make a difference from calling C-c C-o
from the headline. That, to me, is the intuitive behaviour.

About the issue of links in comments (My opinion, for what it's worth):
It's a comment.. Expect it to behave as one. Worst case: copy the link and
paste it in the browser.

About the issue of links in properties: Wouldn't it be nice to allow this?
Maybe a future functionality to consider?


Best regards

Gustav Wikström

Re: [O] [BUG] cannot open menu when in an org buffer

[Gustav Wikström]

On Sat, Feb 4, 2012 at 6:46 PM, Nick Dokos nicholas.do...@hp.com wrote:

 suvayu ali fatkasuvayu+li...@gmail.com wrote:

  Hi,
 
  In a minimal Emacs session when I open _any_ org file and try to access
  the GUI menu with a mouse, I get the following back trace:
 
  Debugger entered--Lisp error: (void-function org-in-clocktable-p)
org-in-clocktable-p()
org-context()
(assq :todo-keyword (org-context))
 
  Switching to a non-org buffer (e.g. scratch) the problem disappears. Can
  someone take a look?
 

 Confirmed. If I add

 (require 'org-clock)

 to my minimal .emacs, it goes away. So it seems to be a missing dependency.

 Nick


I see the same problem when using org-goto with the latest revision of Org
(ELPA from 20120206). As Nick suggests, adding (require 'org-clock) fixes
the problem.

/Gustav

Re: [O] [babel] Editing 'quote' source blocks in artist mode

[Gustav Wikström]

Hi!

Just tried this and I can confirm both your bugs.

calling org-edit-special on the following line gives artist-mode (or
whatever it is called..):

: some text

calling org-edit-special inside the block gives ffap:

#+begin_quote
  some text
#+end_quote

/Gustav

On Thu, Feb 23, 2012 at 10:39 AM, Thorsten quintf...@googlemail.com wrote:

 Nick Dokos nicholas.do...@hp.com writes:

  Thorsten quintf...@googlemail.com wrote:
 
 
  Hi list,
  when I want to edit text inside a 'quote' source block, I find myself in
  picture/artist mode with wild key rebindings, e.g.:
 
 
 ,---
  | RET (translated from return) runs the command artist-key-set-point,
  | which is an interactive compiled Lisp function in `artist.el'.
  |
  | It is bound to RET.
  |
  | (artist-key-set-point optional ARG)
  |
  | Set a point for the current shape.  With optional ARG, set the last
 point.
 
 `---
 
  I don't think thats the intended behaviour? Shouldn't the edit buffer
  rather be in fundamental mode or something like this?
  To reproduce this:
 
  ,-
  | q tab
  | then inside the source block
  | C-c '
  `-
 

 My system data:
  GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
   of 2012-02-07 on arch
  Org-mode version 7.8.03
  Ma Gnus v0.2
 
 
  I can't reproduce it.
 
  Is C-c ' (still) bound to org-edit-special?

 Yes, it is.

  C-h f org-edit-special RET says
 
  ,
  | org-edit-special is an interactive Lisp function in `org.el'.
  |
  | (org-edit-special optional ARG)
  |
  | Call a special editor for the stuff at point.
  | When at a table, call the formula editor with
 `org-table-edit-formulas'.
  | When at the first line of an src example, call `org-edit-src-code'.
  | When in an #+include line, visit the include file.  Otherwise call
  | `ffap' to visit the file at point.
  `
 
  and I get the ffap behavior in a quote block (not that that's
 particularly
  attractive either).
 
  Did you try it emacs -q? Maybe it's a customization of yours.

 I tried that too, and again the edit buffer was in artist mode.
 I use the emacs24-starter-kit now, so not all customisations are mine.
 But I can't see anything that sets edit buffers in artist mode.

 Might that be related with openwith mode? I have that activated
 globally. But it shouldn't happen with emcas -q then.

 --
 cheers,
 Thorsten

Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]

[Gustav Wikström]

 For me, it makes a lot of sense to invert both, as Mathias is suggesting
 it.


+1

It would conform more to a sort of standard that way, (see
http://en.wikipedia.org/wiki/Lightweight_markup_language#Section_headers)


 Best regards,
  Seb

 --
 Sebastien Vauban



/Gustav

Re: [O] Too clumsy to promote/demote a region by multiple levels

[Gustav Wikström]

Hi!

Have you tried to use S-M-left and S-M-right? I't doesn't work with regions
but it works for a heading and all its subheadings at the same time.

/Gustav

On Sun, Mar 18, 2012 at 4:40 AM, James Harkins jamshar...@gmail.com wrote:

 Is there a reason why M-left and M-right (promote/demote tree headings)
 deactivate the selected region?

 That is, if I use C-space and move the point to select a number of
 headings, and I want to demote them by three levels, currently after
 hitting M-right, the region goes away -- so I actually have to do

 C-space (move the point) M-right
 C-space (move the point) M-right
 C-space (move the point) M-right

 But I would like to be able to do

 C-space (move the point) M-right M-right M-right

 Is this possible?

 I know that if there is no freestanding text underneath the headings, I
 could use C-x r t to add more *'s, but that breaks in a region where one or
 more lines are not headings.

 I tried (on a whim) C-u 3 M-right, but the universal argument is ignored
 here.

 Thanks,
 James


 --
 James Harkins /// dewdrop world
 jamshar...@dewdrop-world.net
 http://www.dewdrop-world.net

 Come said the Muse,
 Sing me a song no poet has yet chanted,
 Sing me the universal.  -- Whitman

 blog: http://www.dewdrop-world.net/words
 audio clips: http://www.dewdrop-world.net/audio
 more audio: http://soundcloud.com/dewdrop_world/tracks

Re: [O] [OT] Defining System, process, methodology and framework

[Gustav Wikström]

Not stupid, maybe a bit confusing ;) But thinking normally is, until you
reason it out. =) (And that's a process!)

I wanted to write something about your mail but didn't find anything of
relevance in my mind (In my system, to share your terminology ;) ).

Please share your insights afterwards!

/Gustav

On Fri, Apr 13, 2012 at 6:59 AM, Marcelo de Moraes Serpa 
celose...@gmail.com wrote:

 Well, looks like my text was kind of stupid and or confusing...

 Anyway, I started reading An Introduction To General Systems Thinking -
 surprisingly interesting book, and it's helping me answer most of those
 questions in deeper ways. I needed to do some additional investigation
 before starting to ask questions ;)

 I'll share the insights after I finish it,

 Thanks!

 Marcelo.


 On Tue, Apr 10, 2012 at 9:24 PM, Marcelo de Moraes Serpa 
 celose...@gmail.com wrote:

 Hi guys,

 I know there are quite a few smart brains around here, and I think this
 is valid discussion for this mailing list, even if OT.

 I'm not a cientist, nor work inside an academic environment. I'm just a
 regular guy trying to understand this world and making better use of my
 resources, specially time. For this, I have read dozens of books on
 personal productivity, including GTD, Making it All Work, and Work the
 System. All great books.

 I've started to notice a pattern though. All of them talk about systems
 and processes (and some might even use the word framework and methodology /
 or method), and although you can live by and be quite productivity if you
 apply the principles, I knew I had to understand in an even lower and basic
 level. I then asked myself What the heck is a system and what is the
 relationship it has with process, methodology and frameworks ?

 I found out, for example, that System and Process sometimes are used
 inter-changeably. So I went to google to try to find out the answer. The
 simplest answers simply say that a process is what a system is made of.
 It did not convince me.

 By reading the wikipedia article about System (
 http://en.wikipedia.org/wiki/System), I found out this paragraph under
 System concepts:

 Process and transformation process
 A system can also be viewed as a bounded transformation process, that
 is, a process or collection of processes that transforms inputs into
 outputs. Inputs are consumed; outputs are produced. The concept of input
 and output here is very broad. E.g., an output of a passenger ship is the
 movement of people from departure to destination.


 A system can viewed as a process? Hmm, confusing.

 Right now, my mental model basically says that a system is like
 blueprint with different components that communicate, and a process is what
 runs on it (or in on of its components). Framework is like a collection
 of systems and a methodology is basically akin to system (in my
 understanding).

 Why am I obsessing about this?

 The reason is systems thinking. I think it's a quite interesting mindset
 and way to perceive the world. By trying to view yourself and what
 surrounds you as systems (with sub-systems), it's much easier to document
 (them), get feedback, and improve, automating your life even further,
 understanding it more, and living better.

 For example, from this perspective I think, GTD is simply a product of an
 elevated point of view from the author David Allen. He simply viewed things
 systematically and documented them. That's why he says it's 'common-sense'.

 But before that, it would be nice to know exactly what a System is, and
 it's relationship with process, methodology and framework, in
 abstract terms.

  What do you think? I'm sure there are quite a few people here that might
 be crazy enough to have the same question, or perhaps, I'm just too crazy.
 Let me know, any insights very much appreciated.

 Cheers,

 - Marcelo.

Re: [O] Inverse matching with '/' in agenda view?

[Gustav Wikström]

Hi!

I'd like to follow this up with a feature request on inverse matching on
'', since the inverse of the tag-matching was resolved so fast ;)

It would be neat to be able to hide categories in the agenda as well.

Kind regards
Gustav

On Thu, Apr 19, 2012 at 2:57 PM, James Harkins jamshar...@gmail.com wrote:

 At Thu, 19 Apr 2012 07:16:34 -0400,
 Bernt Hansen wrote:
  / - TAB Docs RET

 Oh, that's great. I missed that one.

 Thanks!
 James


 --
 James Harkins /// dewdrop world
 jamshar...@dewdrop-world.net
 http://www.dewdrop-world.net

 Come said the Muse,
 Sing me a song no poet has yet chanted,
 Sing me the universal.  -- Whitman

 blog: http://www.dewdrop-world.net/words
 audio clips: http://www.dewdrop-world.net/audio
 more audio: http://soundcloud.com/dewdrop_world/tracks

Re: [O] Inverse matching with '/' in agenda view?

[Gustav Wikström]

Hi!


Den 19 apr 2012 16:44 skrev Michael Brand michael.ch.br...@gmail.com:
 ...
 Is a resolve in the past enough fast? ;-)

It sure is! ;-)

Thanks

/Gustav

Re: [O] unintended strike-through in table

[Gustav Wikström]

On Sat, Apr 21, 2012 at 1:13 AM, Bastien b...@altern.org wrote:

 Hi Skip,

 Skip Collins skip.coll...@gmail.com writes:

  I see little reason to continue to support +strike-through+ text.
  Perhaps the simplest solution would be to deprecate stricken text and
  disable it by default, allowing for an option to turn it on for
  backward compatibility.

 I agree.  If no one object, I will make this change soon.

 Although I cannot recall myself having used strike-through text I wonder
what the reason is for removing the functionality? Is it just this, that it
(probably) isn't used much? Not a good argument in my book (especially due
to the uncertainty in usage). Would it not be better to fix the problem at
hand? Maybe by changing the symbol since + seems overloaded, would not - be
a better choice?

On a side-note, what is the intended behavior of bold, italic,
strike-through etc. regarding line-breaks? Since a single long line has the
same meaning in org as multiple consecutive short lines I think the
markup-elements above also should support multiple lines of text (but not
be valid between paragraphs)

Regards Gustav

Re: [O] Scheduled TODO's with DIARY-STYLE sexp entries breaks agenda

[Gustav Wikström]

Hi Bastien,

I'm using Org-mode version 7.8.10 (Downloaded through ELPA 2012-05-17).

Regards
Gustav

On Sat, May 19, 2012 at 9:50 AM, Bastien b...@gnu.org wrote:
 Gustav Wikström gustav.e...@gmail.com writes:

 I don't know if there is an easy fix for this but it's bugging me so
 I'll report it to the list.

 Please report what Org version you are using.

 Thanks,

 --
  Bastien

[O] [Orgmode] Re: [PATCH] org-display-inline-images to reduce image size

[Gustav Wikström]

Hi!

I was just searching the web for a way to scale inline images and
found this thread in the archives.. How did it go with it? Was it
tested and not approved or why is it that the patch is not applied?
(Patch: http://patchwork.newartisans.com/patch/526/)

Regards Gustav

 From:  Vladimir Alexiev
 Subject:   [Orgmode] Re: [PATCH] org-display-inline-images to reduce 
 image size
 Date:  Mon, 10 Jan 2011 08:31:17 + (UTC)
 User-agent:Loom/3.14 (http://gmane.org/)

 How to avoid line breakage in the patch?
 Some source lines are naturally 80 chars and I wouldn't like to shorten them.
 I posted from the web 
 (http://post.gmane.org/post.php?group=gmane.emacs.orgmode)
 I guess I should get an account and post from a real mail client?

 Furthermore, the Comments at the patchwork server
 (http://patchwork.newartisans.com/patch/526/)
 mess up the patch, though the patch itself is ok
 (http://patchwork.newartisans.com/patch/526/raw/)

[O] [Orgmode] [Patch] Information about visibility cycling to the manual

[Gustav Wikström]

Hi,

I've added some information to the documentation about show-children.
Patch is attached.

/Gustav
commit 6f88cf724419af9d0ace6f8950245be176fcf0f0 (HEAD, refs/heads/origin-master)
Author: Gustav Wikström gustav.e...@gmail.com
Date:   Tue May 29 18:15:34 2012 +0200

Documentation: Add some information to the visibility cycling chapter

* org.texi (visibility cycling): Adding a section about the command 
show-children (derived from outline-mode)

TINYCHANGE

Modified   doc/org.texi
diff --git a/doc/org.texi b/doc/org.texi
index a5d4bf6..31db054 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -1227,6 +1227,16 @@ beginning of the buffer and the first line is not a 
headline, then
 option @code{org-cycle-global-at-bob}.}.  Also when called with a prefix
 argument (@kbd{C-u @key{TAB}}), global cycling is invoked.

+@cindex subtree cycling
+@cindex folded, subtree visibility state
+@cindex children, subtree visibility state
+@orgcmd{C-c @key{TAB},show-children}
+
+The cursor must be on a headline for this to work.  Show all direct
+subheadings of this heading.  A numeric prefix argument determines how many
+levels below the current level should be shown.  Show-children is a function
+defined in outline-mode.
+
 @cindex global visibility states
 @cindex global cycling
 @cindex overview, global visibility state

[O] Escaping of non-ascii characters in links

[Gustav Wikström]

Hi list!

Is there a variable that makes org-mode not escape non-ascii characters in
links? Right now when I'm entering a link with eg. an ö in it (or a space
for that matter!) the link is automatically converted and the link
description contains the non-ascii keyword.

Example: Using C-c C-l to enter a link to ö gives:

[[%C3%B6][ö]]

I would like to not have the choice of normal behavior even if non-ascii
characters are used (giving me [[ö]]). Is there one at the moment? If not,
consider this a feature request =)

Regards
Gustav

[Orgmode] Org capture templates - file paths

[Gustav Wikström]

Hello!

I'm having some trouble with org-capture. Could someone explain to me why
the following is not working? (And what to do to get it to work..)

Code:

(defvar my-gtd-inbox-file (concat my-gtd-root inbox.org))
;;; Capture templates
(setq org-capture-templates
  '((n Note entry (file my-gtd-inbox-file)
* %?\n %i\n %a)
 (j Journal entry (file+datetree my-gtd-journal-file)
 * %?\nEntered on %U\n %i\n %a)))

End code.

what I've figured so far is that variables cannot be used in templates... Is
there some workaround for this, or could it possibly be implemented? I need
it since i'm on multiple systems where paths to the same files might differ
depending on the system in use...

Regards Gustav Wikström
___
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 mode manual written in? texinfo?

[Gustav Wikström]

I was just wondering... Is the manual written in texinfo markup, or is there
some obscure .org file behind the manual still?

If it really is written in texinfo, is this not a shortcoming? Org mode is
capable of generating html and pdf etc. Why not use it for the manual then
to set the example and show its powers!?

/Gustav
___
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] Org mode manual written in? texinfo?

[Gustav Wikström]

I guess there are two reasons for this then. The first being that there is
no easy Org-mode to texinfo conversion. The second reason being that
Org-mode still has less functionality than texinfo in terms of functionality
for document writing.

The reason for my post was simple. My thought was that if a tool is created
with the capability of doing a certain task, it would seem advantageous to
also be using that capability for the needs of the tool itself. Maybe in
some distant future there will be support for nice indexes (and appendices!
My personal request) also in Org-mode leading to someone writing a org -
texinfo parser.

Regards Gustav

2010/8/30 Thomas S. Dye t...@tsdye.com

 Aloha Gustav,

 Theoretically, one could export from org to docbook, then output texinfo
 with docbook2x.  I tried this a while ago but couldn't get docbook2x to work
 with minimal effort and gave up.

 Tom


 On Aug 29, 2010, at 9:12 AM, Gustav Wikström wrote:

  I was just wondering... Is the manual written in texinfo markup, or is
 there some obscure .org file behind the manual still?

 If it really is written in texinfo, is this not a shortcoming? Org mode is
 capable of generating html and pdf etc. Why not use it for the manual then
 to set the example and show its powers!?

 /Gustav
 ___
 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



___
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] Last workday of month scheduling

[Gustav Wikström]

Hello!



I have one modest question to ask:



Is there a way in Org-mode to schedule a task so it appears the last workday
(i.e. not Saturday or Sunday) of the month, each month?



Best Regards

Gustav Wikström
___
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] ASCII export - AutoFill

[Gustav Wikström]

Hello!

Just a silly question... If I want to export to ASCII from my Org-file, and
want the exported ASCII to have all the paragraphs restricted to, say, 80
columns - Is there a nice way  to do this without first converting all the
paragraphs in the org-file?

In essence, Org-mode file:


* Heading


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc varius
scelerisque nisi, ac tristique tellus porta ut. Cras porta, tortor eget
malesuada pellentesque, lorem enim accumsan mauris, quis imperdiet risus
velit id ante. Quisque porttitor ornare turpis non aliquam.

Exported ASCII-text file:

* Heading

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc
varius scelerisque nisi, ac tristique tellus porta ut. Cras
porta, tortor eget malesuada pellentesque, lorem enim accumsan
mauris, quis imperdiet risus velit id ante. Quisque porttitor
ornare turpis non aliquam.

Best regards
Gustav
___
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] ASCII export - AutoFill

[Gustav Wikström]

Aha, I see. Well, my elisp is not that evolved either so my attempts would
probably be even less likely to succeed!

Regards Gustav

2010/11/25 Eric S Fraga ucec...@ucl.ac.uk

 Gustav Wikström gustav.e...@gmail.com writes:

  Hello!
 
  Just a silly question... If I want to export to ASCII from my
  Org-file, and want the exported ASCII to have all the paragraphs
  restricted to, say, 80 columns - Is there a nice way  to do this
  without first converting all the paragraphs in the org-file?

 Not a silly question at all!  Having looked at the code, the short
 answer is *no*, unfortunately.  The only wrapping the ascii exporting
 does is on /notes/ generated by the conversion of links.

 It would be a nice feature to have, however...  I had a look at the
 fill.el code and I'm sure some of it (fill-region) could be used quite
 nicely within org-ascii.el but my emacs-lisp abilities are not
 sufficiently good enough for me to attempt changing the code.  Sorry.

 --
 : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 23.2.1
 : using Org-mode version 7.3 (release_7.3.130.g9cc1)

___
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 variables in text

[Gustav Wikström]

Hello!

Is there a easy way to make use of personal variables inside a text?

Lets say that I want to use a number in my text and know that it will change
in the future. Instead of going through the whole document I just put a
variable in the beginning of the document and use the variable name, which
is transformed to the right number when the document is exported.

I know about the #+LINK in-buffer setting. But I'm looking for a simple
variable without making it a link. Is this possible?

Best regards
Gustav Wikström
___
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: UTF-8 characters in #+LINK does not work [7.4]

[Gustav Wikström]

Using characters such as å,ä,ö does not work when using #+LINK

example:

`#+LINK: Färdmedel file:~/färdmedel.org http://xn--frdmedel-0za.org'

this does not work, however the following does:

`#+LINK: Fardmedel file:~/färdmedel.org http://xn--frdmedel-0za.org'

Is there an easy fix?

Emacs  : GNU Emacs 23.2.1 (i386-mingw-nt6.1.7600)
 of 2010-05-08 on G41R2F1
Package: Org-mode version 7.4
___
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: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again! The FSA-assignment is now complete. New patches are attached
and comments below.

On Sat, Jan 31, 2015 at 9:41 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:

 I suppose an FSF-assignment signature is needed before it can be
 included.

 Indeed.

Marked as done now, as stated above :-)

 - Grouptags don't have to be unique on a headline if added with [ ]
   instead of with { }: , | #+TAGS: [ group : include1 included2 ]
   `

 I'd rather not introduce yet another syntax for group tags. IIUC, the
 current one (with curly braces) can be extended.

 Also, I don't get the have to be unique on a headline part.

The reason for the use of [ ] is because { } already has another purpose
- it is used to make the tags within { } exclusive.

this example

,
| #+TAGS: { group : include1 include2 }
`

will only allow one of the tags on any specific headline. [ ] solves
this. Note that grouptags doesn't care if { } or [ ] is used. The only
difference is the exclusiveness. I.e both

,
| #+TAGS: [ group : include1 include2 ]
| #+TAGS: { group : include1 include2 }
`

will work. With some limitations on the second example due to the way {
} works since before.

   A new variable is defined `ORG-GROUP-TAGS-MAX-DEPTH' that is used
   to limit the depth of recursion when expanding tags. It defaults to
   2.

 I don't think this variable is necessary. However, a check for
 circular inclusions would be necessary.

Indeed. The variable is removed and the function `org-tags-expand' now
handles circular definitions with grace ;-)

Best regards
Gustav Wikström


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: Binary data


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-org-Nesting-grouptags.patch
Description: Binary data

[O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi!

My name is Gustav and I'm a user of Orgmode since some time (..years)
now. I've made minor contributions to this list before but mostly in
discussions.

This time I've made some changes in the code. More specifically in how
tag groups function and would like them to be included in Orgmode.

I suppose an FSF-assignment signature is needed before it can be
included. I'll start with that process if this is something the
community can agree to include. But until then; please take it for a
ride. I've attached a file which can be used to test the
functionality. There are a few more things to do too; Like updating
the manual and improving the tag-selection UI. If you have the
interest, please look into that ;-). I suspect some might have
comments on the code too. The tag-expansion function, for example,
(`ORG-TAGS-EXPAND') has grown a bit..

The changes are listed below:

- Grouptags don't have to be unique on a headline if added with [ ]
  instead of with { }:
  ,
  | #+TAGS: [ group : include1 included2 ]
  `

- Grouptags can have regular expressions as sub-tags. The regular
  expressions in the group must be marked up within { }. Example use:

  ,
  | #+TAGS: [ Project : {^P@.+} ]
  `

  Searching for the tag Project will now list all tags also including
  regular expression matches for ^P@.+. it is good, for example, if tags
  for a certain project are tagged with a common project-identifier, i.e.
  P@2014_OrgTags.

- Grouptags are not filtered when setting up tags (in
  `ORG--SETUP-PROCESS-TAGS'). This means they can exist multiple times
  in org-tag-alist. Will be usable if nesting of grouptags is ever
  to become reality.

  There is a slightly annoying side-effect when setting tags, in that a
  tag which is both a part of a grouptag and is a grouptag of its own will
  get multiple key-choices in the selection-UI. The whole selection-UI
  could use some refactoring. Especially with the addition of the point
  below.

- Nesting grouptags. Allowing subtags to be defined as groups
  themselves.

  ,
  | #+TAGS: [ Group : SubOne(1) SubTwo ]
  | #+TAGS: [ SubOne : SubOne1 SubOne2 ]
  | #+TAGS: [ SubTwo : SubTwo1 SubTwo2 ]
  `

  Should be seen as a tree of tags:
  - Group
- SubOne
  - SubOne1
  - SubOne2
- SubTwo
  - SubTwo1
  - SubTwo2
  Searching for Group should return all tags defined above.

  A new variable is defined `ORG-GROUP-TAGS-MAX-DEPTH' that is used to
  limit the depth of recursion when expanding tags. It defaults to 2.

- Filtering in the agenda on grouptags should filter also subcategories.
  Exception if filter is applied with a (double) prefix-argument.

  Filtering in the agenda on subcategories should not filter the above
  levels.

  If a grouptag contains a regular expression the regular expression is
  also used as a filter.

- `ORG-AGENDA-REDO' expands the tag-filters when redrawing the agenda.
  It might be counterintuitive if a filter was applied with a double C-u
  argument just before to *not* expand tags in the filter.

- Some bugs relating to grouptags have been fixed.
  - When filtering on tags in the agenda after using a grouptag, it no
longer complains about wrong type.
  - Regular expressions with tag-names inside are not affected by
group-expansion. Example:

,
| #+TAGS: { Tag : Tag1 Tag2 }
| search expression: {Tag.*} now works predictably.
`

I look forward to hearing what you think!

Best regards
Gustav


Testfile.org
Description: Binary data


0001-Grouptags-not-unique-and-can-contain-regular-exp.patch
Description: Binary data


0002-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-Nesting-grouptags.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

 step, would you mind adding tests
 for this?

Added a few now. Actually found an error in the way regexps were
matched and filtered due to the added tests. So, good point. The
errors are fixed ofc.

Fixed patches are attached,

Best regards
Gustav Wikström


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: Binary data


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-org-Nesting-grouptags.patch
Description: Binary data


0004-org.texi-Complement-info-for-group-tags.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

 
 The following is clearer
 
   @lisp
   (setq org-tag-alist '((:startgrouptag)
 (@@read)
 (:grouptags)
 (@@read_book)
 (@@read_ebook)
 (:endgrouptag)))
   @end lisp
 

Indeed

 However, shouldn't this example apply to the one above? (e.g.., with
 Control : Context Task tag line)?

Indeed again! 

 
  +Searching for the tag Project will now list all tags also including regular
  +expression matches for P@@.+.  Similar for tag-searches on Vision, Goal and
  +AOF.  This can be good for example if tags for a certain project is tagged
  +with a common project-identifier, i.e. P@@2014_OrgTags.
 
 @samp{Project} @samp{Vision}... @samp{P@@2014_OrgTags}.
 
 This all looks very nice.

Thx!

 As a final step, would you mind adding tests
 for this?

Added a few now. Actually found an error in the way regexps were matched and 
filtered due to the added tests. So, good point. The errors are fixed ofc.

Fixed patches are attached,

Best regards
Gustav Wikström


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: 0001-org-Grouptags-not-unique-and-can-contain-regexp.patch


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: 0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch


0003-org-Nesting-grouptags.patch
Description: 0003-org-Nesting-grouptags.patch


0004-org.texi-Complement-info-for-group-tags.patch
Description: 0004-org.texi-Complement-info-for-group-tags.patch

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Nicolas Goaziou m...@nicolasgoaziou.fr wrote:

 As a final step, would you mind preparing an entry in ORG-NEWS? I think
 most of it can be extracted from your commit messages.

I don't mind. Wrote a few lines and the patch is attached!

Best regards
Gustav


0001-ORG-NEWS-Mention-change-in-grouptags-functionality.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi, and thanks for the extensive comments!

I've fixed the issues raised (IMO), and new patches are attached. I've
added a patch for documentation also.

 ,
 | #+TAGS: { group : include1 include2 }
 `

 will only allow one of the tags on any specific headline. [ ] solves
 this. Note that grouptags doesn't care if { } or [ ] is used. The only
 difference is the exclusiveness. I.e both

 ,
 | #+TAGS: [ group : include1 include2 ]
 | #+TAGS: { group : include1 include2 }
 `

 will work. With some limitations on the second example due to the way {
 } works since before.

 OK, but is it really needed? What is the point of having two tags of the
 same group (or, if we consider nested group tags, the same set of
 siblings) at the same time?

I'd say it's an unnecessary limitation if group tags have to be
exclusive on a headline. The more general case should be allowed and I
can see use-cases for it.

If you, for example, want to create a taxonomy of your tags and a part
of your taxonomy is this:

#+TAGS: [ CS : DB OS Software Versioning Programming BI ]

What reason is there for Org mode to limit me to only choosing one of
the above? Lets say I find an article on the web and want to create a
node in my org-mode repository about it. Maybe linking the article and
adding a few thoughts. The fictive article may be called the
importance of good database-design in Business intelligence. It seems
two tags of the above would fit just fine; DB  BI.

Best regards
Gustav


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: Binary data


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-org-Nesting-grouptags.patch
Description: Binary data


0004-org.texi-Complement-info-for-group-tags.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi,

Taking your comments and improving the first patch a bit resulted in the 
attached one. It replaces the previous. Using string-prefix-p and 
string-suffix-p solves the out of index problem in the substrings.

BR
Gustav 

> -Original Message-
> From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]
> Sent: Wednesday, November 25, 2015 15:53
> To: Gustav Wikström <gus...@whil.se>
> Cc: emacs-orgmode@gnu.org; sgeorgii . <sgeor...@gmail.com>
> Subject: Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
> regexps
> 
> Gustav Wikström <gus...@whil.se> writes:
> 
> > Hmm, since the error was thrown when trying to look at indexes outside
> > of the string in (substring ... ), I don't see how isregexp can be
> > left as is. We have to make sure the substring-code is not evaluated
> > if the tag is empty. What am I missing?
> 
> Nothing, I was clear as mud.
> 
>   (cond
>((string= "" tag) (setq f1 '(not tags)))
>((and (equal "{" ...)
>  (equal "}"...))
> ...)
>(t ...))
> 
> Or even
> 
>  ((and (string-prefix-p "{" ...)
>(string-suffix-p "}" ...)))
> 
> on master.
> 
> Regards,


0001-org-agenda-Filter-empty-tags.patch
Description: 0001-org-agenda-Filter-empty-tags.patch

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi, see below

> >
> > * lisp/org-agenda.el (org-agenda-filter-make-matcher-tag-exp): Deal with
> >   the case when the user provided an empty string to filter or exclude
> >   rows from the agenda.
> 
> Please provide a reference to the discussion that lead to this patch.

The reference being the subject-line and date of the mail from sgeorgii?

> 
> >(let* ((tag (substring x 1))
> > -(isregexp (and (equal "{" (substring tag 0 1))
> > +(isemptystring (string= "" tag))
> > +(isregexp (and (not isemptystring)
> > +   (equal "{" (substring tag 0 1))
> > (equal "}" (substring tag -1
> >  regexp)
> > (cond
> >  (isregexp
> >   (setq regexp (substring tag 1 -1))
> >   (setq f1 (list 'org-match-any-p regexp 'tags)))
> > +(isemptystring
> > + (setq f1 '(not tags)))
> >  (t
> >   (setq f1 (list 'member (downcase tag) 'tags
> > (when (eq op ?-)
> 
> Nitpick time:
> 
> You don't need isemptystring if it is the first branch in cond
> 
>   (cond
>((string= "" tag) (setq f1 '(not tags)))
>(isregexp ...)
>(t ...))
> 
> Obviously, in that case, you don't need to change isregexp at all.

Hmm, since the error was thrown when trying to look at indexes outside of the 
string in (substring ... ), I don't see how isregexp can be left as is. We have 
to make sure the substring-code is not evaluated if the tag is empty. What am I 
missing? 

> 
> 
> Regards,
> 
> --
> Nicolas Goaziou0x80A93738

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi!

Indeed, I do get the same error as you. I'll look into it a bit. Not sure if 
the behavior is documented though.

As a workaround for you sgeorgii (and for everyone else with this problem I 
suppose :-) ), you can exclude tags instead of filtering. The behavior is 
similar except instead of only showing the rows with the provided tag, it 
excludes all rows with the provided tag. If you provide a regular expression, 
eg. {.*}, then all rows with tags are hidden from the agenda-view.

So, to recreate with commands, what I just tried to describe with words:
M-x org-agenda
\ (exclude) (alternatively use the combination of / (filter) - (exclude) )
 (exclude by tag)
{.*}


Voila!

Best regards
Gustav

> -Original Message-
> From: sgeorgii . [mailto:sgeor...@gmail.com]
> Sent: Wednesday, November 25, 2015 08:51
> To: gustav.e...@gmail.com; m...@nicolasgoaziou.fr; emacs-
> orgm...@gnu.org
> Subject: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
> 
> Dear Gustav, Eric,
> 
> 
> I was referred to your subject discussion in respect to my problem:
> 
> With new version of org-mode I am now unable to filter agenda to show only
> non-tagged items:
> 
> 
> > "sgeorgii ."  writes:
> >
> >> Hello!
> >>
> >> Having installed latest org 8.3.2 I am now having the subject problem:
> >>
> >> M-x org-agenda
> >>
> >> When in agenda:
> >>
> >> / (filter)
> >>
> >> TAB (filter by tag)
> >>
> >>  (without entering any tags for "Tag:" question)
> >>
> >> Before this gave me agenda view filtered to show only non-tagged items.
> >> I believe this was right and just fine.
> >>
> >> Now I have error:
> >>
> >> Debugger entered--Lisp error: (args-out-of-range "" 0 1)
> >>   org-agenda-filter-make-matcher-tag-exp(("+") 43)
> >>   org-agenda-filter-make-matcher(("+") tag t)
> >>   org-agenda-filter-apply(("+") tag t)
> >>   org-agenda-filter-by-tag(nil)
> >>   call-interactively(org-agenda-filter-by-tag nil nil)
> >>   command-execute(org-agenda-filter-by-tag)
> 
> >
> > I believe 6c6ae99 (org-agenda: Filtering in the agenda on grouptags,
> > 2015-01-24) changed this behavior.  The discussion about these changes
> > is here (sorry, the gmane web interface is down for me):
> > https://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00618.html
> >
> > org-agenda-filter-by-tag should be fixed to handle the empty tag case
> > that causes the error above, either by behaving as before or by giving
> > a clear error.  I haven't looked closely enough at the changes or the
> > discussion to guess whether that commit intended to preserve the empty
> > tag behavior you were relying on.  Is that behavior documented anywhere?
> >
> > --
> > Kyle
> 
> 
> Any help?

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again,

Patch attached. 

If someone could apply it I'd be glad.

Best Regards
Gustav

> -Original Message-
> From: sgeorgii . [mailto:sgeor...@gmail.com]
> Sent: Wednesday, November 25, 2015 12:05
> To: Gustav Wikström <gus...@whil.se>
> Cc: m...@nicolasgoaziou.fr; emacs-orgmode@gnu.org
> Subject: Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
> regexps
> 
> Indeed, the {.*} works. Thank you!
> 
> If we could still use the empty parameter when filtering by "no tags"
> it would be really sweet :)
> 
> On 25 November 2015 at 13:26, Gustav Wikström <gus...@whil.se> wrote:
> > Hi!
> >
> > Indeed, I do get the same error as you. I'll look into it a bit. Not sure 
> > if the
> behavior is documented though.
> >
> > As a workaround for you sgeorgii (and for everyone else with this problem I
> suppose :-) ), you can exclude tags instead of filtering. The behavior is 
> similar
> except instead of only showing the rows with the provided tag, it excludes all
> rows with the provided tag. If you provide a regular expression, eg. {.*}, 
> then all
> rows with tags are hidden from the agenda-view.
> >
> > So, to recreate with commands, what I just tried to describe with words:
> > M-x org-agenda
> > \ (exclude) (alternatively use the combination of / (filter) -
> > (exclude) )  (exclude by tag) {.*} 
> >
> > Voila!
> >
> > Best regards
> > Gustav
> >
> >> -Original Message-
> >> From: sgeorgii . [mailto:sgeor...@gmail.com]
> >> Sent: Wednesday, November 25, 2015 08:51
> >> To: gustav.e...@gmail.com; m...@nicolasgoaziou.fr; emacs-
> >> orgm...@gnu.org
> >> Subject: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
> >> regexps
> >>
> >> Dear Gustav, Eric,
> >>
> >>
> >> I was referred to your subject discussion in respect to my problem:
> >>
> >> With new version of org-mode I am now unable to filter agenda to show
> >> only non-tagged items:
> >>
> >>
> >> > "sgeorgii ." <sgeor...@gmail.com> writes:
> >> >
> >> >> Hello!
> >> >>
> >> >> Having installed latest org 8.3.2 I am now having the subject problem:
> >> >>
> >> >> M-x org-agenda
> >> >>
> >> >> When in agenda:
> >> >>
> >> >> / (filter)
> >> >>
> >> >> TAB (filter by tag)
> >> >>
> >> >>  (without entering any tags for "Tag:" question)
> >> >>
> >> >> Before this gave me agenda view filtered to show only non-tagged items.
> >> >> I believe this was right and just fine.
> >> >>
> >> >> Now I have error:
> >> >>
> >> >> Debugger entered--Lisp error: (args-out-of-range "" 0 1)
> >> >>   org-agenda-filter-make-matcher-tag-exp(("+") 43)
> >> >>   org-agenda-filter-make-matcher(("+") tag t)
> >> >>   org-agenda-filter-apply(("+") tag t)
> >> >>   org-agenda-filter-by-tag(nil)
> >> >>   call-interactively(org-agenda-filter-by-tag nil nil)
> >> >>   command-execute(org-agenda-filter-by-tag)
> >>
> >> >
> >> > I believe 6c6ae99 (org-agenda: Filtering in the agenda on
> >> > grouptags,
> >> > 2015-01-24) changed this behavior.  The discussion about these
> >> > changes is here (sorry, the gmane web interface is down for me):
> >> > https://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00618.h
> >> > tml
> >> >
> >> > org-agenda-filter-by-tag should be fixed to handle the empty tag
> >> > case that causes the error above, either by behaving as before or
> >> > by giving a clear error.  I haven't looked closely enough at the
> >> > changes or the discussion to guess whether that commit intended to
> >> > preserve the empty tag behavior you were relying on.  Is that behavior
> documented anywhere?
> >> >
> >> > --
> >> > Kyle
> >>
> >>
> >> Any help?


0001-org-agenda-Filter-empty-tags.patch
Description: 0001-org-agenda-Filter-empty-tags.patch

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi,

> -Original Message-
> From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]
> Sent: Thursday, November 26, 2015 09:22
> To: Gustav Wikström <gus...@whil.se>
> Cc: sgeorgii . <sgeor...@gmail.com>; emacs-orgmode@gnu.org
> Subject: Re: [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
> 
> Gustav Wikström <gus...@whil.se> writes:
> 
> > Taking your comments and improving the first patch a bit resulted in
> > the attached one. It replaces the previous. Using string-prefix-p and
> > string-suffix-p solves the out of index problem in the substrings.

Ok, darnit. And I see you found another workaround for that ;-)

> 
> Applied. Thank you.

Great.

> 
> I modified a bit the patch however, since my suggestion about using `string-
> suffix-p' doesn't hold: it isn't compatible with Emacs 24.3.
> I also removed a bunch of `setq'.

Ok, fair enough. A bit more difficult to follow the code now (in my opinion) 
but I guess it saves a few I/O's. 

There was a small error in your edit though. The push-statement feels lonely 
outside of the let*.

> 
> 
> Regards,

Kind regards
Gustav

Re: [O] org-agenda-filter-by-tag-refine defaults to exclude

[Gustav Wikström]

Hi Kyle, Viktor and the group,

I'd say it's a naming-problem. What, really, is the purpose of the function? 
Because applying the proposed change essentially makes the function identical 
to the function it calls. Right? And that function is still available for the 
user, so a "refinement" can be done without the org-agenda-filter-by-tag-refine 
(bound to backslash (\) ) function. As of now, using the function to exclude 
tags in the agenda provides a direct access to that functionality, instead of 
calling org-agenda-filter-by-tag (bound to slash (/) ) plus pushing the minus 
key (-) to switch from filter to exclude.

If you want to make any change, I'd suggest to instead change the name of 
org-agenda-filter-by-tag-refine to org-agenda-filter-by-tag-exclude and to 
leave the code within the function as is (well.. maybe change 'refine to 
'exclude with the same argument as to the function name change).

Best Regards
Gustav

-Original Message-
From: Kyle Meyer [mailto:k...@kyleam.com] 
Sent: Tuesday, January 12, 2016 07:19
To: Viktor Rosenfeld <v.rosenf...@gmx.de>
Cc: emacs-orgmode@gnu.org; Gustav Wikström <gus...@whil.se>
Subject: Re: org-agenda-filter-by-tag-refine defaults to exclude

Hi Viktor,

Viktor Rosenfeld <v.rosenf...@gmx.de> writes:

> Hi,
>
> I noticed that org-agenda-filter-by-tag-refine started to exclude 
> selected tags by default recently because the 'refine in the call to 
> org-agenda-filter-by-tag is interpreted as an exclude flag.

This seems to have been introduced by 6c6ae99 (org-agenda: Filtering in the 
agenda on grouptags, 2015-01-24).

> The attached patch fixes this.
>
> However, it seems that the function is superfluous because 
> org-agenda-filter-by-tag can filter on multiple tags as well if called 
> multiple times (that used not to be the case earlier).  So maybe it 
> should be deprecated and removed?

I agree.  Gustav, does that make sense given your changes in 6c6ae99?

> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 
> d91b64d..21928de 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -7580,7 +7580,7 @@ to switch between filtering and excluding."
>  (defun org-agenda-filter-by-tag-refine (arg  char)
>"Refine the current filter.  See `org-agenda-filter-by-tag'."
>(interactive "P")
> -  (org-agenda-filter-by-tag arg char 'refine))
> +  (org-agenda-filter-by-tag arg char))

>  (defun org-agenda-filter-make-matcher (filter type  expand)
>"Create the form that tests a line for agenda filter.  Optional


--
Kyle

Re: [O] org-agenda-filter-by-tag-refine defaults to exclude

[Gustav Wikström]

Hi Viktor, Kyle

Fair enough. I’m not attached to the refine-function at all. If you like to 
have it removed, then remove it, unless others are of different opinion ofc. 
The functionality is fairly complex, so removing the keybinding might make it 
seem less complicated.

/G

From: Viktor Rosenfeld [mailto:v.rosenf...@gmx.de]
Sent: Saturday, January 30, 2016 00:08
To: emacs-orgmode@gnu.org
Cc: Gustav Wikström <gus...@whil.se>; Kyle Meyer <k...@kyleam.com>
Subject: Re: org-agenda-filter-by-tag-refine defaults to exclude

Hi Gustav,

currently, the remove functionality can also be accessed by C-u /. If we want 
to provide a dedicated hotkey, then the following definition will do it:

(add-hook 'org-agenda-mode-hook
  (lambda()
(local-set-key (kbd "\") '(lambda()
(interactive)
(org-agenda-filter-by-tag nil nil 
'exclude
  'append)

I would prefer to remove this function because it doesn’t add functionality. 
Keeping it around just adds another potential source of bugs.

Best,
Viktor

Am 28.01.2016 um 09:27 schrieb Gustav Wikström 
<gus...@whil.se<mailto:gus...@whil.se>>:

Hi Kyle, Viktor and the group,

I'd say it's a naming-problem. What, really, is the purpose of the function? 
Because applying the proposed change essentially makes the function identical 
to the function it calls. Right? And that function is still available for the 
user, so a "refinement" can be done without the org-agenda-filter-by-tag-refine 
(bound to backslash (\) ) function. As of now, using the function to exclude 
tags in the agenda provides a direct access to that functionality, instead of 
calling org-agenda-filter-by-tag (bound to slash (/) ) plus pushing the minus 
key (-) to switch from filter to exclude.

If you want to make any change, I'd suggest to instead change the name of 
org-agenda-filter-by-tag-refine to org-agenda-filter-by-tag-exclude and to 
leave the code within the function as is (well.. maybe change 'refine to 
'exclude with the same argument as to the function name change).

Best Regards
Gustav

-Original Message-
From: Kyle Meyer [mailto:k...@kyleam.com]
Sent: Tuesday, January 12, 2016 07:19
To: Viktor Rosenfeld <v.rosenf...@gmx.de<mailto:v.rosenf...@gmx.de>>
Cc: emacs-orgmode@gnu.org<mailto:emacs-orgmode@gnu.org>; Gustav Wikström 
<gus...@whil.se<mailto:gus...@whil.se>>
Subject: Re: org-agenda-filter-by-tag-refine defaults to exclude

Hi Viktor,

Viktor Rosenfeld <v.rosenf...@gmx.de<mailto:v.rosenf...@gmx.de>> writes:


Hi,

I noticed that org-agenda-filter-by-tag-refine started to exclude
selected tags by default recently because the 'refine in the call to
org-agenda-filter-by-tag is interpreted as an exclude flag.

This seems to have been introduced by 6c6ae99 (org-agenda: Filtering in the 
agenda on grouptags, 2015-01-24).


The attached patch fixes this.

However, it seems that the function is superfluous because
org-agenda-filter-by-tag can filter on multiple tags as well if called
multiple times (that used not to be the case earlier).  So maybe it
should be deprecated and removed?

I agree.  Gustav, does that make sense given your changes in 6c6ae99?


diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index
d91b64d..21928de 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7580,7 +7580,7 @@ to switch between filtering and excluding."
(defun org-agenda-filter-by-tag-refine (arg  char)
  "Refine the current filter.  See `org-agenda-filter-by-tag'."
  (interactive "P")
-  (org-agenda-filter-by-tag arg char 'refine))
+  (org-agenda-filter-by-tag arg char))


(defun org-agenda-filter-make-matcher (filter type  expand)
  "Create the form that tests a line for agenda filter.  Optional


--
Kyle

[O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi,

I’ve attached a patch with some suggested additions to org-attach. Patch 
comments below. Please review.

Kind regards
Gustav
___
Patch comments:
* Add new linktype "attached" for attachments

A new linktype "attached" is added in order to reduce link-duplication
when wanting to link to files in attached folders of nodes. This works
for both ID-based attachments and ATTACH_DIR.  Inline images will
trigger also for attachments, as well as search-decorations in the
links.  The goal is to make the functionality for attached-links
mirror file-links.

* Add further options for ATTACH_DIR

When working with ATTACH_DIR there are now a couple of new options available:
- org-attach-dir-inherit-by-default
- org-attach-dir-create-if-not-exist
- org-attach-dir-relative

Descriptions of them can be found in the commit for each new customization.

* Documentation in org-manual

Org-manual is updated with the new link-type as well as some minor
cleanup in the documentation related to external links and attachments.




0001-org-attach-org-manual-org-New-link-type-more-attach-.patch
Description: 0001-org-attach-org-manual-org-New-link-type-more-attach-.patch

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi Marco,

Nice to hear you like it! Yeah, I'm pretty happy with that functionality as 
well. Use it all the time to quickly add links to attached files.

One use case I have for this (as an example) is for projects and tasks. I have 
a 'tasks.org' file with nodes for each of my tasks and each of my projects. 
Usually, if the task is about some digital work, there are files involved with 
it. So I have a convention to add folders next to the 'tasks.org' file with 
names like 'YYMM [task/project title]', and attach the folder to each 
task/project node. C-c C-l attached RET then makes it super-easy to refer to 
particular files within that folder, from within the node in the 'tasks.org' 
file!

Another use case is for my 'digital brain', where it's also fairly common for 
me to have attachment folders where I want to refer to files within them. 
Images for example, that then will be displayed in the org-mode file. Haven't 
settled on whether I should use auto-managed ID's for these folders, or 
:ATTACH_DIR: properties though. Currently using a bit of both...

I'm not familiar with the 'next' branch and the plans for integrating it into 
'master'. But if 'master' is to offensive to merge into straight away, 'next' 
sounds like a good option!

Kind regards
Gustav

-Original Message-
From: Marco Wahl  
Sent: den 1 november 2018 17:01
To: Gustav Wikström 
Subject: Re: FW: [RFC] Link-type for attachments, more attach options

The following message is a courtesy copy of an article that has been posted to 
gmane.emacs.orgmode as well.

Hi Gustav,

I played a bit with your proposition.  I like it; in particular the completion 
function to insert links from the attachment directory with

C-c C-l attached RET

It seems natural to me to have a more specific link type for attached files.

In my opinion your patch should be applied to the 'next' branch.


My 2ct,
Marco

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi, nice to hear that you find it useful!

I don’t have access to apply the patch myself. So I’d be happy if one of the 
frequent maintainers could help out with that, and at the same time look a bit 
at the quality of it. I’ve used most of the functionality personally for well 
over a year in my local setup and just now took the time to repackage it into 
something reusable. Hopefully it’s seen as “good enough” to warrant a merge 
into one of the org-mode branches!

From my perspective the patch adds a lot of utility to the 
attachment-functionality.

Regards
Gustav

From: tumashu 
Sent: den 1 november 2018 02:46
To: Gustav Wikström 
Cc: emacs-orgmode 
Subject: Re:[O] FW: [RFC] Link-type for attachments, more attach options

Hello, this feature seem to be very useful, what is this patch status?




At 2018-10-21 15:53:38, "Gustav Wikström" 
mailto:gus...@whil.se>> wrote:

Hi,

I’ve attached a patch with some suggested additions to org-attach. Patch 
comments below. Please review.

Kind regards
Gustav
___
Patch comments:
* Add new linktype "attached" for attachments

A new linktype "attached" is added in order to reduce link-duplication
when wanting to link to files in attached folders of nodes. This works
for both ID-based attachments and ATTACH_DIR.  Inline images will
trigger also for attachments, as well as search-decorations in the
links.  The goal is to make the functionality for attached-links
mirror file-links.

* Add further options for ATTACH_DIR

When working with ATTACH_DIR there are now a couple of new options available:
- org-attach-dir-inherit-by-default
- org-attach-dir-create-if-not-exist
- org-attach-dir-relative

Descriptions of them can be found in the commit for each new customization.

* Documentation in org-manual

Org-manual is updated with the new link-type as well as some minor
cleanup in the documentation related to external links and attachments.

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi,

> -Original Message-
> From: Ihor Radchenko 
> Sent: den 18 november 2018 01:42
> To: Gustav Wikström ; Marco Wahl
> 
> Cc: emacs-orgmode 
> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> Hi Gustav,
> 
> > I like the idea of a function that would symbolically links folders
> > from "ID"-folder structure to a hierarchy-folder structure, based on
> > the name and path of the org-file  and its headings containing the
> > links. I probably wouldn't use it much myself though. Not until
> > org-mode starts working better with multiple files, allowing us to
> > more easily define "org-mode libraries".
> 
> I am wondering what you mean by "org-mode libraries". Can you explain
> further?

This goes a bit off topic; But what I mean is mainly two things: 
1) Generalize the org-agenda so that we can have multiple ones

   Generalize org-agenda by allowing us to have multiple ones, and make them 
more general by thinking of them as a set of views that works on sets of files. 
Maybe this is not for all, but I would appreciate to create multiple "agendas" 
(even though I'd call them "libraries" in instead), and possibly also an 
aggregate agenda consisting of other agendas.

2) Make files function as virtual "level-0 headings"

   If two org-mode files exist in the same folder with different names, it 
would be awesome to think of (and work with) them as two top-level headings 
inside one org-mode buffer. Similar to two level-1 headings inside an org-mode 
file. For this to work all properties we can define for regular headings should 
be possible to define for these "level-0 headings". For example an 
attachment-folder or ID, a deadline, scheduled date, or TODO-keyword should in 
that case be configurable on the whole file. I guess some new conventions 
regarding syntax and existing properties would have to be created as well.

> 
> Also, another thought about the attachment: links.
> It would be useful to implement links to attachments, which are not in the
> current org entry.
> For example, something like "attachment:ORG-ID:file-name", where ORG-ID
> refers to ID of an arbitrary org entry.

I wouldn't call that attachment-links, but rather ID-based links (since 
attachments are local based on either headline ID or attach-dir of the current 
headline). ID links exist already but link to headlines. 

If you rather see ID-based attachments as some kind of global attachments for 
all your org-mode files, I'd think the link-type should reflect that and be 
called something like "ID-attachment:file-name", "ID-@:file-name", 
"@ID:file-name" and be a separate link-type.

> 
> Best,
> Ihor
> 
> 

Kind regards
Gustav

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi,

> -Original Message-
> From: Ihor Radchenko 
> Sent: den 20 november 2018 15:01
> To: Gustav Wikström 
> Cc: emacs-orgmode 
> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> Hi,
> 
> >Generalize org-agenda by allowing us to have multiple ones, and make
> them more general by thinking of them as a set of views that works on sets
> of files. Maybe this is not for all, but I would appreciate to create
> multiple "agendas" (even though I'd call them "libraries" in instead), and
> possibly also an aggregate agenda consisting of other agendas.
> 
> Isn't this already in org? You can use custom agendas with multiple
> "agendas" (custom commands) and set the files they operate on with org-
> agenda-files within custom commands.

No, it's not there. I know of the custom agendas and use it currently. But I 
cannot anywhere specify more than one org-agenda-files parameter, for example. 

> 
> >If two org-mode files exist in the same folder with different names, it
> would be awesome to think of (and work with) them as two top-level headings
> inside one org-mode buffer. Similar to two level-1 headings inside an org-
> mode file. For this to work all properties we can define for regular
> headings should be possible to define for these "level-0 headings". For
> example an attachment-folder or ID, a deadline, scheduled date, or TODO-
> keyword should in that case be configurable on the whole file. I guess some
> new conventions regarding syntax and existing properties would have to be
> created as well.
> 
> You can do something like below. It is pretty much what you want, except I
> am not sure how to update the headings from local org files. Current org
> version does not allow `:results replace` on raw org output.
> 
> * Main heading
> 
> #+name: org-files-here
> #+begin_src bash
> ls *.org
> #+end_src
> 
> #+begin_src emacs-lisp :var files=org-files-here()  :var stars=(make-string
> (car (org-heading-components)) ?*)  :results raw replace drawer (let ((files
> (mapcar #'car files)))
>   (cl-loop for file in files
>  concat (with-current-buffer (find-file-noselect file)
>   (concat (format "* %s\n" (buffer-file-name))
>   (replace-regexp-in-string "^\\*" (concat "*" stars)
> (buffer-string)) #+end_src

No, that's not what I want. What I'm talking about is extending org-mode 
conceptually with the concept of 0-level headlines, where the body of that 
"headline" would be everything before the first headline in a file, and where I 
could specify (for example) an attachment-directory and be able to use it with 
this new syntax to link to attached files. I guess I took it a bit far with the 
example of visualizing multiple files from a folder as separate headlines 
inside a single emacs-buffer though. It would be cool to be able to do that but 
my intention was more about introducing the 0-level headline concept.

Thanks for your idea and suggestion though!

> 
> Best,
> Ihor

Kind Regards,
Gustav

Re: [O] [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi again,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 20 november 2018 00:52
> To: Gustav Wikström 
> Cc: Org Mode List 
> Subject: Re: [RFC] Link-type for attachments, more attach options
> 
> > Yeah - I liked "attached" because I prefer clear keywords. But sure,
> > we can keep it shorter. I'd suggest "@" instead in that case. Patch
> > updated with that.
> 
> "@" syntax is a reserved syntax for citations in the "wip-cite" branch.
> I'd rather not use it here. Also, years ago, "att" link type was used to
> link to attachments, hence my proposal.

Too bad, "@" was growing on me. @ is currently automatically set as a tag when 
attaching files to nodes. So it was fitting to use it also in links in my 
opinion. Is the cite-syntax the same as the regular link-pattern? [[@: ...]] ? 
Otherwise I'd suggest them to coexist. Or to change the cite-symbol to ... "c" 
maybe? @ is a pretty standard symbol for attachments. Just have a look at 
Gmail, Outlook etc.

I didn't change this in the attached patch. I'm hoping for second thoughts! :) 
The future ease of use (i.e. clarity and standardization of symbols in this 
case) should have precedence over current work in progress...

> >> > When working with ATTACH_DIR there are now a couple of new options 
> >> > available:
> >> > - org-attach-dir-inherit-by-default
> >>
> >> What is the difference between this and
> >> `org-attach-allow-inheritance'?
> 
> You didn't answer this question, did you?

No, seems I missed it. 

> Something is fishy here anyways. Why is "ATTACH_DIR_INHERIT" needed at
> all? If `org-attach-allow-inheritance', "ATTACH_DIR" should be
> inherited. Why depend on another property?

Yeah, I don't know why it's configured like that from the start. A bit 
convoluted. Not sure of what way to go forward though. I can see at least two 
paths:

1) Rename `org-attach-allow-inheritance' to `org-attach-enable-inheritance' and 
always make attachments inherited when that is set to "t". Deprecate 
"ATTACH_DIR_INHERIT". With this I'd also change the precedence-logic between 
ATTACH_DIR & ID properties and make ID-based attachment inherit as well. The 
properties ATTACH_DIR and ID should be inherited from the closest node when 
resolving attachments, with ATTACH_DIR having precedence over ID if both exist 
for the same node.

2) remove `org-attach-allow-inheritance' and only rely on the 
"ATTACH_DIR_INHERIT" property of any of the parent nodes to decide if the 
"ATTACH_DIR" property should be inherited. This would be a smaller change from 
the user's perspective, where we're basically saying you cannot disable 
inheritance, but it's only active when a node has the 
ATTACH_DIR_INHERIT-property.

I prefer path (1). That would be a great default. But that change is bigger and 
should be separated from this patch anyways. To not increase the complexity 
I've removed the `org-attach-dir-inherit-by-default' customization.

> >> > - org-attach-dir-create-if-not-exist
> >>
> >> What is the use-case for this one? It doesn't seem terribly useful at
> >> first glance.
> >
> > If you try to open attachments on a node where there is no ID or
> >> ATTACH_DIR, the default behavior is to add an ID and create a folder
> >> based on that ID. I would like Org-mode to not do that. This
> >> customization give the user the option to change that. Instead of
> >> providing this customization one could just change the default
> >> behavior of org-attach, since it's a bit offensive to create folders
> >> when I didn't ask for it. But instead of changing the default,
> >> I thought this way was more graceful. I wouldn't mind skipping this
> >> customization though, if the behavior was changed to what
> >> I implemented with org-attach-dir-create-if-not-exist set to nil.
> 
> Considering attaching is about moving, or copying files somewhere,
> creating a folder doesn't sound terribly offensive. You don't even have
> to know the name of the folder.
> 
> Do you suggest to raise an error if there is no folder available for the
> attached documents? If so, wouldn't it be better to ask the user first?

Agreed, the parameter can be removed and a "do you want to create a folder?" 
question could be raised instead, when it's not intuitive for the program to 
create the folder by itself.

> >> > +This list shows the full set of built-in external link types:
> >> > +| http   | web |
> >> > +| https  | secure web  |
> >> > +| doi| DOI for

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi Nicolas,

Thanks for your detailed comments. Much appreciated.

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 4 november 2018 23:37
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: FW: [RFC] Link-type for attachments, more attach options
> 
> Hello,
> 
> Gustav Wikström  writes:
> 
> > I’ve attached a patch with some suggested additions to org-attach.
> > Patch comments below. Please review.
> 
> Thank you. Some comments follow.
> 
> > * Add new linktype "attached" for attachments
> 
> This seem a bit long. Why not "att" links?

Yeah - I liked "attached" because I prefer clear keywords. But sure, we can 
keep it shorter. I'd suggest "@" instead in that case. Patch updated with that.

> 
> > * Add further options for ATTACH_DIR
> >
> > When working with ATTACH_DIR there are now a couple of new options 
> > available:
> > - org-attach-dir-inherit-by-default
> 
> What is the difference between this and `org-attach-allow-inheritance'?
> 
> > - org-attach-dir-create-if-not-exist
> 
> What is the use-case for this one? It doesn't seem terribly useful at
> first glance.

If you try to open attachments on a node where there is no ID or ATTACH_DIR, 
the default behavior is to add an ID and create a folder based on that ID. I 
would like Org-mode to not do that. This customization give the user the option 
to change that. Instead of providing this customization one could just change 
the default behavior of org-attach, since it's a bit offensive to create 
folders when I didn't ask for it. But instead of changing the default, I 
thought this way was more graceful. I wouldn't mind skipping this customization 
though, if the behavior was changed to what I implemented with 
org-attach-dir-create-if-not-exist set to nil.

> 
> > - org-attach-dir-relative
> 
> I'm not sure to understand this one.

When adding folders to nodes using option "s" in org-attach, the path is 
absolute. This makes attachment-directory paths relative to location of the 
file instead.

> >
> > +This list shows the full set of built-in external link types:
> > +| http   | web |
> > +| https  | secure web  |
> > +| doi| DOI for electronic resources|
> > +| file   | file-links  |
> > +| file+sys   | file-links forced to open via OS|
> > +| file+emacs | file-links forced to open via emacs |
> > +| attached   | links to attachments for nodes  |
> > +| docview| doc-view mode   |
> > +| id | Link to heading by id   |
> > +| news   | Usenet link |
> > +| mailto | mail link   |
> > +| mhe| MH-E folder link|
> > +| rmail  | Rmail link  |
> > +| gnus   | Gnus link   |
> > +| bbdb   | BBDB link   |
> > +| irc| IRC link|
> > +| info   | Info link   |
> > +| shell  | shell command   |
> > +| elisp  | interactive elisp command link  |
> > +
> > +The following list shows examples for each link type.
> > +
> > +| =http://www.astro.uva.nl/=dominik=| on the web   
> >|
> > +| =doi:10.1000/182= | DOI for an electronic 
> > resource  |
> > +| =file:/home/dominik/images/jupiter.jpg=   | file, absolute path  
> >|
> > +| =/home/dominik/images/jupiter.jpg=| same as above
> >|
> > +| =file:papers/last.pdf=| file, relative path  
> >|
> > +| =./papers/last.pdf=   | same as above
> >|
> > +| =file:/ssh:me@some.where:papers/last.pdf= | file, path on remote machine 
> >|
> > +| =/ssh:me@some.where:papers/last.pdf=  | same as above
> >|
> > +| =file:sometextfile::NNN=  | file, jump to line number
> >|
> > +| =file:projects.org=   | another Org file 
> >|
> > +| =file:projects.org::some words=   | text search in Org 
> > file[fn:28]  |
> > +| =file:projects.org::*task title=  | heading search in Org file   
> >|
> > +| =file+sys:/path/to/file=  | open via OS, like 
> > double-click  |
> 

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi Ihor,

I'm not sure I follow your suggestion regarding changing the implementation. 
But anyhow I don't think the implementation is heavy and at risk of cumbersome 
code duplication. My opinion ofc 

I like the idea of a function that would symbolically links folders from 
"ID"-folder structure to a hierarchy-folder structure, based on the name and 
path of the org-file  and its headings containing the links. I probably 
wouldn't use it much myself though. Not until org-mode starts working better 
with multiple files, allowing us to more easily define "org-mode libraries".

/G 

> -Original Message-
> From: Ihor Radchenko 
> Sent: den 3 november 2018 04:38
> To: Gustav Wikström ; Marco Wahl 
> Cc: emacs-orgmode 
> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> Hi Gustav,
> 
> Thanks for the patch!
> I am a heavy user of org attachments, so it is pleasant that someone
> spent a time to implement this useful feature into org.
> 
> A comment regarding the code.
> Your new link types appears to reimplement some of the code for the
> "file:" links.
> Would it make more sense to implement the "attachment:" link type as
> abbreviation?
> I mean something like the code below:
> 
> 
> (defun yant/process-att-abbrev (arg)
>   "Return `org-attach-dir' for the current entry."
>   (s-concat (org-attach-dir 'CREATE) arg))
> 
> (add-to-list 'org-link-abbrev-alist (cons "att" 
> "file:%(yant/process-att-abbrev)"))
> 
> (defun org-att-link-complete ( arg)
>   "Completion function for att: link."
>   (let* ((ref-dir (org-attach-dir 'CREATE))
>(filelink (let ((default-directory ref-dir))
>(org-file-complete-link)))
>(filepath (apply #'s-concat (cdr (s-split ":" filelink)
> (format "att:%s" filepath)))
> 
> (org-link-set-parameters "att"
>:complete #'org-att-link-complete)
> 
> 
> Also, is anyone interested in automatic placing of org attachments into
> a folder structure, which mirrors the org path?
> Something like in the following Stack Exchange question:
> https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org-
> attach
> 
> Best,
> Ihor
> 
> Gustav Wikström  writes:
> 
> > Hi Marco,
> >
> > Nice to hear you like it! Yeah, I'm pretty happy with that functionality as 
> > well. Use it
> all the time to quickly add links to attached files.
> >
> > One use case I have for this (as an example) is for projects and tasks. I 
> > have a
> 'tasks.org' file with nodes for each of my tasks and each of my projects. 
> Usually, if the
> task is about some digital work, there are files involved with it. So I have 
> a convention
> to add folders next to the 'tasks.org' file with names like 'YYMM 
> [task/project title]',
> and attach the folder to each task/project node. C-c C-l attached RET then 
> makes it super-
> easy to refer to particular files within that folder, from within the node in 
> the
> 'tasks.org' file!
> >
> > Another use case is for my 'digital brain', where it's also fairly common 
> > for me to have
> attachment folders where I want to refer to files within them. Images for 
> example, that
> then will be displayed in the org-mode file. Haven't settled on whether I 
> should use auto-
> managed ID's for these folders, or :ATTACH_DIR: properties though. Currently 
> using a bit
> of both...
> >
> > I'm not familiar with the 'next' branch and the plans for integrating it 
> > into 'master'.
> But if 'master' is to offensive to merge into straight away, 'next' sounds 
> like a good
> option!
> >
> > Kind regards
> > Gustav
> >
> > -Original Message-
> > From: Marco Wahl 
> > Sent: den 1 november 2018 17:01
> > To: Gustav Wikström 
> > Subject: Re: FW: [RFC] Link-type for attachments, more attach options
> >
> > The following message is a courtesy copy of an article that has been posted 
> > to
> gmane.emacs.orgmode as well.
> >
> > Hi Gustav,
> >
> > I played a bit with your proposition.  I like it; in particular the 
> > completion function
> to insert links from the attachment directory with
> >
> > C-c C-l attached RET
> >
> > It seems natural to me to have a more specific link type for attached files.
> >
> > In my opinion your patch should be applied to the 'next' branch.
> >
> >
> > My 2ct,
> > Marco
> >

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi Feng Shu,

> -Original Message-
> From: Feng Shu 
> Sent: den 4 januari 2019 13:22
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> I like this feature very much!

I'm glad! I've just now sent an updated patch to the mailing-list. 
It contains quite substantial changes. Maybe you care to review it 
as well? 

Best
Gustav

Re: [O] FW: [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi again!

> -Original Message-
> From: Ihor Radchenko 
> Sent: den 14 december 2018 03:16
> To: Gustav Wikström 
> Cc: emacs-orgmode 
> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> > No, that's not what I want. What I'm talking about is extending org-mode 
> > conceptually
> > with the concept of 0-level headlines, where the body of that "headline" 
> > would be
> > everything before the first headline in a file, and where I could specify 
> > (for example) an
> > attachment-directory and be able to use it with this new syntax to link to 
> > attached files.
> > I guess I took it a bit far with the example of visualizing multiple files 
> > from a folder
> > as separate headlines inside a single emacs-buffer though. It would be cool 
> > to be able to
> > do that but my intention was more about introducing the 0-level headline 
> > concept.
> 
> Yeah. But someone needs to volunteer with the patch.

I just wanted to say I'm working on this. More info will come in a separate 
thread soon!

Kind regards,
Gustav

Re: [O] [RFC] Link-type for attachments, more attach options

[Gustav Wikström]

Hi again,

Some updates, and a fresh patch...!

I won't say that much here since the patch speaks for itself (It 
contains a chapter to be added to ORG-NEWS). It's patch 0002 that is the 
important one. See sidenote below for a comment about patch 0001.

I have to mention that the patch has grown quite a lot. With the 
Additional changes, I've taken the liberty to promote attachments to a 
level-1 headline within the documentation!

Please review the new and improved" patch.

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 27 november 2018 10:40
> To: Gustav Wikström 
> Cc: emacs-orgmode 
> Subject: Re: [RFC] Link-type for attachments, more attach options
> 
> Hello,
> 
> Gustav Wikström  writes:
> 
> > Too bad, "@" was growing on me. @ is currently automatically set as
> > a tag when attaching files to nodes.
> 
> You probably customized `org-attach-auto-tag' because this is not the
> default behaviour. It adds "ATTACH" tag automatically.

Yeah, you're right. My bad!

> I prefer not to consider Gmail and Outlook as references, or even
> standards. As another data point, Gnus uses "Attachment: " to list
> attachments.

I won't argue any longer. And I'll do as you say. Attachment: it is!

> > Yeah, I don't know why it's configured like that from the start. A bit 
> > convoluted. Not
> > sure of what way to go forward though. I can see at least two paths:
> >
> > 1) Rename `org-attach-allow-inheritance' to
> > `org-attach-enable-inheritance' and always make attachments inherited
> > when that is set to "t". Deprecate "ATTACH_DIR_INHERIT". With this I'd
> > also change the precedence-logic between ATTACH_DIR & ID properties
> > and make ID-based attachment inherit as well. The properties
> > ATTACH_DIR and ID should be inherited from the closest node when
> > resolving attachments, with ATTACH_DIR having precedence over ID if
> > both exist for the same node.
> 
> Why defining `org-attach-enable-inheritance' at all? There is already
> `org-use-property-inheritance' for this. We do not need another
> conflicting variable.
> 
> I don't think we should inherit ID properties either. ID is defined
> outside "org-attach.el", so this library shouldn't mess with its
> meaning. Does inheriting ID properties give anything valuable?

Inheriting ID's for attachments is actually valuable. It makes it possible, 
for example, to add attachment-links in subheadings to the node the  
attachment is defined on. After having used this for quite some time now it
feels quite natural to have inheritance switched on for attachments. No negative
side-effects at all.

> > 2) remove `org-attach-allow-inheritance' and only rely on the
> > "ATTACH_DIR_INHERIT" property of any of the parent nodes to decide if
> > the "ATTACH_DIR" property should be inherited. This would be a smaller
> > change from the user's perspective, where we're basically saying you
> > cannot disable inheritance, but it's only active when a node has the
> > ATTACH_DIR_INHERIT-property.
> >
> > I prefer path (1).
> 
> So do I, with the remarks above.

I went with path (1) and tried to fit it into the already existing property 
inheritance framework.

> > +This list shows the full set of built-in external link types,
> > +including examples for each:
> > +
> > +| Link Type | Description  | Example|
> > +|---+--+---|
> > +| http  | web  | 
> > =http://www.astro.uva.nl/=dominik= |
> > +| https | secure web   | =https://orgmode.org/= |
> > +| doi   | DOI for electronic resources | =doi:10.1000/182= |
> > +| file  | file-links   | 
> > =file:/home/dominik/images/jupiter.jpg= |
> > +|   |  | 
> > =/home/dominik/images/jupiter.jpg= (same as above)|
> > +|   |  | =file:papers/last.pdf= |
> > +|   |  | =./papers/last.pdf= (same as 
> > above) |
> > +|   |  | 
> > =file:/ssh:me@some.where:papers/last.pdf= (remote)|
> > +|   |  | 
> > =/ssh:me@some.where:papers/last.pdf= (same as above)  |
> > +|   |  | =file:sometextfile::NNN= 
> > (jump to line number)|
> > +|   |  | =file:projects.org= |
> > +|   |  | =file:projects.org::som

Re: [O] Proposal for new document-level syntax

[Gustav Wikström]

Hi Eric!

> -Original Message-
> From: Fraga, Eric 
> Sent: den 1 juni 2019 15:18
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [O] Proposal for new document-level syntax
> 
> For me, however, your proposed structure would clash strongly with my
> usual working practice.  Specifically, I put all customizations and
> settings at the end of my documents, along with, for instance, Emacs
> file local variables.  These are things I do not change often and
> usually don't care to see.  At the start of the document, however, is
> the real content.  So, I don't particularly like the idea of having
> settings etc. *before* the content in my files.

Point taken. File local variables potitions would not be affected of
course. And to be honest, I don't see any existing keyword going away
any time soon either. So your workflow probably won't be affected for
a long time. Unless you choose to!

With that said, I'd still like to argue a bit more for the structure
I've presented. The idea with having drawers is exactly the point
you're also making; that it makes configuration go out of the way for
real content. I question the disctraction 1-2 rows provide. Take for
example the way current property drawer and planning-properties work
on outline-nodes. They have fixed positions at the top of the node and
take up maximum two rows when declared. Not really an issue in my book
and the benefit of fixed positions is easy parsing for both humans and
the machine. The same would apply for document settings and
properties. Take the example below:

#+begin_example
  :SETTINGS:...
  :PROPERTIES:...
  ,* Heading 1
  DEADLINE: <2019-06-02 Sun> SCHEDULED: <2019-06-01 Sat>
  :PROPERTIES:...
  lorem

  ,* Heading 2
  Ipsum

  ,# -*- mode: org -*-
#+end_example

To me it makes perfect sense to have the drawers at the top at fixed
positions. It follows current convention for headlines. At most two
rows before the real content is hopefully a compromize that can be
made for syntactic clarity and simplicity. And personally it would be
a great improvement over the current way document-level keywords work.
> 
> Just by 2¢.

Thanks!

[O] Proposal for new document-level syntax

[Gustav Wikström]

 PROPOSAL FOR NEW DOCUMENT-LEVEL SYNTAX

Gustav Wikström



Table of Contents
_

1. Summary
2. Background, details etc.
3. Proposal details
4. Code?


1 Summary
=

  I propose a "document" element in org-element, a property-drawer on
  document-level, a setting-drawer on document-level and
  property-keywords (slightly different than what already exist). And
  would like your comments regarding that!

  More details below.


2 Background, details etc.
==

  I'm amazed by how well org-mode fullfills my needs for writing,
  thinking, organizing and structuring information. Having a text-based
  outliner with rich formatting, searching and inter-linking options is
  amazing! There are a few things that's bugged me for a while though.
  One of those things is the fact that org-mode is lacking when you're
  outside of a headline. Basically, org-mode lacks the proper notion of
  a document. One use case for a more clear notion of a document is for
  large libraries of short notes separated by files instead of separated
  by headlines. Separating notes by files has drawbacks today. You can't
  easily define todo's, tags, ID's, attachments etc. when your not
  within a headline!

  You might think: "But just create a headline if you want those
  things..!"

  To which I'd answer: "Yes, that works. As a workaround. But it's not
  good enough! What do I name my headline? I already have a name for the
  file, having to define a name again for a headline inside that file is
  redundant for short notes."

  Look for example at org-brain which had to introduce separate concepts
  to be able to deal with files and subtrees ([headlines and files]).
  Some org-brain issues that relates to this lack of a document-concept:
  ([#118], [#91], [#48]). This suggestion is not about org-brain. But I
  just wanted to give an example of how this is something that /can/ be
  improved.

  To get started on this road towards a clearer definition and syntax
  for things above the headline-concept, I have a couple of suggestions
  I hope the community will support!


[headlines and files]
<https://github.com/Kungsgeten/org-brain#headline-and-file-entries>

[#118] <https://github.com/Kungsgeten/org-brain/issues/118>

[#91] <https://github.com/Kungsgeten/org-brain/issues/91>

[#48] <https://github.com/Kungsgeten/org-brain/issues/48>


3 Proposal details
==

  I propose to introduce two org-mode drawers to be used in the top of
  org-mode documents:
  1) A setting drawer. Applicable only if positioned at the top of a
 buffer, below any potential comment-line or document-level keywords
 (more on those later).
  2) A property drawer. Applicable with the same positional condition as
 the settings-block, and positioned after the settings-block if both
 blocks are available.

  I also propose to allow for whatever property to be defined as a
  keyword if also defined at the top of the document.

  Details for these proposals follows:

  The setting drawer makes the following keywords redundant:
  - #+STARTUP
  - #+TODO
  - #+SEQ_TODO
  - #+TYP_TODO
  - #+PRIORITIES
  - #+TAGS
  - #+LINK
  - #+CONSTANTS
  - #+SETUPFILE
  - #+MACRO

  Initially I propose to just use the setting drawer as an additional
  syntax allowed for the above keywords, preferably with a new
  helper-method for setting them. Settings defined in this drawer should
  have precedence over settings defined by the keywords above. Long term
  I'd like to depricate the above keywords in favour of the setting
  drawer.

  The property drawer is used for properties defined at node-level 0.
  Properties defined inside this drawer are applied in exactly the same
  way as properties on headline-entries are applied for it's subtree.
  I.e. the same inheritance-rules apply.

  The property drawer makes the following keywords redundant: (since all
  of them have property drawer equivalences)
  - #+PROPERTY
  - #+OPTIONS
  - #+CATEGORY
  - #+FILETAGS
  - #+COLUMNS
  - #+ARCHIVE

  Defining properties on the document-level should work using the same
  commands as today when the point is before the first headline.
  Properties defined in the document property drawer should have
  precedence over properties defined by the (then redundant) keywords
  above.

  I propose to allow properties to be defined also as document property
  keywords. All keywords in the top of a buffer, before any non-comment
  line, are document-level keywords. In effect, they are properties that
  apply in exactly the same way as properties defined in the property
  drawer. The only reason for using a document keyword instead of
  defining it inside the property drawer is to make it more visible. One
  example would be the 

Re: [O] Proposal for new document-level syntax

[Gustav Wikström]

Hi Nicolas,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 1 juni 2019 23:01
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Proposal for new document-level syntax
> 
> I only skimmed over your proposal, as I don't have much time. I'm sorry
> if you answered this already, but I don't understand how what you
> suggest would differ from regular keywords.

No worries. I think I explained but it can be further detailed. What I
mean is that any property you can think of should be possible to add
to a document as a keyword with the syntax:

#+{PROPERTY}: {Value}

But only at the beginning of a file, before any other content. The
only reason for defining properties like that is for them to be
visible outside of the property drawer. I'm thinking mostly of
=#+TITLE= and similar keywords.

I'd like to depricate =#+PROPERTY:= since it breaks the outline
hierarchy and doens't follow the convention for how properties are
defined inside headlines. Removing the "old" way of defining
properties for the whole buffer will make property-syntax defined the
same for documents and headlines. With the slight extention of
allowing arbitrary keywords to stand for properties at the beginning
of the buffer. Note that we already have "document property keywords"
in org-mode. Less limited since they're not positionally contained.
And only for a limited set of keywords; the "export keywords". (See
[[info:org#Export Settings]]) 

The proposal has a side-effect of reducing the complexity for
keywords.[fn:1] I did an evaluation of available keywords in org-mode
today by going through the documentation. And there are *lots* of uses
for keywords today. Making keywords easier to use, by removing the
need for them in many cases, hopefully will help future org-moders.

[fn:1] All keywords that have outline property equivalences can be
deprecated and later removed since we're introducing a property drawer
on the document level. All keywords that are meant for customizations
that don't have an outline property equivalent can be *moved* into the
setting drawer. That only leaves keywords that have real meaning in
the outline. =#+NAME=, =#+TOC=, =#+INCLUDE=, for example.

> 
> As a reminder:
> - you can create, and support, as many keywords as you want;
> - keywords all operate at the "document-level";
> - keywords can be located anywhere in the document.
> 
> I think Org keywords already provide everything you need. If they
> don't, I would suggest to improve them instead of creating something
> else.

In my opinion property drawers is the improvement which in time will 
make the existing property-keyword redundant.

With regards,
Gustav

Re: [O] Proposal for new document-level syntax

[Gustav Wikström]

Hi again,

This became a bit long, so the most important thing is repeated here
in the top:

I think there is merit to the idea of a file/document/buffer being
seen as a level-0 node. I think we'd benefit by adhering to the
principles for outline nodes also for the document-node (level-0 node)
as much as possible.

I'd like the specification for org-mode to be clear and succinct and
it's features to be as congruent as possible.

Comments to your concerns and questions below!

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 3 juni 2019 22:40
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Proposal for new document-level syntax
> 
> Hello,
> 
> Gustav Wikström  writes:
> 
> > No worries. I think I explained but it can be further detailed. What I
> > mean is that any property you can think of should be possible to add
> > to a document as a keyword with the syntax:
> >
> > #+{PROPERTY}: {Value}
> 
> IIRC, Org uses
> 
>   #+PROPERTY: {key} {value}
> 
> Why "should" it be possible to use a different syntax?

The main change I want to introduce is the property-drawer. The new
property-syntax is secondary but makes 100% sense when you start
thinking about it. If you read through my initial mail you'll see that
I'm trying to consolidate functionality, moving things from keywords
possibly scattered throughout a document into drawers. That
consolidation is to simplify org-mode, even though it for a while will
make the /actual implementation/ more complex to maintain backwards
compatability. There is a longer investigation behind this that I
probably should share. But given the already long text and what I
understand is a lack of time to read it I hesitate to wall-of-text you
guys more than I'm already doing! :) So I'm taking things
incrementally when questions arise!

To the point; the =#+{PROPERTY}: {Value}= syntax idea started with
thinking about the purpose of existing export keywords. [fn:1] They're
not /only/ valuable for exporting. Defining a title for a document
(TITLE is an export-keyword) makes sense even if you don't export a
document. And what is that title-keyword really? It's a property! You
can define it in an outline as well! [fn:2]

Thinking of TITLE as a property, and thinking of depricating the
export keywords (i.e. remove that concept but maintain functionality
with properties) lead to the problem of TITLE in the future being
hidden away in a drawer. Being a user of the short and easy syntax for
export keywords today, my idea was to generalize them to work for all
properties. But contain them to a fixed position above the document
property drawer since the only use of that kind of property-definition
is to visually highlight it while letting all other document
properties be hidden away in the drawer.

What I've done is to try to not get stuck in existing syntax and think
more freely what would benefit us long term. I hope you can appreciate
that. It will indeed create another way of defining properties on
document-level . But I claim it makes sense! And I claim that the
current way of defining document properties with the

  #+PROPERTY: {key} {value}

doesn't make that much sense when we have document property drawers in
place! I do appreciate the concern of making breaking changes, which
is the reason for not proposing the removal of existing document
property syntax. That maybe could be saved for a major version
sometime in the future, when the drawer has been tried and tested
more, and hopefully accepted more! (I honestly didn't think I'd get
resistance for trying to introduce it...)

> > But only at the beginning of a file, before any other content. The
> > only reason for defining properties like that is for them to be
> > visible outside of the property drawer. I'm thinking mostly of
> > =#+TITLE= and similar keywords.
> >
> > I'd like to depricate =#+PROPERTY:= since it breaks the outline
> > hierarchy and doens't follow the convention for how properties are
> > defined inside headlines.
> 
> So the reason for this change is that keywords break the outline
> hierarchy? Well, keywords do not belong to the outline hierarchy in the
> first place. But syntax is not very different, either.

No no no, you clearly have not read my first mail. Please do. Keywords
breaking the outline hierarchy is only one of the reasons. What you're
saying is actually exactly what I mean with them breaking the outline.
I'm just a bit harsher and more strict - If keywords don't belong to
the outline, then don't put them inside headlines in the outline! They
don't belong there! Also, as I'm sure you're aware since you are the
most knowledgable org-mode'er out there, the following keywords *do*
belong in the outline: 
  #+NAME 
  #+TOC 
  #+ASCII
  #+INCLUDE

What I'm saying is basically that all keywords that "break the
outlin

Re: [O] [RFC] Extend+slight change to C-c C-k and C-c TAB

[Gustav Wikström]

Hi Marco,

I (ofc!) support this.

/Gustav

[O] org-id fixups and minor changes

[Gustav Wikström]

Hi!

I've pushed a couple of fixes and changes to master related to org-id.

First; a fix and a (major) speedup and method-change for how the
global caching works for ID's. The change in method is that providing
file's as arguments to org-id-update-id-locations no longer breaks the
existing id locations.

Second; I've added a customization so one can choose to cache the
id-locations as relative to the org-id-locations-file instead of as
absolute links. This helps a lot when running a system mirrored on
multiple machines where the absolute paths to ones documents might
differ, but where it's all the same relative to the
org-id-locations-file.

Third; I've added another ID generator method. The extremists might
say the new method is not unique enough but org-mode is a personal
system first and foremost, so I think there is merit to this new ID
method. It creates ID's based on current timestamp and doesn't try to
hide the timestamp from the user. One might call the ID's "natural"
since they are contain information in themselves. Certainly a good
thing for some. The new method will not be active unless explicitly
chosen by the user.

As a side note, if using ID's together with attachments, try this
new ID-generator out by setting org-id-method to ts (short for
timestamp) and change the org-attach-id-to-path-function to
something like "/MM/DDTHHMMSS" for more human readable
attachment folders.

Org-id is next to undocumented in the manual so I didn't find a good
place to add this. A few lines are added to org-news though.

This is the first push by me without first doing an RFC. So,
naturally, if anything is out of order mail back and/or make changes
directly in the repo if needed. Tests passed anyways.

Kind regards
Gustav

Re: [O] org-id fixups and minor changes

[Gustav Wikström]

Hi Carsten,

Yeah – you’re right, I didn’t think that much about automated ID creation so I 
stopped at seconds. I agree that it would be more general with more precision 
but that will also add some more noise into each ID. Maybe that’s not 
significant. But I also wonder how common it will be to try to batch-add ID’s…? 
I have nothing against adding more precision though, if that’s requested. What 
do you think?

Regarding documentation I’ll try to give it some thought. Maybe I’ll find some 
time to describe this area better .

I wouldn’t mind changing the default from random to timestamp. But I’m not so 
sure about all the others? One thing that complicates things is the way 
attachment functionality parse the ID. If we use timestamps as the default ID 
it makes sense to change the default way org-attach parses the ID into folders 
as well. Something like “/MM/DD_and_the_rest”. But that will be a breaking 
changing. The existing folder-structure for attachments wouldn’t match the new 
any longer. Cleverness in code might solve the breakage though… If there is 
interest in changing the default I can try to solve the issue with the breaking 
change as well.

Regards
Gustav

From: Carsten Dominik 
Sent: den 10 augusti 2019 00:34
To: Gustav Wikström 
Cc: emacs-orgmode@gnu.org
Subject: Re: [O] org-id fixups and minor changes

Hi Gustav,

I can see that it feels more natural to use timestamps.  I certainly see that 
relative file names are good for across-computer compatibility.

You system assumes, if I see that correctly (have not studied it yet), that not 
more that one ID will be created per second.  Or do you have something in place 
that will catch this, for example if someone uses the mapping API to assign IDs 
to a whole bunch of entries in a short time?

You are right that this is not documented in the manual, even though it is used 
for lings and for attachments.  Maybe it would be good to explain it in an 
appendix to the manual?  Would you like to draft such a section, since you have 
been looking into this problem?

Do you think the default setting for Org should be modified?

Carsten

On Fri, Aug 2, 2019 at 5:14 PM Gustav Wikström 
mailto:gus...@whil.se>> wrote:
Hi!

I've pushed a couple of fixes and changes to master related to org-id.

First; a fix and a (major) speedup and method-change for how the
global caching works for ID's. The change in method is that providing
file's as arguments to org-id-update-id-locations no longer breaks the
existing id locations.

Second; I've added a customization so one can choose to cache the
id-locations as relative to the org-id-locations-file instead of as
absolute links. This helps a lot when running a system mirrored on
multiple machines where the absolute paths to ones documents might
differ, but where it's all the same relative to the
org-id-locations-file.

Third; I've added another ID generator method. The extremists might
say the new method is not unique enough but org-mode is a personal
system first and foremost, so I think there is merit to this new ID
method. It creates ID's based on current timestamp and doesn't try to
hide the timestamp from the user. One might call the ID's "natural"
since they are contain information in themselves. Certainly a good
thing for some. The new method will not be active unless explicitly
chosen by the user.

As a side note, if using ID's together with attachments, try this
new ID-generator out by setting org-id-method to ts (short for
timestamp) and change the org-attach-id-to-path-function to
something like "/MM/DDTHHMMSS" for more human readable
attachment folders.

Org-id is next to undocumented in the manual so I didn't find a good
place to add this. A few lines are added to org-news though.

This is the first push by me without first doing an RFC. So,
naturally, if anything is out of order mail back and/or make changes
directly in the repo if needed. Tests passed anyways.

Kind regards
Gustav

[O] [RFC] Org document concept + document property drawers

[Gustav Wikström]

Hi!

I'm continuing on my proposal to introduce a "document" element in
org-mode and the idea of seeing everything before the first headline
as the base level 0 outline for a file. I've attached two patches that
I'd like some public review of before pushing to master.

Patch 0001 introduces the document element into org-element.el, and
some restructuring related to that.

Patch 0002 makes it possible to use property drawers at the document
level. I've hopefully covered all related commands to make this work.
And I've added a bunch of tests to guard against future regressions.

Waiting for your comments!

Kind regards Gustav


0001-New-top-level-document-concept-and-minor-restructure.patch
Description: 0001-New-top-level-document-concept-and-minor-restructure.patch


0002-Org-document-property-drawers.patch
Description: 0002-Org-document-property-drawers.patch

Re: [O] org-id fixups and minor changes

[Gustav Wikström]

I’ve committed a minor fix to add parts of a second to the ISO 8601 version if 
the ID.

https://code.orgmode.org/bzg/org-mode/commit/dea0c70c7b9036f386d36dfc8864ac0e431f9d25

/G

From: Carsten Dominik 
Sent: den 1 september 2019 10:36
To: Stig Brautaset 
Cc: Gustav Wikström ; org-mode list 
Subject: Re: [O] org-id fixups and minor changes


On Sun, Sep 1, 2019, 08:49 Stig Brautaset 
mailto:s...@brautaset.org>> wrote:
Hi Gustav,

Gustav Wikström mailto:gus...@whil.se>> writes:
> [...] I also wonder how common it will be to try to batch-add ID’s…?

Not especially uncommon, I think.  Both the org-rss and org-drill
packages batch-add IDs on first use.

And even if that would be uncomment - at least the defaults need to be safe.

Carsten


Regards,
Stig

Re: [O] [RFC] Org document concept + document property drawers

[Gustav Wikström]

Hi Nicolas,

> -Original Message-
> From: Nicolas Goaziou 
> 
> > I'm continuing on my proposal to introduce a "document" element in
> > org-mode and the idea of seeing everything before the first headline
> > as the base level 0 outline for a file. I've attached two patches that
> > I'd like some public review of before pushing to master.
> 
> I will not review fully the patches, as I have no time for that.
> However, I will make a few comments about it.
> 
> First, you should show a few examples of what an Org document would look
> like, compared to what we have already, focusing particularly on the
> advantages, and what is now invalid. It is a good thing to do if you
> expect comments, as you cannot ask everyone to eyeball through the whole
> patch set.

Sure, I'll do that as a reply to my own mail to not make that comment
disappear among the details here.

> Also, whatever the outcome of the discussion is, /nothing should go in
> master as long as Org 9.3 is not released/. This looks like a breaking
> change at the most lower level (syntax, parser...), I think it may
> trigger a new major release.

I'm starting out slow by making this a non-breaking change. At least
I'm trying to. I.e. everything that worked before should continue to
work.

> > Patch 0001 introduces the document element into org-element.el, and
> > some restructuring related to that.
> 
> This should be explained in comments, and, if it lands at some point,
> Worg pages about syntax and exporter should be updated, too.

Which comments do you mean? I've tried to be rigorous in the patch
notes. But you mean in the mail itself?

> 
> > ** (renamed, modified) org--setup-collect-keywords -> org-collect-keywords
> > Renamed and generalized org--setup-collect-keywords to make it work
> > for multiple purposes.  Is not limited to a fixed set of keywords any
> > longer.  New name: org-collect-keywords.
> 
> An important typo note: we use "Org mode", or "an Org document", not
> "Org-mode" and "an org-document". Hyphens are only used to refer
> explicitly to a Lisp symbol, or its value or function.

Ah of course. I keep forgetting that one.

> 
> > ** (modified) org-element-keyword-parser
> > Uses (new) org-keyword-regexp instead of hardcoding it's own regexp.
> 
> Keep in mind that Org Element library should ultimately be as
> independent as possible to the other parts of Org, including "org.el".

Got it - is it preferred to do it the other way around - I.e. define
the regexp in org-element.el rather than org.el if there is use of the
regexp in both files?

> > +;; Org-element can parse org-mode documents.  The top-node in the
> > +;; parse-tree will always have TYPE `org-data' and PROPERTIES nil.
> 
> See my remark about typography above.

Got it.

> 
> > +;; The following part creates a fully recursive org-mode parser.
> 
> Ditto.

Ok, ofc.

> > +(defun org-back-to-heading-or-point-min ( invisible-ok)
> > +  "Go back to heading or first point in buffer.
> > +If point is before first heading go to first point in buffer
> > +instead of back to heading."
> > +  (condition-case nil
> > +  (outline-back-to-heading invisible-ok)
> > +(error
> > + (goto-char (point-min)
> 
> Try to limit use of Outline functions. They are generally slower than
> their Org counterpart. This is not true in this case, but, one day, we
> might optimize `org-back-to-heading'.

Noted, except in this case I think it's warranted since
org-back-to-heading behaves exactly the same with the exception of
raising an error if before the first heading. Since both functions are
defined next to another I'm sure a later refactor will take care of
both since they're structurally identical and defined two lines apart.

> > +(defun org-at-keyword-p nil
> > +  "Is cursor at a keyword-line?"
> 
> Non-nil if ...

I've just "pattern-matched" myself into that docstring. It matches the
existing definitions of org-at-drawer-p, org-at-comment-p,
org-at-block-p. Which are defined around this.

> > +  (save-excursion
> > +(move-beginning-of-line 1)
> > +(looking-at org-keyword-regexp)))
> 
> While this is technically correct today, please don't write a predicate
> only based on regexps, use the parser for that. For example, the parser
> can understand
> 
>   #+begin_example
>   #+keyword: not a keyword
>   #+end_example
> 
> whereas your function cannot.

Hmm... I see your point. Have to think a bit here - because I have the
feeling that defining the predicate using org-element-at-point will
incur quite a performance hit. Or what is your intuition regarding
that?

> 
> Also, you could use `org-match-line' in this case.
> 
> 
> Regards,
> 
> --
> Nicolas Goaziou

Thanks for your initial thoughts.

/G

Re: [O] [RFC] Org document concept + document property drawers

[Gustav Wikström]

Hi Adam,

> This is a very interesting idea, and I don't want to dismiss your work,
> but I am concerned about how much third-party code will likely break by
> changing the results returned by org-element for parsing an Org buffer.
> I haven't thoroughly studied all of the code in your patches, so I may
> be wrong, but I think the breakage could be extensive.  For example,
> simple operations like destructuring the results of org-element parsing
> functions may be broken.  Have you done any investigation into this
> issue?
> 
> Maybe there should be a transitional period in which the existing
> org-element parsing functions would work as before, and the new
> document-level elements would be returned by a new org-element
> document-level parsing function.  Frankly, if there is breakage,the
> transition would probably take a few years, because there is a lot of
> code out there that has worked for years and may not be updated or
> replaced for years.

I have not investigated much into that to be honest. I'd argue that
it's a fairly trivial change in terms of the parser though. Everything
will work as before except when you're after the whole buffer
syntax-tree. In that case one will have to dig one step deeper into
the tree to find the content.

Previous tree: 
(org-data nil CONTENTS)

With this patch:
(org-data nil (document (doc-props) CONTENTS))

Yeah.. The structure changed a bit. But it's a fairly trivial change 
in my opinion. Everything else works as before AFAIK... But I might be 
overseeing something. Please enlighten me in that case!

I've made specification-changes only at two locations in the
test-cases for org-element. (ref. patch nr.1) 

Best
Gustav