Feature request [7.3]

Feature request [7.3]

[Dave Abrahams]

When using Org for planning, I often find myself corrupting my Org
files.  All kinds of things can go wrong, but the basic issue is that
agenda items have a syntax, and it's easy to violate, especially when
I'm going *fast*, which after all is what Org is supposed to enable!

For example, a typical captured item looks like:

** TODO Set up yasnippet
   SCHEDULED: <2010-11-22 Mon>
   :PROPERTIES:
   :Link: [[some-nasty-link]]
   :ID:       A0B4159C-D796-40DF-9ADD-93DF03577B68
   :END:
   [2010-11-20 Sat 20:17]

Now, suppose I'm looking at this in the agenda and I want to add some
commentary.  Where should I open the new line?  If I choose wrongly, my
agenda will start to misbehave (e.g. items will appear to be
un-reschedulable because they'll acquire a second SCHEDULED date).  

So I'm requesting some more help from Org in maintaining proper Org
syntax.  Could Org have a mode that prevents things from being modified
incorrectly?  For example, it'd be awesome if dates were smart (TAB into
one, hit return, get a smart date editor).  It'd be great if there were
a way to make the ID property read-only (or really really hard to
change).  I'd love it if there were a way to create a link to an org
item that narrows the view to just that item, so I don't inadvertently
mess anything else up.  Do you get the idea?

Thanks for listening,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Feature request [7.3]

[Jeff Horn]

I don't know about others, but I just put note text below everything
else, but before the next headline

On Tue, Dec 7, 2010 at 3:59 PM, Dave Abrahams <dave@boostpro.com> wrote:
>
> When using Org for planning, I often find myself corrupting my Org
> files.  All kinds of things can go wrong, but the basic issue is that
> agenda items have a syntax, and it's easy to violate, especially when
> I'm going *fast*, which after all is what Org is supposed to enable!
>
> For example, a typical captured item looks like:
>
> ** TODO Set up yasnippet
>   SCHEDULED: <2010-11-22 Mon>
>   :PROPERTIES:
>   :Link: [[some-nasty-link]]
>   :ID:       A0B4159C-D796-40DF-9ADD-93DF03577B68
>   :END:
>   [2010-11-20 Sat 20:17]
>
> Now, suppose I'm looking at this in the agenda and I want to add some
> commentary.  Where should I open the new line?  If I choose wrongly, my
> agenda will start to misbehave (e.g. items will appear to be
> un-reschedulable because they'll acquire a second SCHEDULED date).
>
> So I'm requesting some more help from Org in maintaining proper Org
> syntax.  Could Org have a mode that prevents things from being modified
> incorrectly?  For example, it'd be awesome if dates were smart (TAB into
> one, hit return, get a smart date editor).  It'd be great if there were
> a way to make the ID property read-only (or really really hard to
> change).  I'd love it if there were a way to create a link to an org
> item that narrows the view to just that item, so I don't inadvertently
> mess anything else up.  Do you get the idea?
>
> Thanks for listening,
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
>
>
> _______________________________________________
> 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
>



-- 
Jeffrey Horn
Graduate Lecturer and PhD Student in Economics
George Mason University

(704) 271-4797
jhorn@gmu.edu
jrhorn424@gmail.com

http://www.failuretorefrain.com/jeff/

Re: Feature request [7.3]

[Eric S Fraga]

Dave Abrahams <dave@boostpro.com> writes:

> When using Org for planning, I often find myself corrupting my Org
> files.  All kinds of things can go wrong, but the basic issue is that

I do have a couple of rules I follow to avoid problems. 

1. I usually have a blank line between the meta data (scheduled,
   properties) and any subsequent text, whether part of that entry or
   the following headline.  I accomplish this by ensuring that my
   capture templates all insert such a blank line, typically followed by
   the date of insertion.

2. I also always use the =C-c C-d=, =C-c C-s= and =C-c C-x p= sequences
   to manage the meta data so org takes care of keeping things sane.


