Re: [O] outorg issue

[Andreas Leha]

Hi Kaushal,

Kaushal  writes:
> I had submitted a pull request to solve this issue on that author's outshine 
> package page a couple of months back but as Andreas noted, the author hasn't 
> been able to maintain this stuff
> due to personal reasons.
>
> You can fix this issue by manually making changes in your copy of outshine as 
> per this PR: https://github.com/tj64/outshine/pull/46/files
>
> I use outshine daily and I needed to fix only outshine.el. Probably outorg.el 
> needs a similar fix?
>

Thanks for your patch!  In my first quick tests, this seems to work
nicely!  Nothing seems to be needed for outorg.

Regards,
Andreas

Re: [O] outorg issue

[Andreas Leha]

Hi Pip,

Pip Cet  writes:
> Hi,
> can you confirm the issue only appears when the first line of the
> buffer isn't an outline heading? I think it's easy enough to fix then,
> and if you like you might want to try the patch I've attached.
>
> It's bugged me for a while that `org-back-to-heading' et al throw
> errors when they're used before the first heading, but I haven't
> really come up with a better solution.

Thank you for your patch!  It seems as it breaks global visibility
cycling, though.

Regards,
Andreas

Re: [O] Stable releases

[Nicolas Goaziou]

Hello,

Bastien  writes:

> that I've been releasing it too quickly, after having been inactive
> way too long.

I disagree. Most bugs reported were introduced months ago. Waiting more
wouldn't have helped here.

> So all the advice you got is good, but think of 8.3 as a "come back"
> release, with problems that are largely due to me not paying attention
> enough to all those small details that make a good release.

...

> In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as
> I don't see why we needed to remove this option too.

`org-latex-hyperref-template' is more general that
`org-latex-with-hyperref'. Now, we have two variables which can
contradict each other (e.g., setting with-hyperref to t and
hyperref-template to the empty string). This is not very good, IMO.

At the bare minimum `org-latex-with-hyperref' should be an obsolete
alias for `org-latex-hyperref-template', and the latter should support
nil as a possible value.


Regards,

-- 
Nicolas Goaziou

Re: [O] beamer_env tag issue with empty headlines

[Nicolas Goaziou]

Hello,

Prateek Mehta  writes:

> I have a beamer block setup like below, so that it does not have a headline.
>
>
> **  :B_block:BMCOL:
>:PROPERTIES:
>:BEAMER_col: 0.64
>:BEAMER_env: block
>:END:
>
> - Some text here
>
> When I export it, the beamer environment tags show up in the pdf. This was
> not the case a couple of months ago, when the tags didn't appear in the
> pdf.
>
> If the the headline is not empty, the tags do not show in the pdf and it
> works as it used to.
>
> Has there been a recent change that introduced this?

This is an ambiguous headline. Indeed, it's impossible to tell if it is
an empty headline with tags or a headline without tags whose title is
":B_block:BMCOL:".

I think the last option is better as the first one prevents any
headline's title from being enclosed within colons. This is restrictive.

In any case, there are workarounds available for what you have to do.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Nicolas Goaziou]

Hello,

Luke Amdor  writes:

