Hi Torsten,
thanks for the mock-ups -- very useful to get a quick overview.
I'm still reluctant to implement what you propose, because the
two issues (cycling and hiding) are still too intertwined for me.
Here is how I would like the problems:
1. The fact that property drawers with only "techn
On 8/2/2012 11:10 AM, Bastien wrote:
If the whole point is to make some properties less visible,
why not a solution based on fontification?
We could have a user-defined regexp to highlight (or "dim")
certain properties.
That would still leave the :PROPERTIES: line visible, which is problem
for
On 8/6/2012 2:16 PM, Allen S. Rout wrote:
One common use would be to store the creation & last-modification dates
of each entry. I've tried various ways of doing it and they all were
too obtrusive to use on _every_ entry. Time-stamping of all entries
would be extremely useful, just as time-sta
Separating out the issue of how to hide and expose the content, why not
use s-expressions for the hidden content? Org is built on a lisp engine
and these will fit nicely into automation. It avoids a lot of parsing
and other headaches, and an s-expression can hold any of the discussed
information
Hey Christopher,
>* All entries are unfolded one level
>** Only "hidden" properties with other content
> This is more content
>
> The ":PROPERTIES:" is not shown.
I left it there, because some people claimed the dislike to hide
property drawers to much. A different face colour might
Nice! I like this approach. The only slight change I would make is to
the "All entries are unfolded one level". If there are only "hidden"
properties but there is other content, show the other content but not
the PROPERTIES drawer:
* All entries are unfolded one level
** Only "hidden"
Hey Bastien,
On 7 August 2012 19:23, Bastien wrote:
> that a drawer doesn't make an
> entry non-empty while cycling,
ohhh you challenge us... "does not ... non-empty" is in fact the
same like "if there is only a drawer, the entry is still empty"
right ?!
Yes, I agree that should be sepa
Torsten Wagner writes:
> So how to satisfy both views, a clutter free view and the awareness of
> what is saved in your file?
I think we must untangle two issues here: one is about the visibility by
itself (what should be visible, invisible, how visible, how invisible?)
and the other one is abou
Hi,
I would say this discussion is just showing how difficult it becomes
to save all extra information provided by more and more 3rd party
tools in a smart way in plain-text.
I can understand both arguments
* hide stuff which is not useful or needed for the user vs.
* its my data and my file, I
On Mon, Aug 6, 2012 at 8:16 PM, Allen S. Rout wrote:
> Org is my life in plain text, not WordPerfect with reveal-codes.
I always wondered what Ford Prefect is doing in the Org Manual and why
he is related with Org. :-))
Michael
On 08/04/2012 02:10 PM, Ilya Shlyakhter wrote:
One common use would be to store the creation & last-modification dates
of each entry. I've tried various ways of doing it and they all were
too obtrusive to use on _every_ entry. Time-stamping of all entries
would be extremely useful, just as ti
On Mon, Aug 6, 2012 at 8:12 AM, Jonathan Leech-Pepin
wrote:
> The issue I can see with completely hiding :PROPERTIES: line is
> that you would then run the risk of adding text at the wrong
> location (between the headline and the drawer for example). At
> the moment when the drawer is folded you
Hi Folks,
I thought I'd throw in my 2c on the topic. I work on org-toodledo which
syncs TODO items with Toodledo.com. On first sync, it creates adds a
"ToodledID" property to track the ID assigned by the server.
In my use case, that majority of TODO items have *no* other properties.
As su
Hello,
On Sun, Aug 5, 2012 at 11:01 PM, Ilya Shlyakhter wrote:
> On Sun, Aug 5, 2012 at 10:46 PM, Torsten Wagner
> wrote:
>> I can see the point that the property drawer header can be annoying
>> too. Actually, when I used orgmobile for the first time I was not too
>> happy to see all this prope
On Sun, Aug 5, 2012 at 10:46 PM, Torsten Wagner
wrote:
> I can see the point that the property drawer header can be annoying
> too. Actually, when I used orgmobile for the first time I was not too
> happy to see all this property drawers suddenly appearing in my files.
> Alternatively to a new ki
Hey,
during this discussions people already claimed that they would prefer
to know what is stored and I can understand this.
That was the reason for the proposal of a HIDDEN_PROP: line to mark
certain properties hidden.
The benefit of this approach, people are actively aware of what they
hide and
On Sun, Aug 5, 2012 at 6:20 PM, Nicolas Goaziou wrote:
>> What about a HIDDEN_PROPERTIES drawer that, when folded, folds
>> completely (so that its title line is hidden too), and have a key to
>> reveal such drawers (the way M-tab opens archived entries)?
>
> This is begging for problems. At some
Hello,
> What about a HIDDEN_PROPERTIES drawer that, when folded, folds
> completely (so that its title line is hidden too), and have a key to
> reveal such drawers (the way M-tab opens archived entries)?
This is begging for problems. At some point, an user will start to
notice weird behaviour h
On 8/5/2012 5:16 AM, Bastien wrote:
Hi Ilya,
Ilya Shlyakhter writes:
But I don't want to see the timestamps during normal Org usage.
What do you think of "hiding" them by having a new face for properties
matching a custom regexp? This has the advantage of letting the user
decide what to do
Hi Ilya,
Ilya Shlyakhter writes:
> But I don't want to see the timestamps during normal Org usage.
What do you think of "hiding" them by having a new face for properties
matching a custom regexp? This has the advantage of letting the user
decide what to do with such properties: either hiding o
On 7/31/2012 9:23 AM, Robert Horn wrote:
I agree. The real use needs more clarification. Things like ID are
already well hidden as :PROPERTIES: until the user explicitly opens the
drawer for viewing. I don't understand the need to hide those further, so
a better explanation of why is needed.
If the whole point is to make some properties less visible,
why not a solution based on fontification?
We could have a user-defined regexp to highlight (or "dim")
certain properties.
I don't believe in a solution that would change the current
flow of cycling through drawers. I feel that's too mu
Hey Bhastien,
thanks for keeping the topic up. Well, I guess people who are dealing
with import/export from third-party programs might have an idea how to
use this functionality (and can tell us how useful this would be). I
can try to contact the authors of mobileorg for iphone and android as
well
Hi Achim,
well the HIDE_PROP approach would have the benefit that one can easily
and quickly change what he wants to see and what he wants to hide at a
single place within his org-file. E.g., I might like to hide almost
all and everything in a drawer normally, but need to work on special
propertie
Bernt Hansen writes:
> Or just use two drawers... PROPERTIES and SYNCDATA (or some other
> appropriate name) so you unfold the on you care about and leave the
> other folded. That seems a lot simpler than stops in drawers...
It might seem to, but I'm actually using this right now (LOGBOOK and
CLO
Achim Gratz writes:
> Torsten Wagner writes:
>> One Idea I had and which was mentioned by Rasmus already too, would be
>> to use the same property block but being able to hide certain
>> properties
>>
>> #+ HIDE_PROP: ID, UUID, ODF_PROP, MOBILE_ORG_PROP
>
> I don't think that moves us into the ri
Torsten Wagner writes:
> One Idea I had and which was mentioned by Rasmus already too, would be
> to use the same property block but being able to hide certain
> properties
>
> #+ HIDE_PROP: ID, UUID, ODF_PROP, MOBILE_ORG_PROP
I don't think that moves us into the right direction...
Let me again s
Hi Thorsten,
thanks for the detailed example. As I said, I tend to be conversative
about such topics. Not because I'm already too old, but because this is
often not worth the time-to-implement/complexity-in-code. So I'm still
open to read a very compelling case where "tech" properties need to b
Hi Robert,
Please see my follow up post with a more detailed description and a
(as I find) already better solution.
In summary, it is about providing a way to store data in org-mode
which is not intended to be read/modified by humans.
Your idea would be one part of it and I was thinking of that to
Jonathan Leech-Pepin writes:
> Hi,
>>> This blocks could be hidden under all normal means unlike
>>> really someone want to see them and hit a special
>>> key-combo.
>>
>> Hmm, personally I'd rather have it visible but clearly
>> labeled. Transparency is nearly always a good thing.
>>
>
I agree.
Hi,
I was aware that some people would prefer a more transparent way.
I think a technical property block accessible for third party sync
tools would make it much easier for the developers of those tools.
On the other hand I understand that people want to know what is stored
along within there org-
Hi,
On Mon, Jul 30, 2012 at 10:42 AM, Ivy Foster wrote:
> On 30 Jul 2012, at 11:26 am +0900, Torsten Wagner wrote:
>> Hi,
>
> Hi,
>
>> [Because of the problems of syncing and interaction with
>> third-party programs] I was wondering if it would be time
>> to switch org-mode from text to some sort
On 30 Jul 2012, at 11:26 am +0900, Torsten Wagner wrote:
> Hi,
Hi,
> [Because of the problems of syncing and interaction with
> third-party programs] I was wondering if it would be time
> to switch org-mode from text to some sort of XML.
I mostly lurk on this list, but reading the preceding
prop
On Mon, Jul 30, 2012 at 11:27:28AM +0100, Rasmus wrote:
> Bastien writes:
>
> > I don't think this is about plain text vs ?? la XML (because XML and
> > friends are plain text too) but about whether we should allow a new
> > type of block to keep non-human-readable stuff out of the way.
>
> How ab
Bastien writes:
> I don't think this is about plain text vs à la XML (because XML and
> friends are plain text too) but about whether we should allow a new
> type of block to keep non-human-readable stuff out of the way.
How about just allowing for a list of properties being hidden. For
instanc
Hi Torsten,
I don't think this is about plain text vs à la XML (because XML and
friends are plain text too) but about whether we should allow a new
type of block to keep non-human-readable stuff out of the way.
One thing I don't get is how these blocks would be more hidden than
normal blocks or d
Hi,
I notice that with all this upcoming syncing and interaction with
third party programs as well as with programming languages org-mode
starts to require more and more information which are actually not
intend to be read in plain text. E.g. a UUID-number for each task to
enable two-way syncs wit
37 matches
Mail list logo