However:

[...]

> So I'm requesting some more help from Org in maintaining proper Org
> syntax.  Could Org have a mode that prevents things from being modified
> incorrectly?  For example, it'd be awesome if dates were smart (TAB into
> one, hit return, get a smart date editor).  

This would be quite nice, even something as simple as having RET, within
a time stamp, doing the equivalent of org-time-stamp or
org-time-stamp-inactive depending on the current state of the time
stamp.

> It'd be great if there were
> a way to make the ID property read-only (or really really hard to
> change).

This is where column mode comes in quite handy?  I tend to use column
mode to edit properties and so I never come near the ID property as it
usually isn't displayed.

> I'd love it if there were a way to create a link to an org
> item that narrows the view to just that item, so I don't inadvertently
> mess anything else up.  

org-narrow-to-subtree does some of this...

HTH,
eric

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

Re: Feature request [7.3]

[Dave Abrahams]

At Wed, 08 Dec 2010 16:20:44 +0000,
Eric S Fraga wrote:
> 
> Dave Abrahams <dave@boostpro.com> writes:
> 
> > When using Org for planning, I often find myself corrupting my Org
> > files.  All kinds of things can go wrong, but the basic issue is that
> 
> I do have a couple of rules I follow to avoid problems. 
> 
> 1. I usually have a blank line between the meta data (scheduled,
>    properties) and any subsequent text, whether part of that entry or
>    the following headline.  I accomplish this by ensuring that my
>    capture templates all insert such a blank line, typically followed by
>    the date of insertion.

Nice idea; I'll get right on it.

> 
> 2. I also always use the =C-c C-d=, =C-c C-s= and =C-c C-x p= sequences
>    to manage the meta data so org takes care of keeping things sane.

Understood; I do that too ... well, sometimes I add properties
manually but only because I forget the keybinding, and I always get
that right because it's trivially easy.  The problems creep in when
I'm not watching carefully and typing fast, or maybe when my
3-year-old visits my keyboard, or... life happens.  Then things can
effectively drop off my TODO list silently, which is really
problematic!  I know there are ways to mitigate the risk, but I really
want a new feature: in general I really don't want Org to *let* me
edit most of the file as plain text most of the time.

> However:
> 
> [...]
> 
> > So I'm requesting some more help from Org in maintaining proper Org
> > syntax.  Could Org have a mode that prevents things from being modified
> > incorrectly?  For example, it'd be awesome if dates were smart (TAB into
> > one, hit return, get a smart date editor).  
> 
> This would be quite nice, even something as simple as having RET, within
> a time stamp, doing the equivalent of org-time-stamp or
> org-time-stamp-inactive depending on the current state of the time
> stamp.

Right.  But Org could be smart about the whole "grammar" of items and
only allow freeform editing where it wouldn't do any serious damage.

> > It'd be great if there were a way to make the ID property
> > read-only (or really really hard to change).
> 
> This is where column mode comes in quite handy?  

Link please?

> I tend to use column mode to edit properties and so I never come
> near the ID property as it usually isn't displayed.

My properties are usually collapsed, so I usually don't see them
either.  But I don't want a special mode.  I want org to understand
and manage its own syntax.

> > I'd love it if there were a way to create a link to an org
> > item that narrows the view to just that item, so I don't inadvertently
> > mess anything else up.  
> 
> org-narrow-to-subtree does some of this...

Yes, some of it, but not all of it.  But the point is that these are
just examples.  I think Org wasn't designed with the idea that it
would end up having much of a "grammar," but it grew one.  I'm arguing
for a UI re-think for the tool Org has become.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Feature request [7.3]

[Eric S Fraga]

Dave Abrahams <dave@boostpro.com> writes:

[...]

>> > It'd be great if there were a way to make the ID property
>> > read-only (or really really hard to change).
>> 
>> This is where column mode comes in quite handy?  
>
> Link please?