> Given a test.org with:
>
> * [#B] Test
> ** TODO one
>
>
> When I do the agenda to find TODO headlines with priority B I would expect
> it to find the "TODO one", however it doesn't. I'm very sure this regressed
> when upgrading to 8.3.1, as it worked fine in 8.3.0. Thanks!

There is a misunderstanding here. Special properties, like PRIORITY,
cannot be inherited.

However, in this case, "one" has a default priority, defined in
`org-default-priority'. Since it is usually B, it should appear
nonetheless in your sparse tree. 

It is fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] beamer_env tag issue with empty headlines

[Prateek Mehta]

On Wed, Aug 19, 2015 at 4:56 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Prateek Mehta  writes:
>
> > I have a beamer block setup like below, so that it does not have a
> headline.
> >
> >
> > **  :B_block:BMCOL:
> >:PROPERTIES:
> >:BEAMER_col: 0.64
> >:BEAMER_env: block
> >:END:
> >
> > - Some text here
> >
> > When I export it, the beamer environment tags show up in the pdf. This
> was
> > not the case a couple of months ago, when the tags didn't appear in the
> > pdf.
> >
> > If the the headline is not empty, the tags do not show in the pdf and it
> > works as it used to.
> >
> > Has there been a recent change that introduced this?
>
> This is an ambiguous headline. Indeed, it's impossible to tell if it is
> an empty headline with tags or a headline without tags whose title is
> ":B_block:BMCOL:".
>
> I think the last option is better as the first one prevents any
> headline's title from being enclosed within colons. This is restrictive.
>

That probably makes sense, though I still feel it is a little inconsistent.
One could argue that anything within colons is an org tag (regardless of
whether the title is empty), and isn't meant to be exported. It's probably
rare to start a headline with a colon anyway.

Plus, I guess you are still somewhat restricted if you want to export a
headline ** foo :bar:, where :bar: is not a tag. ;)

In any case, there are workarounds available for what you have to do.
>

Yes, either way works.

Thanks,

Prateek

>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] beamer_env tag issue with empty headlines

[Nicolas Goaziou]

Prateek Mehta  writes:

> That probably makes sense, though I still feel it is a little inconsistent.
> One could argue that anything within colons is an org tag (regardless of
> whether the title is empty), and isn't meant to be exported. It's probably
> rare to start a headline with a colon anyway.
>
> Plus, I guess you are still somewhat restricted if you want to export a
> headline ** foo :bar:, where :bar: is not a tag. ;)

Of course, there are limitations (and workarounds) in each case.

This is why I suggest to stay away from the "empty headlines + tags".
The only empty headline supported in Org is the one without anything.

Regards,

Re: [O] Stable releases

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> I disagree. Most bugs reported were introduced months ago. Waiting more
> wouldn't have helped here.

s/quickly/hastily

> `org-latex-hyperref-template' is more general that
> `org-latex-with-hyperref'. Now, we have two variables which can
> contradict each other (e.g., setting with-hyperref to t and
> hyperref-template to the empty string). This is not very good, IMO.
>
> At the bare minimum `org-latex-with-hyperref' should be an obsolete
> alias for `org-latex-hyperref-template', and the latter should support
> nil as a possible value.

If you want, please go ahead.

Thanks,

-- 
 Bastien

Re: [O] [DEV] Bump Emacs requirement to 24.4?

[Bastien]

Hi Suvayu,

Suvayu Ali  writes:

> I'm slightly confused as-to why this special org-8-master branch is
> needed.  As far as I understood from Achim's message (2nd paragraph):
>
>   ,
>
> that so far maint supports Emacs 23.

Yes, maint supports Emacs 23.

But maint is for minor release, and I want a branch where we can work
on major releases (8.4, 8.5, etc.) that support Emacs 23 too.

The clean way would have been to use drop-emacs23 branch for working
on code that does not support Emacs 23, and continue to use master for
working on major releases, but since nobody wants to revert the code
on master, there is no harm in using "org-8-master" as the new master.

> Although this might have been a
> coincidence, without a conscious decision.  It will continue supporting
> Emacs 23 until Org 9.  Post Org 9, if required, one can choose to start
> a new maint branch called maint23 for continued Emacs 23 support.
>
> Given the above, I do not understand the need for a separate
> org-8-master branch.  Is this a gap in communication, or am I missing
> something here?

I hope my answer clarifies things.

Thanks,

-- 
 Bastien

Re: [O] element-debug-mode breaks capture

[Nicolas Goaziou]

Hello,

Bastien  writes:

> I also had a lot of these recently.

I posted some tricks on the ML to help debug the problem. Also, a single
cache corruption can lead to many error reports (basically whenever
a command relying on `org-element-at-point' is used).

> I'm now turning org-element-use-cache off and I don't see real issue
> when not using it.
>
> Nicolas, what's the real benefit of using the cache?  Is it with
> large files?  With frequent updates of the structure?  What actions
> are the most impacted by not using the cache?

It makes `org-element-context'/`org-element-at-point' very fast in
almost every situation. This is of course the most noticeable when
editing large sections.

However, once remaining glitches in the cache are fixed, I expect to
make fontification use it. So, turning cache off in the long run doesn't
help moving forward, though it may be convenient in some unfortunate
situations.


Regards,

-- 
Nicolas Goaziou

Re: [O] [DEV] Bump Emacs requirement to 24.4?

[Bastien]

Hi David,

David Engster  writes:

> Bastien writes:
>> Emacs 23 and XEmacs support will be officially dropped as of Org 9.0.
>
> Support for XEmacs should be dropped right away; it would just state a
> fact, as Org didn't even compile with XEmacs for quite some time now
> (and nobody complained).

Yes.  By "officially", I mean : "all the code related to XEmacs
compatibility will be removed from Org codebase".  Of course we can
declare that XEmacs is not supported right now, but removing this code
takes some time.

>> I recognize having the manpower to watch after those branches might be
>> an issue, but we can overcome it by calling for careful testing before
>> major releases.
>
> At least the Buildbot can test the 8.3 branch with older Emacsen. I
> already changed that master is only checked with 24.3+.

That's great, thanks.

-- 
 Bastien

Re: [O] M-x org-publish in 8.3.1 results in error "org-check-agenda-file: Wrong type argument: stringp, nil"

[Sebastien Vauban]

Bastien  writes:
> Omid  writes:
>
>> user-error: No language for src block: (unnamed)
>
> This suggests to look for a #+begin_src block with no language name.

Use the function `my-src-block-check' [1] to find where it's missing.

Best regards,
  Seb

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00776.html

-- 
Sebastien Vauban

[O] Regression: org-translate-link doesn't work correctly in Org 8.3

[Sergei Nosov]

Hi!

I'm the maintainer of the toc-org (https://github.com/snosov1/toc-org)
package. With 8.3 I have noticed a regression in how org-translate-link
function works.

In this package, toc-org, I use org-link-translation-function variable to
make C-c C-o (org-open-at-point) work with GitHub-style links. To do this,
I set the aforementioned org-link-translation-function variable to a
function that translates GitHub-style links back to Org-style.

It was working fine in Org 8.2, but it doesn't work in Org 8.3.

I believe the root cause is the following. Here's the code of the
org-translate-link function:

(defun org-translate-link (s)
  "Translate a link string if a translation function has been defined."
  (if (and org-link-translation-function
  (fboundp org-link-translation-function)
  (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s))
  (progn
(setq s (funcall org-link-translation-function
(match-string 1 s) (match-string 2 s)))
(concat (car s) ":" (cdr s)))
s))

Consider that we're trying to follow the link [[#about][About]]

In Org 8.2 org-translate-link function is called with s equal to
"thisfile:#about". So, (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)
returns true and the call to the function stored in
org-link-translation-function follows.

In Org 8.3 org-translate-link function is called with s equal to simply
"#about" (no "thisfile:" in the beginning). Thus, the string-match call
NEVER succeeds (because there's no colon).

Please, let me know, what would be the solution to this issue.

--
Best regards,
   Sergei Nosov

Re: [O] org-block-background in 8.3.1?

[Sebastien Vauban]

Hi Bastien,

Bastien writes:
> Sebastien Vauban writes:
>
>> Really, it has been removed because of a problem when ps-print'ing an
>> Org buffer -- though the bug was to find in `ps-def.el' and not in
>> Org, as reported by Stefan Monnier [1].  It should have been fixed
>> there instead.
>
> Yes, indeed.
>
>>> I'm not aware of anything that has been introduced in its place.
>>
>> I'm planning to reintroduce it as an optional feature.  At least in
>> my personal Git repository, if that's not accepted in Org core.
>
> If you can find an implementation that does not rely on overlays, I'm
> fine with it - overlays have inherent scalability issues, and I'm
> reluctant using them for something as pervasive as code blocks
> background.

I don't know how to add the background color without overlays.

That's why the very first step would (have) be(en) to put it as an
optional feature, that could been disabled by those who feel that it
introduces a performance delay -- what hasn't been shown so far IIRC.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Regression: org-translate-link doesn't work correctly in Org 8.3

[Bastien]

Hi Sergei,

wild guess: what if you simply make the ":" optional like this:

(string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)

(string-match "\\([a-zA-Z0-9]+\\):?\\(.*\\)" s)
 ^^^

?

-- 
 Bastien

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Bastien]

