From: Samuel Wales <samologist@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Bastien <bzg@altern.org>, Org Mode List <emacs-orgmode@gnu.org>,
Nicolas Goaziou <n.goaziou@gmail.com>
Subject: Re: About commit named "Allow multi-line properties to be specified in property blocks"
Date: Wed, 9 Nov 2011 10:40:59 -0700 [thread overview]
Message-ID: <CAJcAo8uG=p6FE7Ud0ayv4t8Ox-u43iQHacHbnxqDX-tqHqOvrg@mail.gmail.com> (raw)
In-Reply-To: <87k47hgin2.fsf@gmail.com>
Hi Eric,
On 2011-11-03, Eric Schulte <schulte.eric@gmail.com> wrote:
>>
>> But allowing a top-level :PROPERTIES: drawer with properties
>> whose scope is the entire file looks like a good idea to me.
>>
>
> I don't see what this would add, how would this solve the need for
> multi-line properties, and how would it differ from IMO being uglier
> than a series of #+PROPERTY: lines.
(Your quote is from Bastien, not me.)
The idea the way I put it (which is with a top level entry to hold the
properties drawer) is, as I stated, possibly too radical for the
thread. Possibly too radical period. So feel free to ignore it.
However, let me clarify because I think you might misunderstand.
The idea is not to augment syntax, but reduce it. Or, if backward
compatibility is desired, then reduce the need for future
ambiguous-scope syntax -- which is a currently unresolved problem.
In my view #+ is uglier than existing property syntax -- which has to
exist anyway because it is used for all sorts of things. You can't
get rid of it. (And shouldn't.)
The idea is that a single top-level task, marked as such, acts as if
it were a superlevel, and contains ALL information needed for the file
level.
So there will be no need for #+property .
It is consistent syntax with the rest of Org, unlike file-level or
rest-of-file #+ syntax. It is less ambiguous in scope. It is clear
what it means.
It is foldable. It is searchable the same way other entries are searchable.
The agenda can show it if you want it to (unlike #+whatever).
More consistent all the way around IMO.
If I were designing Org from scratch, I probably would not suggest
this. Instead, I would simply disallow file-level anything. If you
want that, just use a top-level task. a/b/c -- you know, normal
outline. And then export that top level subtree.
To me, and this is admittedly radical, file-level operations should be
deprecated.
But as a compromise, since a lot of people do file-level operations, I
am proposing a dedicated top level place that acts as if it is
hierarchically above everything else even though it is not. That
allows consistency better than #+property IMO.
I am talking about the stuff at the top of the file (title,
properties, etc.) Not blocks etc. Those are reasonable elsewhere.
As for multiple-line properties, you can use the syntax you're
currently discussing to accumulate in the properties drawer, or even
use a syntax to simply allow multiple-line properties in a properties
drawer. Either way.
Again, probably too radical for this thread, but I wanted to clarify.
Hope that clarifies.
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.
prev parent reply other threads:[~2011-11-09 17:41 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-31 19:06 About commit named "Allow multi-line properties to be specified in property blocks" Nicolas Goaziou
2011-10-31 20:05 ` Eric Schulte
2011-10-31 20:49 ` Nicolas Goaziou
2011-10-31 21:30 ` Eric Schulte
2011-11-01 8:24 ` Nicolas Goaziou
2011-11-01 8:36 ` Nicolas Goaziou
2011-11-01 14:36 ` Eric Schulte
2011-11-01 15:39 ` Nicolas Goaziou
2011-11-01 16:58 ` Eric Schulte
2011-11-01 17:48 ` Christian Moe
2011-11-01 19:02 ` Eric Schulte
2011-11-01 19:45 ` Christian Moe
2011-11-01 20:22 ` Eric Schulte
2011-10-31 21:33 ` Christian Moe
2011-10-31 21:22 ` Christian Moe
2011-10-31 21:36 ` Eric Schulte
2011-11-01 7:33 ` Christian Moe
2011-11-02 15:35 ` Bastien
2011-11-02 17:39 ` Nicolas Goaziou
2011-11-03 1:26 ` Bastien
2011-11-03 8:08 ` Christian Moe
2011-11-03 15:10 ` Nick Dokos
2011-11-03 18:32 ` Eric Schulte
2011-11-03 20:01 ` Nicolas Goaziou
2011-11-03 20:18 ` Eric Schulte
2011-11-03 20:23 ` Eric Schulte
2011-11-04 8:02 ` Rainer M Krug
2011-11-04 17:48 ` Darlan Cavalcante Moreira
2011-11-04 19:25 ` Eric Schulte
2011-11-07 22:09 ` Eric Schulte
2011-11-08 8:42 ` Rainer M Krug
2011-11-08 9:31 ` Sebastien Vauban
2011-11-08 9:41 ` Rainer M Krug
2011-11-08 9:58 ` Sebastien Vauban
2011-11-08 10:06 ` Rainer M Krug
2011-11-08 14:42 ` Darlan Cavalcante Moreira
2011-11-08 15:06 ` Sebastien Vauban
2011-11-08 16:03 ` Eric Schulte
2011-11-08 22:53 ` Eric Schulte
2011-11-09 8:25 ` Rainer M Krug
2011-11-09 16:12 ` Eric Schulte
2011-11-09 17:18 ` Rainer M Krug
2011-11-09 22:31 ` Sebastien Vauban
2011-11-15 12:33 ` Rainer M Krug
2011-11-15 16:00 ` Eric Schulte
2011-11-15 16:37 ` Torsten Wagner
2011-11-15 16:56 ` Eric Schulte
2011-11-15 17:13 ` Thomas S. Dye
2011-11-15 18:22 ` Eric Schulte
2011-11-15 17:24 ` Rainer M Krug
2011-11-08 9:41 ` Sebastien Vauban
2011-11-08 9:44 ` Rainer M Krug
2011-11-08 16:01 ` Eric Schulte
2011-11-02 21:05 ` Samuel Wales
2011-11-02 21:21 ` Samuel Wales
2011-11-03 1:42 ` Bastien
2011-11-03 8:19 ` Christian Moe
2011-11-03 18:34 ` Eric Schulte
2011-11-03 18:59 ` Eric Schulte
2011-11-09 17:40 ` Samuel Wales [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJcAo8uG=p6FE7Ud0ayv4t8Ox-u43iQHacHbnxqDX-tqHqOvrg@mail.gmail.com' \
--to=samologist@gmail.com \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).