Apologies;  I meant column view within org mode: info -> org ->
Properties and Columns -> Column view


[...]

> But the point is that these are just examples.  I think Org wasn't
> designed with the idea that it would end up having much of a
> "grammar," but it grew one.  I'm arguing for a UI re-think for the
> tool Org has become.

Yes, I can see what you are getting at.  However, one of the nicest
things about org is that it doesn't necessarily impose a structure on
everything and so a formal grammar could get in the way.  One could
argue that the flexibility of the system is it's main source of
effectiveness!  That and the fact that it is based on pure text.
However, this doesn't argue against improvements in the user interface
when necessary!

-- 
Eric S Fraga (: http://www.homepages.ucl.ac.uk/~ucecesf/ :)

Re: Feature request [7.3]

[Dave Abrahams]

At Thu, 09 Dec 2010 08:57:54 +0000,
Eric S Fraga wrote:
> 
> Dave Abrahams <dave@boostpro.com> writes:
> 
> [...]
> 
> >> > It'd be great if there were a way to make the ID property
> >> > read-only (or really really hard to change).
> >> 
> >> This is where column mode comes in quite handy?  
> >
> > Link please?
> 
> Apologies;  I meant column view within org mode: info -> org ->
> Properties and Columns -> Column view

Wow, having that on completely messes up the agenda view!

> [...]
> 
> > But the point is that these are just examples.  I think Org wasn't
> > designed with the idea that it would end up having much of a
> > "grammar," but it grew one.  I'm arguing for a UI re-think for the
> > tool Org has become.
> 
> Yes, I can see what you are getting at.  However, one of the nicest
> things about org is that it doesn't necessarily impose a structure on
> everything and so a formal grammar could get in the way.  

I'm not asking to change the grammar, I'm just asking the editor to be
smarter about the grammar that has actually evolved.

> One could argue that the flexibility of the system is it's main
> source of effectiveness!  

Could, but total flexibility doesn't work for everyone.

> That and the fact that it is based on pure
> text.  However, this doesn't argue against improvements in the user
> interface when necessary!

...or even "when possible?"

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Feature request [7.3]

[Manish]

On Wed, Dec 8, 2010 at 2:29 AM, Dave Abrahams wrote:
>
> When using Org for planning, I often find myself corrupting my Org
> files.  All kinds of things can go wrong, but the basic issue is that
> agenda items have a syntax, and it's easy to violate, especially when
> I'm going *fast*, which after all is what Org is supposed to enable!
>
> For example, a typical captured item looks like:
>
> ** TODO Set up yasnippet
>   SCHEDULED: <2010-11-22 Mon>
>   :PROPERTIES:
>   :Link: [[some-nasty-link]]
>   :ID:       A0B4159C-D796-40DF-9ADD-93DF03577B68
>   :END:
>   [2010-11-20 Sat 20:17]
>
> Now, suppose I'm looking at this in the agenda and I want to add some
> commentary.

I am not sure what you mean by agenda here since you don't see the
full entry in the agenda.

> Where should I open the new line?  If I choose wrongly, my
> agenda will start to misbehave (e.g. items will appear to be
> un-reschedulable because they'll acquire a second SCHEDULED date).
>

When in the entry in org file, use `C-c C-z' and when in agenda just
use `z' to add a correctly formatted  and timestamped note.

> So I'm requesting some more help from Org in maintaining proper Org
> syntax.  Could Org have a mode that prevents things from being modified
> incorrectly?  For example, it'd be awesome if dates were smart (TAB into
> one, hit return, get a smart date editor).

FWIW, I find shift+up/down arrow sufficiently magical for my use case,
but I suppose you have already tried that.

> It'd be great if there were
> a way to make the ID property read-only (or really really hard to
> change). I'd love it if there were a way to create a link to an org
> item that narrows the view to just that item, so I don't inadvertently
> mess anything else up.  Do you get the idea?

You mean like if you clicked/returned on an item in agenda it should
take you to the entry in org file but narrowed to that item?  I had
earlier added a call to org-narrow (I think) to the code that enables
follow mode and the code that jumps to the entry in the org file.  It
used to work nice but was a minor irritation when I needed to widen it
all the time.  I have since lost the code but it should be reasonable
easy to reproduce.

HTH
-- 
Manish

Re: Feature request [7.3]

[Dave Abrahams]

At Wed, 8 Dec 2010 23:11:09 +0530,
Manish wrote:
> 
>  Manish <mailtomanish.sharma@gmail.com>
> Subject: Re: [Orgmode] Feature request [7.3]
> Date: Wed, 8 Dec 2010 23:11:09 +0530
> To: Dave Abrahams <dave@boostpro.com>
> Cc: emacs-orgmode@gnu.org
> Message-ID: <AANLkTikjaXo4BM1gbiGNZvjYZRddYRFQY_0VbWHcWqqv@mail.gmail.com>
> 
> On Wed, Dec 8, 2010 at 2:29 AM, Dave Abrahams wrote:
> >
> > When using Org for planning, I often find myself corrupting my Org
> > files.  All kinds of things can go wrong, but the basic issue is that
> > agenda items have a syntax, and it's easy to violate, especially when
> > I'm going *fast*, which after all is what Org is supposed to enable!
> >
> > For example, a typical captured item looks like:
> >
> > ** TODO Set up yasnippet
> >   SCHEDULED: <2010-11-22 Mon>
> >   :PROPERTIES:
> >   :Link: [[some-nasty-link]]
> >   :ID:       A0B4159C-D796-40DF-9ADD-93DF03577B68
> >   :END:
> >   [2010-11-20 Sat 20:17]
> >
> > Now, suppose I'm looking at this in the agenda and I want to add some
> > commentary.
> 
> I am not sure what you mean by agenda here since you don't see the
> full entry in the agenda.

Exactly.  Sometimes I am dealing with agenda items from plain org.
For example, if I've stored a link to the item and follow it from an
agenda item, I end up in my todo.org file.

> > Where should I open the new line?  If I choose wrongly, my
> > agenda will start to misbehave (e.g. items will appear to be
> > un-reschedulable because they'll acquire a second SCHEDULED date).
> >
> 
> When in the entry in org file, use `C-c C-z' and when in agenda just
> use `z' to add a correctly formatted  and timestamped note.

Yes, I use those keys.  The problem is that I edit fast, and an errant
key here or there can blow the syntax of items to heck.

> > So I'm requesting some more help from Org in maintaining proper Org
> > syntax.  Could Org have a mode that prevents things from being modified
> > incorrectly?  For example, it'd be awesome if dates were smart (TAB into
> > one, hit return, get a smart date editor).
> 
> FWIW, I find shift+up/down arrow sufficiently magical for my use case,
> but I suppose you have already tried that.

Yes, I've tried all the simple things.  I'm really asking for regular
org to act more like the agenda in some ways.

> > It'd be great if there were
> > a way to make the ID property read-only (or really really hard to
> > change). I'd love it if there were a way to create a link to an org
> > item that narrows the view to just that item, so I don't inadvertently
> > mess anything else up.  Do you get the idea?
> 
> You mean like if you clicked/returned on an item in agenda it should
> take you to the entry in org file but narrowed to that item?  

spacebar already does that.  But if I have an *org link* to an 

  [[id: ... ]] 

item and follow that I end up with no narrowing.

> I had earlier added a call to org-narrow (I think) to the code that
> enables follow mode and the code that jumps to the entry in the org
> file.  It used to work nice but was a minor irritation when I needed
> to widen it all the time.  I have since lost the code but it should
> be reasonable easy to reproduce.

That's nice, but not what I'm asking for.  I'm asking for a
comprehensive re-think of editing in plain org mode.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com