Nicolas Goaziou  writes:

> There is a misunderstanding here. Special properties, like PRIORITY,
> cannot be inherited.

The PRIORITY property *was* inherited.  At least in 8.2.10.

It is reasonable to expect the PRIORITY property to be inherited and
the new behavior (falling back on the default priority) is confusing.

I see a lot of work on the way Org get properties since one year.

How hard would it be to restore the previous behavior?

Are there any other changes that we need to know from a user point of
view?

Thanks,

-- 
 Bastien

Re: [O] element-debug-mode breaks capture

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> It makes `org-element-context'/`org-element-at-point' very fast in
> almost every situation. This is of course the most noticeable when
> editing large sections.

How can I test it manually to really _notice_ the difference between
using the cache and not using it?

(I'm not discussing it's general utility, I'm trying to understand in
what circumstances the cache is a noticeable optimization.)

> However, once remaining glitches in the cache are fixed, I expect to
> make fontification use it. So, turning cache off in the long run doesn't
> help moving forward, though it may be convenient in some unfortunate
> situations.

The cache seems still a bit brittle, so yes, let's fix it and see.

-- 
 Bastien

Re: [O] org-block-background in 8.3.1?

[Bastien]

Hi Sébastien,

Sebastien Vauban 
writes:

> That's why the very first step would (have) be(en) to put it as an
> optional feature, that could been disabled by those who feel that it
> introduces a performance delay -- what hasn't been shown so far IIRC.

Can you provide a patch and a test?

The patch would restore the block background, turned off by default.

Then the test would show that the modified fontification functions are
not significantly slowed down with a large number of blocks.  Say e.g.
100 blocks in 100 subtrees.

Thanks!

-- 
 Bastien

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> There is a misunderstanding here. Special properties, like PRIORITY,
>> cannot be inherited.
>
> The PRIORITY property *was* inherited.  At least in 8.2.10.

AFAIK, PRIORITY never was intended to be inherited. Inheritance applies
to node properties, i.e. property drawers, whereas special properties,
like PRIORITY are, by definition, not set through property drawers.

