Re: [O] [RFC] Document level property drawer

[Gustav Wikström]

Hi!

I'll start with the most important info at the top. I've applied the
patch! But before anyone comes screaming I'll just say it's applied on
a separate branch. After consultation with Nicolas Goaziou that was
seen as the most reasonable thing to do. The idea is that it's high
time to start wrapping up 9.3 for a release and (even though I
personally would like to have this in there) since this patch might
continue to generate discussion and possibly bugs and fixes it's more
safe to let this come after the 9.3 release.

Sooo, a separate branch is created in the Org mode repository named
"next". I'm not entirely sure how we're supposed to work with it. But
I've anyways pushed my (non-breaking) patch there.

Comments on what you've written below!

Marco Wahl writes:

> > @Marco Wahl; As I understand you've applied the patch and tried it
> > out. Have you found any issues yet? What do you think of the patch
> > after having used it for a while?
> 
> Indeed I applied your patch and have it applied still.  Please note that
> I did nothing fancy and in particular I did not try to break the patch.

Got it.

> The patch works good for me.

Nice to hear!

> Noteworthy observations AFAICT:
> 
> 1. I could not translate my personal "#+TODO: . N ~ | x c g >" into a
> respective :TODO: property.

Yes, that's true. The reason is that there is no TODO-property that
fits in property drawers right now. I.e. special properties such as
TODO, TAGS, priority, scheduling and deadlines that have special
syntax for the outline still have no defined meaning for outline level
0. I ofc. think that's an oversight ;) But I may also be a bit crazy. 

A conclusion to draw from that, that may be worth writing more about,
is that the property drawer for node level 0 will not be able to
replace all file-level keywords that exist today.  Only properties that
currently can also be defined in property drawers in the outline will
work in the property drawer on level 0.  Makes sense?

The idea I had for all the other keywords that apply for the whole
file was to create another drawer, what I called a settings drawer.
Because the TODO-keyword you refer to above really is a setting that
you're making for the current file, much the same as when you make
changes in global, folder local or file local variables using the
standard emacs framework.

I've attached an investigation I did of the world of Org mode
keywords. It was done quite a while back and some things in there are
subjective and may not represent my current picture of the "ideal".
Nonetheless, maybe an interesting read for the ... other crazy people
out there?

> 2. With org-ids turned on and point before the first heading, function
> org-store-link creates an org-id property at the document level.
> 
> Regarding number 1. I think a list of document-level properties which
> don't behave the same when used in the document property drawer would be
> nice.  Ideally this list is empty AFAICT.  Maybe I overlook something.
> Is this an issue?

Ahh, see the attachment ;) Maybe can give answers to some of your
thoughts.

> I think observation 2. is just a little surprise but turns out to be
> natural when the document level property drawer is enabled.

Glad to hear!

> 
> 
> Still +1 for the inclusion of the patch and HTH,
> -- 

Thanks
Gustav


Investigation.org
Description: Investigation.org

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

[Gustav Wikström]

Hi again,

FYI, I’ve applied a patch that will make it easier to change the default 
without breaking any existing functionality. I.e. we can avoid breakage for 
existing attachment-folders if we at some point in the future would choose to 
change default for ID’s to timestamp.

Commit 42b8db0d3

/G

From: Gustav Wikström
Sent: den 31 augusti 2019 21:17
To: Carsten Dominik 
Cc: emacs-orgmode@gnu.org
Subject: RE: [O] org-id fixups and minor changes

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 mailto:domi...@uva.nl>>
Sent: den 10 augusti 2019 00:34
To: Gustav Wikström mailto:gus...@whil.se>>
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

Re: [O] Creating a (RabbitMQ) diagram

[Michael Welle]

Hello,

"Fraga, Eric"  writes:

> On Thursday, 17 Oct 2019 at 15:21, Cecil Westerhof wrote:
>> I tried it out (after a bit of configuring) with the following:
>>
>> #+BEGIN_SRC plantuml :file groupingComponents.eps :noexport
>
> [...]
>
>> It looks a bit different, but I will not worry about it at the moment.
>
> I use the following tools within org for eventual export to PDF via
> latex: tikz, ditaa, graphviz (dot, neato, ...), & plantuml.  I've even
> bee known to use LaTeX's own picture environmnt.  They each have
> different advantages and disadvantages but all work well with org in my
> opinion.
so think and do I. At the moment I try to consolidate the tools I use
and try to get away with tikz only. I tried to reproduce same diagrams I
created with plantuml. Well, it works. But there are a lot of details in
plantuml's output that you have to do manually with tikz. BTW, I just
discovered that plantuml's pdf output is way different from its LaTeX
output.

Regards
hmw