Re: [O] CUSTOM_ID vs ID
Hi Nate, Nathan Neff writes: > However, I usually *do* manually assign IDs (not CUSTOM_IDs) myself. > The reason is so I can reasonably search for the ID within my org > files and that the link ID makes some sense to me. > > For example, if I see a link to "id:keyboard_shortcuts" I can tell where > it's going. If this is what you want IDs for, then you probably want CUSTOM_ID. There is built-in Org syntax for links based on CUSTOM_ID: write your links like [[#some-custom-id]] or [[file:foo.org::#some-custom-id]]. And if you use CUSTOM_ID, then if you ever need ID later (e.g., for something like org-caldav), you won't have a collision between the two different properties. -- Best, Richard
[O] Release 9.2.5
Hi all, I've released Org 9.2.5, a bugfix release. Enjoy! -- Bastien
Re: [O] Cross reference in TeXinfo export
Hi Nicolas,
thank you for that pointer. I'll see if I can figure out what is going on
and if I can propose a solution.
Carsten
On Mon, Jul 15, 2019 at 12:10 PM Nicolas Goaziou
wrote:
> Hello,
>
> Carsten Dominik writes:
>
> > I noticed that the link in the following line in org-guide.org
> >
> > This document is a much compressed derivative of the
> > [[info:org][comprehensive Org mode manual]].
> >
> >
> > gets turned into this in orgguide.texi
> >
> > @ref{Top,comprehensive Org mode manual,,org,}.
> >
> >
> > The PDF version of the guide then looks like this:
> >
> > This document is a much compressed derivative of the org.
> >
> >
> > So the link description in the PDF version is just "org", the name of the
> > info node. I think the link text should be "comprehensive Org mode
> > manual". Is anyone familiar enough with the texinfo exporter and texinfo
> > to fix this?
>
> Actually, this is not about the Texinfo exporter (ox-texinfo.el), but
> the library responsible for handling info links (ol-info.el).
>
> Maybe we should use
>
> @ref{Top,comprehensive Org mode manual,,org,comprehensive Org mode
> manual}
>
> instead. But what should we do when a section is specified, e.g.,
>
> @ref{Section Name, description,,org,}
>
> ?
>
> Regards,
>
> --
> Nicolas Goaziou
>
>
[O] [PATCH] ob-plantuml.el support for non-UML diagrams
Hello, ob-plantuml encloses the body of PlantUML ( http://plantuml.com) diagram code with @startuml/@enduml clauses. Recent versions of PlantUML support non-UML diagrams like gantt, mindmap and others that needs to be enclosed with @startgantt/@endgantt and @startmindmap/@endmindmap clauses. I created a patch that only inserts @startuml and @enduml if the body does not already starts with the string "@start". This patch allows the execution of existing UML diagrams without @startuml/@enduml as well as non-UML diagrams that contain any @start-/@end- clause. Regards Henrik Koschitzki 0001-ob-plantuml-Allow-different-start-end-clauses.patch Description: Binary data
Re: [O] [PATCH] ob-plantuml.el support for non-UML diagrams
Thanks for this. I've not tested but I appreciate the head's up on the new features in plantuml! -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-399-g4e6222
Re: [O] Agenda: Display projects and 3 todo subtasks
Wow, cool to hear from the one & only Sacha!
Also, I found this GTD blog which appears to have something similar, under
the "Filtering Projects and Actions" section:
https://emacs.cafe/emacs/orgmode/gtd/2017/06/30/orgmode-gtd.html
However, this mechanism seems to report only the first TODO action
which is tagged with "@office" and (I presume) assumes that any headline
tagged @office is a "project".
Also, after reviewing Bernt Hansen's org-mode setup, it appears that
he uses NEXT keyword to distinguish between tasks that need to be done
(TODO) and tasks that can be accomplished NEXT. This may obviate
the need to show the first X items of any given project.
So many options . . . . . .
Thanks,
--Nate
>
>
>
>> On Wed., Jul. 31, 2019, 10:37 Nathan Neff, wrote:
>>
>>> I forgot to mention that I have PROJECT tag as not inheritable:
>>> (setq org-tags-exclude-from-inheritance (quote ("PROJECT")))
>>>
>>> And here's the agenda custom-command addition:
>>> ("2" "List projects with tasks" my/org-agenda-projects-and-tasks
>>> "+PROJECT"
>>> ((org-agenda-max-entries 3))
>>>
>>>
>>>
>>> On Tue, Jul 30, 2019 at 9:32 PM Nathan Neff
>>> wrote:
>>>
Hello all,
I found this cool snippet at Sacha Chua's website: [1].
It creates an agenda view with headings marked with tag "project",
and for each of those headings, it displays up to 3 sub headings marked
TODO.
I like this idea of seeing my projects (plus a few TODO entries under
each project)
in the agenda is a cool idea, so I copy/pasted the snippet at [1].
I created an example org file:
* Project 1:PROJECT:
** todo task 1.1
** todo task 1.2
** todo task 1.3
** todo task 1.4
* Project 2:PROJECT:
** todo task 2.1
** todo task 2.2
** todo task 2.3
** todo task 2.4
And ran the custom agenda command on only that file.
The output which is produced lists each project correctly.
However the sub-tasks under each project are the *same 3 subtasks*
from Project 1
foo:Project 1
foo:todo task 1.1
foo:todo task 1.2
foo:todo task 1.3
foo:Project 2
foo:todo task 1.1
foo:todo task 1.2
foo:todo task 1.3
The snippet at [1] is a bit more complex than I thought would be
necessary for such
an agenda view. Does someone have any snippets or suggestions for how
to
accomplish the idea above? Is there something obvious that I'm missing
about
the setup of my test org file?
Thanks,
--Nate
[1]
https://github.com/sachac/.emacs.d/blob/gh-pages/Sacha.org#display-projects-with-associated-subtasks
The associated blog entry is:
https://sachachua.com/blog/2013/01/emacs-org-display-projects-with-a-few-subtasks-in-the-agenda-view/
Re: [O] CUSTOM_ID vs ID
Nicolas Goaziou writes: > David Masterson writes: > >> Can you talk a little bit about how IDs are generated so that they are >> absolutely unique? > > See `org-id-new'. By default, it uses "uuidgen" command. > >> IDs sound like something that would be useful for synchronizing >> information between two (or more) separate Org systems - the ID could be >> updated whenever a change occurs and then used to determine what needs >> synchronization. True? > > I think this is different. ID property is meant to never change once > created. If you update it, you lose the reference to the headline, which > defeats the intended purpose. Ah. Gotcha. -- David