There is also a technical issue: Org defines a default priority, so
PRIORITY is never empty. Again, inheritance kicks in when a property is
undefined at some level. This never happens in this case.

Regards,

Re: [O] [DEV] Bump Emacs requirement to 24.4?

[Suvayu Ali]

Hi Bastien,

On Wed, Aug 19, 2015 at 11:40:09AM +0200, Bastien wrote:
> Suvayu Ali  writes:
> 
> > I'm slightly confused as-to why this special org-8-master branch is
> > needed.  As far as I understood from Achim's message (2nd paragraph):
> >
> >   ,
> >
> > that so far maint supports Emacs 23.
> 
> Yes, maint supports Emacs 23.
> 
> But maint is for minor release, and I want a branch where we can work
> on major releases (8.4, 8.5, etc.) that support Emacs 23 too.

I think this was the bit of information I was missing.

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] element-debug-mode breaks capture

[Nicolas Goaziou]

Bastien  writes:

> How can I test it manually to really _notice_ the difference between
> using the cache and not using it?

Create a buffer with a large section (or no section at all).

Edit the end of the section (e.g., fill paragraphs) ...

Regards,

Re: [O] Regression: org-translate-link doesn't work correctly in Org 8.3

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Hi Sergei,
>
> wild guess: what if you simply make the ":" optional like this:
>
> (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)
>
> (string-match "\\([a-zA-Z0-9]+\\):?\\(.*\\)" s)
>  ^^^
>
> ?

I think `org-translate-link' should be updated to provide correct type,
including internal ones, to `org-link-translation-function'. E.g.,

  http://orgmode.org => "http"
  #something => "custom-id"
  (ref:line) => "coderef"
  whatever   => "fuzzy"

At least, this would be consistent with the parser.

Regards,

-- 
Nicolas Goaziou

Re: [O] Regression: org-translate-link doesn't work correctly in Org 8.3

[Sergei Nosov]

> wild guess: what if you simply make the ":" optional like this:

I believe, the preceding text should be made optional as well (i.e. +
should be *, like (string-match "\\([a-zA-Z0-9]*\\):?\\(.*\\)" s))

But anyway, it doesn't seem to work, because for some reason (I just
noticed this) - the org-translate-link function doesn't seem to be called
at all, when C-c C-o is executed. It is called only
in org-element-link-parser.

Also, org-translate-link tries to return the link in the ":"
format (exactly the way it expects the input parameter to be). So, simply
modifying the regexp shouldn't work because of this as well.

So, I suppose, something like what Nicolas suggests should be done about it
(i.e. providing the type and the link in the "new format").

Also, org-translate-link should probably be called somewhere
in org-open-at-point again.



--
Best regards,
   Sergei Nosov

On Wed, Aug 19, 2015 at 1:39 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Bastien  writes:
>
> > Hi Sergei,
> >
> > wild guess: what if you simply make the ":" optional like this:
> >
> > (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)
> >
> > (string-match "\\([a-zA-Z0-9]+\\):?\\(.*\\)" s)
> >  ^^^
> >
> > ?
>
> I think `org-translate-link' should be updated to provide correct type,
> including internal ones, to `org-link-translation-function'. E.g.,
>
>   http://orgmode.org => "http"
>   #something => "custom-id"
>   (ref:line) => "coderef"
>   whatever   => "fuzzy"
>
> At least, this would be consistent with the parser.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Regression: org-translate-link doesn't work correctly in Org 8.3

[Bastien]

Nicolas Goaziou  writes:

> I think `org-translate-link' should be updated to provide correct type,
> including internal ones, to `org-link-translation-function'. E.g.,
>
>   http://orgmode.org => "http"
>   #something => "custom-id"
>   (ref:line) => "coderef"
>   whatever   => "fuzzy"
>
> At least, this would be consistent with the parser.

Agreed.

-- 
 Bastien

Re: [O] element-debug-mode breaks capture

[Bastien]

Nicolas Goaziou  writes:

> Bastien  writes:
>
>> How can I test it manually to really _notice_ the difference between
>> using the cache and not using it?
>
> Create a buffer with a large section (or no section at all).
>
> Edit the end of the section (e.g., fill paragraphs) ...

With a 13MO file, with 500 headlines, each containing about 100
paragraphs, editing the end of the last paragraph (unfill/fill)
is just very fast.

My machine is this: http://minifree.org/product/libreboot-x200/

So nothing really crazy...

Maybe I don't do the right test.

-- 
 Bastien

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Nicolas Goaziou]

Correcting myself,

> AFAIK, PRIORITY never was intended to be inherited. Inheritance applies
> to node properties, i.e. property drawers, whereas special properties,
> like PRIORITY are, by definition, not set through property drawers.

This is incorrect. What I mean is inheritance is not automatic for
special properties, unlike to regular node properties.

