Puneeth Chaganti writes:
> Yes, that is correct. I have a few code blocks that work and don't
> work, in the ECM, if at all you want to look at them.
It should now be fixed. Thank you for reporting it.
Regards,
On Sat, Dec 6, 2014 at 5:01 AM, Nicolas Goaziou wrote:
> Hello,
>
> Puneeth Chaganti writes:
>
>> It looks the commit 8d8ad983823c63b13fd6b471ce9db8c2f95e3808 broke
>> generation of org sparse trees, when searching with properties that
>> are not all uppercase.
>
> Could you provide an ECM?
I've
Hello,
Puneeth Chaganti writes:
> It looks the commit 8d8ad983823c63b13fd6b471ce9db8c2f95e3808 broke
> generation of org sparse trees, when searching with properties that
> are not all uppercase.
Could you provide an ECM?
> The fix seems to be just removing the conversion of key to upcase in
>
Hi Nicolas,
It looks the commit 8d8ad983823c63b13fd6b471ce9db8c2f95e3808 broke
generation of org sparse trees, when searching with properties that
are not all uppercase. The fix seems to be just removing the
conversion of key to upcase in `org-entry-properties'. Since the
comparison with specia
Sebastien Vauban
writes:
> The above function is perfect for her task! No diff at all [1] when
> applied on all my files from org-agenda-files (~ 45).
I updated ORG-NEWS then. Thanks for the feedback.
Regards,
Hello Nicolas,
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>>> ** Sectionnement
>>>
>>> Exemple de section avec un titre court pour LaTeX :
>>>
>>> #+begin_src org
>>> ,* Ceci est un titre de section assez long
>>> :PROPERTIES:
>>> :ALT_TITLE: Ceci est un titre court
>>> :END:
>>> #+
Sebastien Vauban
writes:
>> ** Sectionnement
>>
>> Exemple de section avec un titre court pour LaTeX :
>>
>> #+begin_src org
>> ,* Ceci est un titre de section assez long
>> :PROPERTIES:
>> :ALT_TITLE: Ceci est un titre court
>> :END:
>> #+end_src
>>
>> Upon execution of the repair functi
Nicolas,
Sebastien Vauban wrote:
> Sebastien Vauban wrote:
>> After heavy testing (on all my Org files, I mean) of the function
>> `org-repair-property-drawers', it works perfectly except for the
>> following corner-case (when there are Org properties in "quote"
>> blocks).
>>
>> I did not retest
Hello Nicoalas,
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> I've done that but, now, it does not support anymore the structure I had
>> in all my Org files:
>>
>> ** TODO Show typical Org entry
>>SCHEDULED: <2014-11-08 Sat>
>>:LOGBOOK:
>>CLOCK: [2014-11-11 Tue 12:35]--[201
Hello Nicolas,
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> After heavy testing (on all my Org files, I mean) of the above function,
>> it works perfectly except for the following corner-case [...].
>
> Thanks for your feedback. Would the following updated function solve the
> problem?
Hello,
Sebastien Vauban
writes:
> After heavy testing (on all my Org files, I mean) of the above function,
> it works perfectly except for the following corner-case (when there are
> Org properties in "quote" blocks):
>
> * Reference
>
> Example of Custom ID:
>
> #+begin_verse
> ,* Some title
Hello,
Sebastien Vauban
writes:
> I've done that but, now, it does not support anymore the structure I had
> in all my Org files:
>
> ** TODO Show typical Org entry
>SCHEDULED: <2014-11-08 Sat>
>:LOGBOOK:
>CLOCK: [2014-11-11 Tue 12:35]--[2014-11-11 Tue 14:19] => 1:44
>:END:
>
Nicolas,
Sebastien Vauban wrote:
> After heavy testing (on all my Org files, I mean) of the function
> `org-repair-property-drawers', it works perfectly except for the
> following corner-case (when there are Org properties in "quote"
> blocks).
>
> PS- I did not retest (yet) the same thing in #+be
Hello Nicolas,
Nicolas Goaziou wrote:
> As discussed previously, I would like to modify property drawers
> syntax. [...]
>
> However, it will break some Org documents. In particular, TODO-states
> changes are usually logged before any drawer, including properties
> drawers. The following function
Hello Nicolas,
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
>> etc.). Though, it moves as well the "body" text -- while I'm not
>> using `org-indent-mode'.
>>
>> * New section
>>
>> ** The SCHED will be moved
>>SCHEDULE
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> Isn't that somehow duplicate with `org-indent-mode' (which I don't
>> enable either)?
>
> `org-indent-mode' sets `org-adapt-indentation' to nil _and_ indents
> virtually (no modification to the document) body as if
> `org-adapt-indentation' was
Sebastien Vauban
writes:
> Isn't that somehow duplicate with `org-indent-mode' (which I don't
> enable either)?
`org-indent-mode' sets `org-adapt-indentation' to nil _and_ indents
virtually (no modification to the document) body as if
`org-adapt-indentation' wasn't nil.
There's no duplication
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
>> etc.). Though, it moves as well the "body" text -- while I'm not using
>> `org-indent-mode'.
>>
>> * New section
>>
>> * The SCHED will be moved
>> SCHEDULED: <2011-08-18 Thu
Sebastien Vauban
writes:
> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
> etc.). Though, it moves as well the "body" text -- while I'm not using
> `org-indent-mode'.
>
> * New section
>
> * The SCHED will be moved
> SCHEDULED: <2011-08-18 Thu>
>
> ** This one won't be move
Hello Nicolas,
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> One question, now that this syntax is stabilized, can the following
>> long-standing bug be fixed: sometimes the SCHEDULED line (or
>> DEADLINE, or ...) is moved synchronously with the heading when
>> promoting/demoting, sometim
Hello,
Sebastien Vauban
writes:
> One question, now that this syntax is stabilized, can the following
> long-standing bug be fixed: sometimes the SCHEDULED line (or DEADLINE,
> or ...) is moved synchronously with the heading when promoting/demoting,
> sometimes not.
>
> I found in which cases
Nicolas Goaziou wrote:
> Nicolas Goaziou writes:
>
>>> As discussed previously, I would like to modify property drawers syntax.
>>> The change is simple: they must be located right after a headline and
>>> its planning line, if any.
>>
>> [...]
>>
>>> I pushed a new branch, "top-properties" in the
Christian Egli writes:
> AFAIK the org-mode taskjuggler exporter was previously able to handle
> this if given the following headline:
>
> * task
> :PROPERTIES:
> :Effort: 1w
> :depends: software
> :allocate: test dev2
> :note: "Hopefully most bugs will be found and fixed her
Nicolas Goaziou writes:
> Hello,
>
> Christian Egli writes:
>
>> I see that it is too late now, but let me still note that the
>> taskjuggler exporter is quite liberal in what attribute values it allows
>> for exporting. I've never used it and I haven't ever seen anyone using
>> it, but in theor
Hello,
Christian Egli writes:
> This usage is perfectly fine and will continue to work. There are some
> very obscure attributes that taskjuggler (and the exporter) support,
> such as note and journalentry. These can span multiple lines. They can
> be used to add notes or more structured "journa
John Hendy writes:
> I use this, or at least things like this. For example:
>
> * task
> :PROPERTIES:
> :start:2014-11-03-08:00
> :task_id: task_d
> :depends: task_a task_b task_c
> :duration: 30min
> :END:
>
> Not multi-line, but currently I can feed any property tha
Hello,
Christian Egli writes:
> I see that it is too late now, but let me still note that the
> taskjuggler exporter is quite liberal in what attribute values it allows
> for exporting. I've never used it and I haven't ever seen anyone using
> it, but in theory you could give a task a note or a
On Fri, Oct 31, 2014 at 8:10 AM, Christian Egli wrote:
> Nicolas Goaziou writes:
>
>> Nicolas Goaziou writes:
>>
>>> As discussed previously, I would like to modify property drawers syntax.
>>> The change is simple: they must be located right after a headline and
>>> its planning line, if any.
>
Nicolas Goaziou writes:
> Nicolas Goaziou writes:
>
>> As discussed previously, I would like to modify property drawers syntax.
>> The change is simple: they must be located right after a headline and
>> its planning line, if any.
>> Feedback welcome.
>
> If there is no more feedback or objecti
Nicolas Goaziou writes:
>> As discussed previously, I would like to modify property drawers syntax.
>> The change is simple: they must be located right after a headline and
>> its planning line, if any.
>
> [...]
>
>> I pushed a new branch, "top-properties" in the repository for code
>> review an
Nicolas Goaziou writes:
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.
[...]
> I pushed a new branch, "top-properties" in the repository for code
> review and testing
Nicolas Goaziou writes:
> As discussed previously, I would like to modify property drawers syntax.
I think the syntax change looks great (based on the proposal)!
Thanks a bunch!
—Rasmus
--
Dobbelt-A
Hello,
Michael Brand writes:
> My questions were misleading, I'm sorry. I should not have asked about
> "valid" and not have added a property drawer.
Actually valid/invalid is a bit strong. There is no such thing as
a syntax error in Org. However, Org may differ from your expectations in
some c
Hi Nicolas
My questions were misleading, I'm sorry. I should not have asked about
"valid" and not have added a property drawer. Rather I wanted to know
when regarding only the agenda whether I can still postpone to make
these examples valid:
* Yearly meeting
<2013-08-11 Sun>
<2014
Nicolas Goaziou writes:
> Hello,
>
> Rainer M Krug writes:
>
>
>>> Moreover, node properties' keys can only contain non-whitespace
>>> characters and cannot end with a plus sign (which is used for
>>> accumulation).
>>
>> This is problematic for me, as I am using it extensively in the case
>> o
Nicolas Goaziou writes:
> Hello,
>
> Eric Abrahamsen writes:
>
>> Is there any chance this has messed up file-local #+TODO: keyword
>> definitions?
>
> The changes mess with todo keywords, tags, properties, initialization
> (local keywords), clock and logging. However, the modifications are
> in
Hello,
Rainer M Krug writes:
>> Moreover, node properties' keys can only contain non-whitespace
>> characters and cannot end with a plus sign (which is used for
>> accumulation).
>
> This is problematic for me, as I am using it extensively in the case
> of :header-args.
>
> I set file wide hea
Hello,
Eric Abrahamsen writes:
> Is there any chance this has messed up file-local #+TODO: keyword
> definitions?
The changes mess with todo keywords, tags, properties, initialization
(local keywords), clock and logging. However, the modifications are
internal and no change in behaviour is expe
Nicolas Goaziou writes:
> Hello,
Hi
I am not using org that much for schedulig, todo items, and other
similar topics, but mainly for literate programming, so I will comment
From that perspective.
>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simpl
Nicolas Goaziou writes:
> Hello,
>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any. Therefore the following cases are valid
Is there any chance this has messed up file-
Hello,
Michael Brand writes:
> What about legacy multi line plain timestamp and planning info:
>
> * Yearly meeting
> <2013-09-22 Sun>
> <2014-10-19 Sun>
> SCHEDULED: <2015-01-01 Thu> Add next plain timestamp.
> :PROPERTIES:
> :KEY: value
> :END:
Thi
Hello,
Eric Abrahamsen writes:
> Sounds like fun! Here's maybe a bug. In this test case:
>
> * Here's something
> ** Second level
>:PROPERTIES:
>:ID: 06b778b5-72a5-45b5-aea6-2d0fef0fd24b
>:END:
Good catch. Fixed, thank you.
Regards,
--
Nicolas Goaziou
Hi Nicolas
On Tue, Oct 14, 2014 at 4:42 PM, Nicolas Goaziou wrote:
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any. Therefore the following cases are valid
>
> * Headl
Nicolas Goaziou writes:
> Hello,
>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any. Therefore the following cases are valid
>
> * Headline
> :PROPERTIES:
> :KE
Hello,
Andreas Leha writes:
> My only 'concern' is that it looks awkward or at least unfamiliar when the
> property drawer is closed (which it is always in my documents).
>
> I guess than it would change from
>
> *** Call XXX
> :PROPERTIES:...
> <2014-10-16 Thu 13:00-14:00>
>
> t
Hi Nicolas,
My only 'concern' is that it looks awkward or at least unfamiliar when the
property drawer is closed (which it is always in my documents).
I guess than it would change from
*** Call XXX
:PROPERTIES:...
<2014-10-16 Thu 13:00-14:00>
to
*** Call XXX
<2014-10-16
Hello,
As discussed previously, I would like to modify property drawers syntax.
The change is simple: they must be located right after a headline and
its planning line, if any. Therefore the following cases are valid
* Headline
:PROPERTIES:
:KEY: value
:END:
* Headline
SCHED
47 matches
Mail list logo