In any case, this doesn't depend on `org-use-property-inheritance'. Few
of the special properties are inherited, e.g., BLOCKED, and /always/
are, most are never inherited, e.g. ITEM.

> There is also a technical issue: Org defines a default priority, so
> PRIORITY is never empty. Again, inheritance kicks in when a property is
> undefined at some level. This never happens in this case.

We need to redefine `org-default-prority' to solve this, e.g., the
variable only applies to top-level items.

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Bastien]

Nicolas Goaziou  writes:

> Correcting myself,
>
>> AFAIK, PRIORITY never was intended to be inherited. Inheritance applies
>> to node properties, i.e. property drawers, whereas special properties,
>> like PRIORITY are, by definition, not set through property drawers.
>
> This is incorrect. What I mean is inheritance is not automatic for
> special properties, unlike to regular node properties.
>
> In any case, this doesn't depend on `org-use-property-inheritance'. Few
> of the special properties are inherited, e.g., BLOCKED, and /always/
> are, most are never inherited, e.g. ITEM.
>
>> There is also a technical issue: Org defines a default priority, so
>> PRIORITY is never empty. Again, inheritance kicks in when a property is
>> undefined at some level. This never happens in this case.
>
> We need to redefine `org-default-prority' to solve this, e.g., the
> variable only applies to top-level items.

After a few tests, I'm confused and I don't understand all the changes
in this area (and they are not documented in ORG-NEWS.)

Let's forget about what "special" means and how properties are
displayed and set in the buffer.

We have four categories of properties:

1. those which are *never* inherited (like ITEM)
2. those which are *always* inherited (like CATEGORY)
3. those which inheritance relies on `org-use-property-inheritance'
4. those which are not part of the previous types

(4) sounds a bit borgesian, but it's important: my understanding is
that this fourth category *should* be empty.  Apparently it is not
empty, since the PRIORITY property inheritance is not controlled by
`org-use-property-inheritance'.  Are there other exceptions?

There is a default priority the same way there is a default category:
having a default value for the PRIORITY property should not prevent
inheriting it from a superior headline IMO, and the previous behavior
was right.

I know dwelling on this is boring but we need to do so, at least to
clarify changes in etc/ORG-NEWS.

Thanks,

-- 
 Bastien

[O] nested macro expansion?

[Eric Abrahamsen]

What I'm trying to do is have a macro that takes the computed TIMESTAMP
property for an entry, and then runs it through a custom function that
breaks out the start/end times, and produces a nicely formatted string
from that.

I don't see how to write a macro that feeds the value of a computed
special property to a function.

Right now my testing version looks like this:

#+MACRO: bubba (eval (format-time-string "%Y" "$1"))

and I'm calling it like this:

{{{bubba({{{property(TIMESTAMP)}}})}}}

That doesn't expand the interior "{{{property(TIMESTAMP)}}}" clause.
What `format-time-string' ends up seeing is "{{{property(TIMESTAMP",
without the final braces etc.

Is there any way to get that value expanded first, and then passed to
`format-time-string' (or, eventually, my custom function)?

Thanks!

Eric

Re: [O] nested macro expansion?

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> What I'm trying to do is have a macro that takes the computed TIMESTAMP
> property for an entry, and then runs it through a custom function that
> breaks out the start/end times, and produces a nicely formatted string
> from that.
>
> I don't see how to write a macro that feeds the value of a computed
> special property to a function.
>
> Right now my testing version looks like this:
>
> #+MACRO: bubba (eval (format-time-string "%Y" "$1"))
>
> and I'm calling it like this:
>
> {{{bubba({{{property(TIMESTAMP)}}})}}}
>
> That doesn't expand the interior "{{{property(TIMESTAMP)}}}" clause.
> What `format-time-string' ends up seeing is "{{{property(TIMESTAMP",
> without the final braces etc.
>
> Is there any way to get that value expanded first, and then passed to
> `format-time-string' (or, eventually, my custom function)?

After googling for a while, I also thought this might work:

#+MACRO: bubba (eval (format-time-string "%Y" property{{{TIMESTAMP}}}))

{{{bubba}}}

But the nested definition isn't expanded, either with or without quotes.

E

Re: [O] element-debug-mode breaks capture

[Eric S Fraga]

On Wednesday, 19 Aug 2015 at 12:55, Bastien wrote:

[...]

> With a 13MO file, with 500 headlines, each containing about 100
> paragraphs, editing the end of the last paragraph (unfill/fill)
> is just very fast.

What about editing at the start of the file?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-117-gc98729

Re: [O] Bug: Priorities not inheriting [8.3.1 (8.3.1-56-g17a225-elpa @ /Users/luke/.emacs.d/elpa/org-20150817/)]

[Nicolas Goaziou]

Bastien  writes:

> After a few tests, I'm confused and I don't understand all the changes
> in this area (and they are not documented in ORG-NEWS.)

I'd rather clarify something here.

Most changes introduced come from bug reports, i.e., they are not a will
to change how things work in Org. Fixed bugs are not documented in
ORG-NEWS.

Unfortunately, once the fix is applied, it is hard to know if it
actually modifies some behaviour because the documentation doesn't, and
cannot, explain all the details and there are no tests to get a clue
about the original intent. For core functions, the bug fix usually
includes specifications tests to avoid encountering the same issue
again.

This is exactly what happened with "COMMENT" headlines. This is almost
the same for property API (the current change): I wanted to improve it
but had to switch from an ad-hoc model to a structured one.

To sum it up, this is not carelessness in filling up ORG-NEWS (though
omissions do happens occasionally) but fuzziness in how features are
described.

> Let's forget about what "special" means and how properties are
> displayed and set in the buffer.

On the contrary, it is important to understand that a few properties do
not follow the regular model and need to be handled specifically.

However, me way extend what "special" means. At the moment it only
includes properties not set through a property drawer. We could include
properties with a hard-coded inheritance patters (i.e., CATEGORY and
PRIORITY).

> We have four categories of properties:
>
> 1. those which are *never* inherited (like ITEM)
> 2. those which are *always* inherited (like CATEGORY)
> 3. those which inheritance relies on `org-use-property-inheritance'
> 4. those which are not part of the previous types
>
> (4) sounds a bit borgesian, but it's important: my understanding is
> that this fourth category *should* be empty.

I agree.

> Apparently it is not empty, since the PRIORITY property inheritance is
> not controlled by `org-use-property-inheritance'. Are there other
> exceptions?

I cannot think of any.

> There is a default priority the same way there is a default category:
> having a default value for the PRIORITY property should not prevent
> inheriting it from a superior headline IMO, and the previous behavior
> was right.

You are right, but I'm pretty sure the previous implementation of the
property API didn't implement it this way, i.e., PRIORITY was not
implemented like CATEGORY, at all. My gut feeling is that PRIORITY
inheritance happened by side-effect.

In any case, I see no objection to treat PRIORITY much like CATEGORY.


Regards,

Re: [O] element-debug-mode breaks capture

[Nicolas Goaziou]

Bastien  writes:

> Eric S Fraga  writes:
>
>> On Wednesday, 19 Aug 2015 at 12:55, Bastien wrote:
>>
>> [...]
>>
>>> With a 13MO file, with 500 headlines, each containing about 100
>>> paragraphs, editing the end of the last paragraph (unfill/fill)
>>> is just very fast.
>>
>> What about editing at the start of the file?
>
> Very fast.  I made a small movie, that'll help telling if I'm
> doing the wrong tests:
>
> http://bzg.fr/u/org-element-cache-test.ogv

You edit the first paragraph of a section, which is always fast.

Try 1000 paragraphs in a single entry and move to the end of line
anywhere in the last one.

Also, try (require 'benchmark) (benchmark 1 '(org-element-at-point))
*twice* with or without `org-element-use-cache' in that last paragraph.

Without cache, parsing doesn't scale. Some users reported already in
th past having issues with speed on large documents.


Regards,

Re: [O] element-debug-mode breaks capture

[Bastien]

Eric S Fraga  writes:

> On Wednesday, 19 Aug 2015 at 12:55, Bastien wrote:
>
> [...]
>
>> With a 13MO file, with 500 headlines, each containing about 100
>> paragraphs, editing the end of the last paragraph (unfill/fill)
>> is just very fast.
>
> What about editing at the start of the file?

Very fast.  I made a small movie, that'll help telling if I'm
doing the wrong tests:

http://bzg.fr/u/org-element-cache-test.ogv

-- 
 Bastien

Re: [O] Regression: org-translate-link doesn't work correctly in Org 8.3

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> I think `org-translate-link' should be updated to provide correct type,
>> including internal ones, to `org-link-translation-function'. E.g.,
>>
>>   http://orgmode.org => "http"
>>   #something => "custom-id"
>>   (ref:line) => "coderef"
>>   whatever   => "fuzzy"
>>
>> At least, this would be consistent with the parser.
>
> Agreed.

Done. There is one foreseeable incompatible change however. When link
type is unknown to Org, it is reported as fuzzy, e.g.:

  [[foobar:something]]

is seen as ("fuzzy" "foobar:something") by
`org-link-translation-function', not ("foobar" "something"), unless
"foobar" belong to `org-link-types'.

In practice I don't think it matters because
`org-link-translation-function' isn't meant to create new link types but
handle conflicting link types. In any case, in the example above, one
can always use

  (when (and (string= type "fuzzy")
 (string-match "\\(.*?\\):\\(.*\\)" path))
   (cons (match-string 1) (match-string 2)))

in `org-link-translation-function'.

Regards,

Re: [O] [DEV] Bump Emacs requirement to 24.4?

[Achim Gratz]

Bastien writes:
> Here is my decision on this issue:
>
> - the Org 8.x series will be Emacs 23+ compatible.

…and we should maybe do an 8.4 final release before it is frozen, but
not drag it along furhter like you suggested in emacs-devel.

> - the Org 9.x series will be Emacs 24.3+ compatible.
>
> Emacs 23 and XEmacs support will be officially dropped as of Org 9.0.

Org on XEmacs is practically dead already, so why do we need to pretend
it is still supported?  You can check when I did the last compatibility
fixes for it, after that nobody (not even any XEmacs user) has ever made
any mention of it working or not working even though there were numerous
changes that are unlikely to work or work correctly on XEmacs.

> The maint branch continues to be used to work on minor releases, as it
> has always been used.
>
> Instead of reverting changes from the master branch (you clearly don't
> want to do that, and I don't either), I suggest we create a new branch
> called "org-8-master" for Org 8.4+, and continue to use master for Org
> 9.x+ (i.e. "major major releases").

I'm not sure how you want to implement this in practise, but it looks
too complicated and error-prone.  My suggestion would be to keep the
maint branch compatible with Emacs23 until 8.4 and then (maybe) split
off a maint-23 branch for any bugfixes.  If a (new) maintainer springs
into action to backport features into this branch, then fine, but
otherwise it stops being connected to the development branches.

> This is temporary: once the 9.0 version is released, we can simply use
> maint and master as before, and delete org-8-master.

You mustn't delete public branches.

> The reason for this is that we need to make room for new features in
> the 8.x series, so that these new features will be available to the
> Emacs 23 users.
>
> If we drop Emacs 23 support as of Org 8.4, we won't be able to add new
> features (e.g. new export backends) for Emacs 23.

I don't think we should.  Emacs23 does not get any new features, then why
should Org on Emacs23 do?

> I recognize having the manpower to watch after those branches might be
> an issue, but we can overcome it by calling for careful testing before
> major releases.

See the above proposal which minimizes that impact.  Call for a new
maintainer for maint-23 and see if someone volunteers.  Otherwise just
freeze that branch and backport only fixes for really bad issues.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Stable releases

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> At the bare minimum `org-latex-with-hyperref' should be an obsolete
>> alias for `org-latex-hyperref-template', and the latter should support
>> nil as a possible value.
>
> If you want, please go ahead.

Done.


Regards,

Re: [O] org-habit and Org 8.3

[Dave Marquardt]

"John Wiegley"  writes:
> I've upgrade today to Org 8.3.1, and I've noticed that any customization which
> used overlays (mainly, org-habit) now displays no overlays in the Agenda
> buffer.
>
> Is this something others have already seen and found a fix for?

Check to see that the properties drawer that specifies that a task is a
habit is just after SCHEDULED or a similar keyword. This was a change
made in 8.3 or 8.3.1. See http://orgmode.org/Changes.html for a function
to repair your properties drawers.

-Dave

Re: [O] outorg issue

[Pip Cet]

On 8/19/15, Andreas Leha  wrote:
> Thank you for your patch!  It seems as it breaks global visibility
> cycling, though.

Sorry about that, I really messed up there. Kaushal's patch should
work better, as long as there is at least one valid heading in the
file (if I try running it on an entirely empty org file, I can still
produce the error message with M-x outline-hide-sublevels).

I'd also like to second Bastien's suggestion, it would be excellent to
see this useful extension maintained again.

Re: [O] org-habit and Org 8.3

[Matt Lundin]

"John Wiegley"  writes:

> I've upgrade today to Org 8.3.1, and I've noticed that any customization which
> used overlays (mainly, org-habit) now displays no overlays in the Agenda
> buffer.

I cannot replicate this. Habits are displaying correctly on my machine.

Calling describe-text-properties on the habit graph shows the following:

--8<---cut here---start->8---
Text content at position 1480:

There are text properties here:
  face org-habit-overdue-face
  tags ("inbox" "per" "email")
--8<---cut here---end--->8---

org-version:
8.3.1

Matt

Re: [O] Valid use cases for lists?

[Kyle Meyer]

Chris Patti  writes:

> Can anyone give me an example of when it's a good idea to use lists
> rather than headlines?

I think there are quite a few, but here's one example.  I keep a heading
with a list of links to potentially interesting articles that I don't
have time to process at the moment when I encounter them.  I capture new
links (with no description) as items under this heading.  I don't want
to use a separate heading for each link because I don't want to think
about a name to give the heading.  I just want a list of links where I
can check off items when I get around to visiting them.

> They feel rather like a violation of the principle of least surprise
> to me, because when you use them, and then try to use pretty much any
> other Org feature on them (marking them as a TODO item, tagging, etc.)
> it doesn't work because lists aren't meant to be used that way.

That is pretty much how I decide.  If I think I need heading-specific
features, I use headings.

--
Kyle

[O] Bug: Org-indent does not align headings with text when using non-monospaced fonts [8.3.1 (8.3.1-16-gf6aa53-elpa @ /Users/cube/.emacs.d/elpa/org-20150810/)]

[Jakub Szypulka]

Reproduction of bug: Open an org-file in org-mode with auto-indent turned on 
while using a non-monospaced font.
Expected result: The headings align with the text contents.
Actual result: The headings do not align with the text contents.

This has been originally filed two years ago:
http://article.gmane.org/gmane.emacs.orgmode/64775/match=indent+misalign

There is a proposed fix: replace the blankspace used to indent a line, defined 
in org-indent.el, with a star ('*').
Source: 
http://emacs.stackexchange.com/questions/7429/how-to-customize-org-mode-indentation
This link also includes screenshots that illustrate the problem.

Thanks in advance for fixing!

Emacs  : GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21) 
of 2015-04-10 on builder10-9.porkrind.org
Package: Org-mode version 8.3.1 (8.3.1-16-gf6aa53-elpa @ 
/Users/cube/.emacs.d/elpa/org-20150810/)

Re: [O] Stable releases

[Rasmus]

Russell Adams  writes:

> On Tue, Aug 18, 2015 at 07:36:00PM +0200, Bastien wrote:
>> Hi Scott,
>>
>
>> the main reason why 8.3 was not as "stable" as it should have been is
>> that I've been releasing it too quickly, after having been inactive
>> way too long.
>>
>> It's kind of a miracle that Org development could continue without an
>> active "official" maintainer for so long, and we owe a lot to Nicolas
>> and other contributors for this.
>
> Bastien,
>
> As a Org user since 2006 I've watched and appreciated how much time
> and effort yourself and Carsten have put into maintainership. This
> significant commitment brings about the following question:
>
> Is Org large enough that it would benefit from being broken into more
> pieces?
>
> For instance a stable core that includes only the major mode itself,
> which you continue to maintain. This defines the file syntax and
> includes core features which require little to no external programs or
> libraries.
>
> Then could you break out the exporters, babel, and many of the other
> sub-features into "plugins" that could be maintained separately by
> others, and they depend back to the core version?
>
> My impression has been that the core Org functionality has been stable
> for quite a while, and the org ecosystem grows by leaps and bounds as
> new users expand the incredibly flexible syntax to work for their use
> case.

It's nice to have "batteries included".  This is also the strength of
programming languages such as python, emacs-lisp, and to a lesser extend
R.

One data point: I can absolutely not be bothered using anything that is
not at least in contrib.

Rasmus

-- 
A clever person solves a problem. A wise person avoids it

[O] Babel for eshell?

[Lawrence Bottorff]

Is there any way to do literate Babel-style things with eshell? Only shell
(sh) seems to be listed among the languages. As I understand, eshell is
just a wrapper around actual elisp expressions. For example,

find-file foobar.txt

is actually

(find-file "foobar.txt")

I'd like to do shell-like stuff and capture everything literate-style in
code and result blocks. If no Babel for eshell, is there a way to translate
eshell into its raw elisp? Then I could do Babel on the elisp.

LB

Re: [O] [DEV] Bump Emacs requirement to 24.4?

[Rasmus]

Bastien  writes:

> Hi Nicolas and all,
>
> As Achim said, we may have been miscommunicating, especially on
> whether it was about requiring Emacs 23+ or 24.3 vs 24.4.
>
> Here is my decision on this issue:
>
> - the Org 8.x series will be Emacs 23+ compatible.
>
> - the Org 9.x series will be Emacs 24.3+ compatible.
>
> [...]
> 
> Let me know what you think,

It would seem to me, that the natural conclusion from this is simply to
EOL Org 8+ and move on to v9, no?

Rasmus

-- 
Send from my Emacs

Re: [O] Per-backend export options?

[Jay Dixit]

I do something similar to change export options between HTML and LaTeX:

(defun my-org-export-change-options (plist backend)
  (cond
   ((equal backend 'html)
(plist-put plist :with-toc nil)
(plist-put plist :section-numbers nil))
   ((equal backend 'latex)
(plist-put plist :with-toc t)
(plist-put plist :section-numbers t)))
  plist)
(add-to-list 'org-export-filter-options-functions
'my-org-export-change-options)



---
Jay Dixit
jaydixit.com
(646) 355-8001
Jay Dixit


On Mon, Jul 6, 2015 at 10:16 AM,  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, Jul 06, 2015 at 11:32:21AM +0200, Rasmus wrote:
> [...]
> > I'd use a macro for this.  E.g.
>
> Works like a charm now :-)
>
> - -- t
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlWaja4ACgkQBcgs9XrR2kaEzgCfbM0McF+Yi3sR1prWI8ix1cpu
> pTIAn0PQumh5sUJmE4UBQm9OFd8Nc/CV
> =z5tl
> -END PGP SIGNATURE-
>
>
>