Re: [O] More clocktable breakage

2017-05-15 Thread Achim Gratz
Nicolas Goaziou writes:
> Is your issue solved?

I can confirm the issue is solved.  Thanks again.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] More clocktable breakage

2017-05-14 Thread Achim Gratz
Nicolas Goaziou writes:
> I fixed the issue by extending `org-at-timestamp-p' optional argument
> while preserving backward-compatibility.

Thanks.  That seems like a much better soultion than what we've had
before and some of what we've discussed before getting there.

> Is your issue solved?

I'll have final confirmation sometime next week, but I assume yes.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra




Re: [O] More clocktable breakage

2017-05-14 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> Yes, put the cursor on the date or time of one of the timestamps and
> press S-Up or S-Down.  It should increase or decrease the corresponding
> element of the timestamp, but instead you'll get an error message:
>
> org-clocktable-shift: Line needs a :block definition before this command works
>
> which appears because the timestamp wasn't recognized and the
> fallthrough of org-shift* then tries to apply another function that
> deals with the :block argument (which isn't present here and shouldn't
> be).

OK, reproduced.

I fixed the issue by extending `org-at-timestamp-p' optional argument
while preserving backward-compatibility.

The new docstring is:

Non-nil if point is inside a timestamp.

By default, the function only consider syntactically valid active
timestamps.  However, the caller may have a broader definition
for timestamps.  As a consequence, optional argument EXTENDED can
be set to the following values

  `inactive'

Include also syntactically valid inactive timestamps.

  `agenda'

Include timestamps allowed in Agenda, i.e., those in
properties drawers, planning lines and clock lines.

  `lax'

Ignore context.  The function matches any part of the
document looking like a timestamp.  This includes comments,
example blocks...

For backward-compatibility with Org 9.0, every other non-nil
value is equivalent to `inactive'.

When at a timestamp, return the position of the point as a symbol
among `bracket', `after', `year', `month', `hour', `minute',
`day' or a number of character from the last know part of the
time stamp.

When matching, the match groups are the following:
  group 1: year
  group 2: month
  group 3: day number
  group 4: day name
  group 5: hours, if any
  group 6: minutes, if any

I also updated the callers throughout the code base.

>> I start to think that there is no bug in clock tables (but certainly in
>> the cache mechanism, probably related to some `before-change-functions'
>> and `after-change-functions' misuse there).
>
> I'm not using any of those unless they already come with Emacs or Org.

What I meant is the use of `before-change-functions' and
`after-change-functions' is wrong in the caching mechanism, not in your
configuration.

Anyway, it doesn't matter for the problem at hand.

Is your issue solved?

Regards,

-- 
Nicolas Goaziou



Re: [O] More clocktable breakage

2017-05-07 Thread Achim Gratz
Nicolas Goaziou writes:
> OK. I inserted it in a fresh Org buffer. Is there any command to call on
> it now?

Yes, put the cursor on the date or time of one of the timestamps and
press S-Up or S-Down.  It should increase or decrease the corresponding
element of the timestamp, but instead you'll get an error message:

org-clocktable-shift: Line needs a :block definition before this command works

which appears because the timestamp wasn't recognized and the
fallthrough of org-shift* then tries to apply another function that
deals with the :block argument (which isn't present here and shouldn't
be).

>> Sometimes org-element-context recognizes the clocktable as a paragraph
>> instead of dynamic-block
>
> FWIW, I get `dynamic-block'.

OK, then that should get you the same error.

>> (I've not yet figured out why and it isn't vary reproducible, but it
>> must have something to do with the cache since it goes away when
>> I reload the file)
>
> It is possible, indeed. You can also use M-x org-element-cache-reload to
> check this. However, cache is disabled by default, so the problem
> shouldn't appear in normal usage.

I have not enabled any cache that I know of.  All I can say is that
sometimes the clocktable doesn't get recognized as dynamic-block but a
paragraph instead.  That re-enables the recognition of the timestamp
incidentally (why exactly I don't really understand), which was why I
couldn't reproduce the error at home for some time.

> I start to think that there is no bug in clock tables (but certainly in
> the cache mechanism, probably related to some `before-change-functions'
> and `after-change-functions' misuse there).

I'm not using any of those unless they already come with Emacs or Org.


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] More clocktable breakage

2017-05-07 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> I've told you from the beginning that it was a file at work and that it
> would take some time to dig down to the problem since it did work at
> home when I tried to create said ECM.

I know, but I was hoping a few weeks would be enough, since the
resolution of the issue was stalled.

> After a few false starts (thinking that it was Windows vs. Linux and
> the local configurations on each side) I've finally converged to this
> (just insert a new clocktable, then replace the default parameters
> with tstart/tend):
>
>   #+BEGIN: clocktable :tstart "<2017-03-24 Fri 00:00>" :tend "<2017-04-23 Sat 
> 23:45>"
>   #+CAPTION: Clock summary at [2017-05-06 Sat 11:09]
>   | L | Headline | Time   |   |
>   |---+--++---|
>   |   | *Total time* | *0:00* |   |
>   #+END:

OK. I inserted it in a fresh Org buffer. Is there any command to call on
it now?

> Sometimes org-element-context recognizes the clocktable as a paragraph
> instead of dynamic-block

FWIW, I get `dynamic-block'.

> (I've not yet figured out why and it isn't vary reproducible, but it
> must have something to do with the cache since it goes away when
> I reload the file)

It is possible, indeed. You can also use M-x org-element-cache-reload to
check this. However, cache is disabled by default, so the problem
shouldn't appear in normal usage.

I start to think that there is no bug in clock tables (but certainly in
the cache mechanism, probably related to some `before-change-functions'
and `after-change-functions' misuse there).

WDYT?

Regards,

-- 
Nicolas Goaziou



Re: [O] More clocktable breakage

2017-05-06 Thread Achim Gratz
> As I asked 5 weeks ago (!), could you provide an ECM demonstrating the
> issue so that I can fix it, in the light of our discussion?

I've told you from the beginning that it was a file at work and that it
would take some time to dig down to the problem since it did work at
home when I tried to create said ECM.  After a few false starts
(thinking that it was Windows vs. Linux and the local configurations on
each side) I've finally converged to this (just insert a new clocktable,
then replace the default parameters with tstart/tend):

--8<---cut here---start->8---
  #+BEGIN: clocktable :tstart "<2017-03-24 Fri 00:00>" :tend "<2017-04-23 Sat 
23:45>"
  #+CAPTION: Clock summary at [2017-05-06 Sat 11:09]
  | L | Headline | Time   |   |
  |---+--++---|
  |   | *Total time* | *0:00* |   |
  #+END:
--8<---cut here---end--->8---

Sometimes org-element-context recognizes the clocktable as a paragraph
instead of dynamic-block (I've not yet figured out why and it isn't vary
reproducible, but it must have something to do with the cache since it
goes away when I reload the file) and then 'timestamp gets returned when
the cursor is on one of the timestamps.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] More clocktable breakage

2017-05-06 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> No, I meant context of application, rather than context in the
> syntactical sense.  Org-element-* deals with syntax, nothing else.
> Whether you need strict syntactical interpretation or something else
> gets decided someplace else.

OK. Then we agree here.

> Whatever it sounds like, what you want in the clocktables example and
> the properties example (and elsewhere) is something that looks, walks
> and talks like a timestamp if you'd put it into the proper context.  In
> each of these places the text that looks like timestamp but isn't
> (org-element says so) will be fed into some machinery that emerges with
> a result that is indistinguishable from what you'd get if that text
> would have been a proper timestamp and then uses that result to do
> whatever it wants to do with it (i.e. most certainly not build up an
> agenda, although it could do that as well).  It uses a bit of Org syntax
> in the improper context to achieve this (and this requires precisely to
> ignore that context or at least check with something more loose than
> org-element).

I also agree, but it seems to contradict what you write below.

> In a comment that timestamp-looking text doesn't have any function, so
> it's in a different category, I must insist.  As I said, I can see
> somebody wanting to have this text be editable like any other timestamp
> also, but it's really the other uses where it's used meta-syntactically
> that I'd like to focus on.

Here, I don't follow you anymore. A timestamp in a comment is "something
that looks, walks and talks like a timestamp if you'd put it into the
proper context", too. So there's no difference with properties or the
clock table.

> One of the differences to text in comments (or generally quoted
> material) is that there is an expectation that this sort of timestamp
> is correct, since they are intended to be input to further processing.

True, but if that timestamps isn't correct, it doesn't "look, walk and
talk" like a timestamp anymore, so this doesn't apply to the above.

Anyway, I think we're digressing. We're talking about design, yet, to
tell the truth, I don't even know anymore what the original, concrete,
problem is really about.

As I asked 5 weeks ago (!), could you provide an ECM demonstrating the
issue so that I can fix it, in the light of our discussion?


Regards,

-- 
Nicolas Goaziou



Re: [O] More clocktable breakage

2017-05-02 Thread Achim Gratz
Nicolas Goaziou writes:
>> I'd say anything org-element-* should exclusively return syntactical
>> things.  Context dependence needs to be dealt with elsewhere.
>
> I'm not sure to understand this. Syntactical things are all about
> context dependence in Org. Do you mean /context independance/ needs to
> be dealt with elsewhere?

No, I meant context of application, rather than context in the
syntactical sense.  Org-element-* deals with syntax, nothing else.
Whether you need strict syntactical interpretation or something else
gets decided someplace else.

> Could you provide examples about that? In particular "providing
> timestamps as arguments to any processing functions" sounds odd, in
> particular from someone who cringes when I suggest to add a second
> optional argument to a single function.

Whatever it sounds like, what you want in the clocktables example and
the properties example (and elsewhere) is something that looks, walks
and talks like a timestamp if you'd put it into the proper context.  In
each of these places the text that looks like timestamp but isn't
(org-element says so) will be fed into some machinery that emerges with
a result that is indistinguishable from what you'd get if that text
would have been a proper timestamp and then uses that result to do
whatever it wants to do with it (i.e. most certainly not build up an
agenda, although it could do that as well).  It uses a bit of Org syntax
in the improper context to achieve this (and this requires precisely to
ignore that context or at least check with something more loose than
org-element).

>> If I'd follow that road, I could edit what looks like a timestamp
>> everywhere, regardless of context.  I don't know if that's the right
>> thing to do and I don't even expect consensus among the Org user base.
>> I personally see no need to do that.
>
> I do see it, tho. This is analogous to links in comments. If you see
> something looking like a timestamp (or a link), you can expect some
> commands to operate on it. This is exactly what is biting us at the
> moment.

In a comment that timestamp-looking text doesn't have any function, so
it's in a different category, I must insist.  As I said, I can see
somebody wanting to have this text be editable like any other timestamp
also, but it's really the other uses where it's used meta-syntactically
that I'd like to focus on.  ONe of the differences to text in comments
(or generally quoted material) is that there is an expectation that this
sort of timestamp is correct, since they are intended to be input to
further processing.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] More clocktable breakage

2017-05-02 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> Well, taking a further setp back, before Org started to have a formal
> syntax anything that looked like a timestamp was treated as one.  The
> different categories of timestamps really arise from the fact that we
> now have syntactical timestamps and non-syntactical ones.

I don't pretend the contrary. I'm just talking about the current state
of timestamps.

Oh, and it is a really good thing Org now has a formal syntax.

> This in turn requires that each function dealing with timestamps needs
> to specify what exactly it wants to deal with, but as this discussion
> amply shows, that isn't quite as straightforward as one would think.

Indeed.

>> The first category is the "strict" one, which follows Org syntax
>> definition. None of the examples above belong to that category.
>> `org-element-context' should be the relative predicate, which means that
>> it probably shouldn't return a timestamp object on planning lines, as it
>> does at the moment.
>
> I'd say anything org-element-* should exclusively return syntactical
> things.  Context dependence needs to be dealt with elsewhere.

I'm not sure to understand this. Syntactical things are all about
context dependence in Org. Do you mean /context independance/ needs to
be dealt with elsewhere?

> I would call that meta-syntax or maybe quoted syntax: you are looking at
> a proper timestamp, to be used somewhere else where a timestamp is
> needed, but in a context that doesn't specify a timestamp itself.  There
> are many analogous cases elsewhere in Org, so it may be a fruitful
> endeavour to consider this in a more general fashion.  Providing
> timestamps as arguments to any processing functions (built into Org or
> otherwise) carries the requirement that they should syntactically be
> correct as a timestamp (so they can be converted into a timestamp object
> at the place of use), so all functions to insert and edit a timestamp
> need to work at those places.

Could you provide examples about that? In particular "providing
timestamps as arguments to any processing functions" sounds odd, in
particular from someone who cringes when I suggest to add a second
optional argument to a single function.

> If I'd follow that road, I could edit what looks like a timestamp
> everywhere, regardless of context.  I don't know if that's the right
> thing to do and I don't even expect consensus among the Org user base.
> I personally see no need to do that.

I do see it, tho. This is analogous to links in comments. If you see
something looking like a timestamp (or a link), you can expect some
commands to operate on it. This is exactly what is biting us at the
moment.

The real problem is that, deep into the functions calls triggered by
(org-shift*), one of them expects to operate on timestamps at least from
category 2 (i.e., it uses `org-at-timestamp-p') while we're in
category 3. The solution is not to promote current timestamp to category
2 but to relax requirements from the guilty function, so that it also
operates on category 3. Fixing it is easy: we just need to replace
`org-at-timestamp-p' with (org-in-regexp org-ts-regexp) at the
appropriate place.

IIUC, however, we are discussing higher level details, i.e., about
predicates for each category, and the developer interface we want to
provide.

> Agreed.  That's why I'm hesitant to change the org-at-timestamp-p to
> (org-in-regexp org-ts-regexp) in the edit functions.  What I don't agree
> with (if I've read you correctly) is the implied assertion that the
> clocktable example is in the last category.  Or maybe it is at the
> moment, but it ought to be in the second one.  I consider only examples
> (3) and (5) to be in the "last" category.

The second category, according to my previous message, is about agenda.
Writing

  * Entry
  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"
  ...
  #+END:

doesn't mean you want to display "Entry" in the agenda for today. It is
but a parameter to the clocktable that happens to use timestamp syntax.

It belongs neither to the first category nor the second one.

>> Yet, `org-at-timestamp-p' is something users are going to look after.
>> Different names may also introduce confusion (remember `org-at-regexp-p'
>> and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
>> a single predicate, or even two if we set "agenda" apart, with
>> a docstring explaining the different categories and how to select them
>> may also be a good natural choice. Hence my suggestion.
>
> Since org-at-timestamp-p already has an argument, adding a second one
> doesn't look appealing to me, especially when the first one would often
> be nil.  Maybe it's possible to change the definition of that argument
> (which would need the equivalence between t meaning 'inactive).
>
>> WDYT? Do you have any other concrete proposal?
>
> I really only need the clocktables to work again, which they'd be if
> they were in the second category, I gather.  

Re: [O] More clocktable breakage

2017-05-01 Thread Achim Gratz
Nicolas Goaziou writes:
> Sadly, what a "timestamp" is depends on what function is asking. AFAICT,
> there are three categories of "timestamps".

Well, taking a further setp back, before Org started to have a formal
syntax anything that looked like a timestamp was treated as one.  The
different categories of timestamps really arise from the fact that we
now have syntactical timestamps and non-syntactical ones.  This in turn
requires that each function dealing with timestamps needs to specify
what exactly it wants to deal with, but as this discussion amply shows,
that isn't quite as straightforward as one would think.

> Let's consider the following examples:
>
>   (1)
>   SCHEDULED: <2017-04-30 dim.>
>
>   (2)
>   CLOCK: [2017-04-30 dim. 08:10]--[2017-04-30 dim. 08:11] =>  0:01
>
>   (3)
>   : <2017-04-30 dim.>
>
>   (4)
>   :PROPERTIES:
>   :DATE: <2017-04-30 dim.>
>   :END:
>
>   (5)
>   # <2017-04-30 dim.>
>
>   (6)
>
>   #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"
>
> The first category is the "strict" one, which follows Org syntax
> definition. None of the examples above belong to that category.
> `org-element-context' should be the relative predicate, which means that
> it probably shouldn't return a timestamp object on planning lines, as it
> does at the moment.

I'd say anything org-element-* should exclusively return syntactical
things.  Context dependence needs to be dealt with elsewhere.

> The second category, which is a super-set of the previous one, is
> "agenda" one. Historically, Org allowed to insert timestamps in property
> drawers, e.g., as in (4), and use them in the agenda. So basically, this
> category contains "every timestamp that would appear as a plain
> timestamp in the agenda if it were active". `org-at-timestamp-p' is
> currently the relative predicate for that category. Note that the
> category also contains (2) if inactive timestamps are meant to be
> displayed in the agenda.

I would call that meta-syntax or maybe quoted syntax: you are looking at
a proper timestamp, to be used somewhere else where a timestamp is
needed, but in a context that doesn't specify a timestamp itself.  There
are many analogous cases elsewhere in Org, so it may be a fruitful
endeavour to consider this in a more general fashion.  Providing
timestamps as arguments to any processing functions (built into Org or
otherwise) carries the requirement that they should syntactically be
correct as a timestamp (so they can be converted into a timestamp object
at the place of use), so all functions to insert and edit a timestamp
need to work at those places.

> The last category, a super-set of the "agenda" one, is the "convenience"
> category. Basically, it contains every occurrence of what looks like
> a timestamp, but isn't necessarily one. Obviously, every example given
> above fits in there, as in every case, you can ignore that Org has
> a context-dependant grammar and pretend you are on a timestamp. There is
> no predicate relative to that category, but `org-at-timestamp-p'
> docstring suggests to use (org-in-regexp org-ts-regexp).

If I'd follow that road, I could edit what looks like a timestamp
everywhere, regardless of context.  I don't know if that's the right
thing to do and I don't even expect consensus among the Org user base.
I personally see no need to do that.

> So, about the predicates, I guess we could move the second one into
> "org-agenda.el" and rename it `org-agenda-at-timestamp-p'. However,
> using `org-at-timestamp-p' for the last category seems a bit
> far-stretched to me, since it doesn't always match timestamps. In
> particular, (3) and (5) sound counter-intuitive to me and I wouldn't
> like it from a developer standpoint. `org-at-timestamp' is also not
> really needed for the first category, since there is already
> `org-element-context'.

Agreed.  That's why I'm hesitant to change the org-at-timestamp-p to
(org-in-regexp org-ts-regexp) in the edit functions.  What I don't agree
with (if I've read you correctly) is the implied assertion that the
clocktable example is in the last category.  Or maybe it is at the
moment, but it ought to be in the second one.  I consider only examples
(3) and (5) to be in the "last" category.

> Yet, `org-at-timestamp-p' is something users are going to look after.
> Different names may also introduce confusion (remember `org-at-regexp-p'
> and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
> a single predicate, or even two if we set "agenda" apart, with
> a docstring explaining the different categories and how to select them
> may also be a good natural choice. Hence my suggestion.

Since org-at-timestamp-p already has an argument, adding a second one
doesn't look appealing to me, especially when the first one would often
be nil.  Maybe it's possible to change the definition of that argument
(which would need the equivalence between t meaning 'inactive).

> WDYT? Do you have any other concrete proposal?

I really only 

Re: [O] More clocktable breakage

2017-04-30 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> That's what I've been asking the whole time: when you changed that
> predicate, you've basically cut off some of its consumers.  It looks
> like bad factoring to me to then splitting the same predicate based on
> some argument.  I'd rather pull out the old sloppy matching into a new
> predicate for instance.

There are drawbacks in both choices. More on this below.

> I don't use planning, so no.  But it seems to me that the only way for
> org-element-context to deliver a 'timestamp is when pos is on a planning
> line (that may be wrong, I just don't see where else a 'timestamp would
> be returned).  In that case we've already left the cond, so testing for it
> doesn't do anything useful.  I'm also not really sure why the existing
> exceptions from the "true" timestamp (planning, property and clock-log)
> are any different than "dynamic block" would be (with the appropriate
> change of the doc string of course).y

I start to see where the confusion comes from. 

Sadly, what a "timestamp" is depends on what function is asking. AFAICT,
there are three categories of "timestamps".

Let's consider the following examples:

  (1)
  SCHEDULED: <2017-04-30 dim.>

  (2)
  CLOCK: [2017-04-30 dim. 08:10]--[2017-04-30 dim. 08:11] =>  0:01

  (3)
  : <2017-04-30 dim.>

  (4)
  :PROPERTIES:
  :DATE: <2017-04-30 dim.>
  :END:

  (5)
  # <2017-04-30 dim.>

  (6)
  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"

The first category is the "strict" one, which follows Org syntax
definition. None of the examples above belong to that category.
`org-element-context' should be the relative predicate, which means that
it probably shouldn't return a timestamp object on planning lines, as it
does at the moment.

The second category, which is a super-set of the previous one, is
"agenda" one. Historically, Org allowed to insert timestamps in property
drawers, e.g., as in (4), and use them in the agenda. So basically, this
category contains "every timestamp that would appear as a plain
timestamp in the agenda if it were active". `org-at-timestamp-p' is
currently the relative predicate for that category. Note that the
category also contains (2) if inactive timestamps are meant to be
displayed in the agenda.

The last category, a super-set of the "agenda" one, is the "convenience"
category. Basically, it contains every occurrence of what looks like
a timestamp, but isn't necessarily one. Obviously, every example given
above fits in there, as in every case, you can ignore that Org has
a context-dependant grammar and pretend you are on a timestamp. There is
no predicate relative to that category, but `org-at-timestamp-p'
docstring suggests to use (org-in-regexp org-ts-regexp).

So, about the predicates, I guess we could move the second one into
"org-agenda.el" and rename it `org-agenda-at-timestamp-p'. However,
using `org-at-timestamp-p' for the last category seems a bit
far-stretched to me, since it doesn't always match timestamps. In
particular, (3) and (5) sound counter-intuitive to me and I wouldn't
like it from a developer standpoint. `org-at-timestamp' is also not
really needed for the first category, since there is already
`org-element-context'.

Yet, `org-at-timestamp-p' is something users are going to look after.
Different names may also introduce confusion (remember `org-at-regexp-p'
and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
a single predicate, or even two if we set "agenda" apart, with
a docstring explaining the different categories and how to select them
may also be a good natural choice. Hence my suggestion.

WDYT? Do you have any other concrete proposal?

Regards,

-- 
Nicolas Goaziou



Re: [O] More clocktable breakage

2017-04-28 Thread Achim Gratz
Nicolas Goaziou writes:
> Another idea is to add an optional argument to `org-at-timestamp-p' to
> allow "sloppy" matching (or strict matching, it doesn't really matter)
> and skip checks when it is required. So all functions requiring this
> predicate can make use of it, as long as they call it properly.
>
> WDYT?

That's what I've been asking the whole time: when you changed that
predicate, you've basically cut off some of its consumers.  It looks
like bad factoring to me to then splitting the same predicate based on
some argument.  I'd rather pull out the old sloppy matching into a new
predicate for instance.

>> Also, again, I think that function is buggy even without these issues as
>> the only code I can find in org-element-context that deals with
>> timestamps is conditional on being on a planning line and if that's true
>> we should never get there.
>
> I don't think there is a bug there. Do you have an ECM?

I don't use planning, so no.  But it seems to me that the only way for
org-element-context to deliver a 'timestamp is when pos is on a planning
line (that may be wrong, I just don't see where else a 'timestamp would
be returned).  In that case we've already left the cond, so testing for it
doesn't do anything useful.  I'm also not really sure why the existing
exceptions from the "true" timestamp (planning, property and clock-log)
are any different than "dynamic block" would be (with the appropriate
change of the doc string of course).y


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] More clocktable breakage

2017-04-27 Thread Nicolas Goaziou
Achim Gratz  writes:

> and org-at-block-p only matches in the first line of a dynamic block,

[...]

> N.B.: The regex used in org-at-block-p is overbroad since it matches the
> whole block, I think it should use org-at-dblock-start-re instead.

This old and buggy function has nothing to do with the problem at hand.
Also, even if it used org-at-dblock-start-re, it would still be buggy
(is it closed? is it in an example block?).

> Anyway, when you changed the scope of that function you'd need to check
> all users of the API and fix them where necessary.

Really? I thought it would magically happen... somehow. Silly me.

> The main users of that predicate were and still are the org-shift*
> family of commands and they do expect a looser recognition than what
> you implemented based on the docstring. Maybe that's true in other
> places also, I haven't checked.

The main user of that predicate is the agenda, now.

> It's also obvious that the test coverage of this is bad.

Patch welcome.

> So that looser recognition would need to be factored out again or you
> revert this predicate and apply the stricter check where it matters
> (the agenda functions, most likely).

Another idea is to add an optional argument to `org-at-timestamp-p' to
allow "sloppy" matching (or strict matching, it doesn't really matter)
and skip checks when it is required. So all functions requiring this
predicate can make use of it, as long as they call it properly.

WDYT?

> Also, again, I think that function is buggy even without these issues as
> the only code I can find in org-element-context that deals with
> timestamps is conditional on being on a planning line and if that's true
> we should never get there.

I don't think there is a bug there. Do you have an ECM?

Regards,



Re: [O] More clocktable breakage

2017-04-27 Thread Achim Gratz
Nicolas Goaziou writes:

  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend 
 "<2006-08-10 Thu 12:00>"
  #+END: clocktable
>
> These are not timestamps. Even though they look like timestamps, you
> wouldn't want them to appear in the agenda. So `org-at-timestamp-p' is
> correct, IMO. Moreover, its docstring says
[…]

Well, that's the change you made that I pointed at earlier.  The
functionality of org-shift* has unfortunately regressed due to
that change you introduced by "hardening" the recognition of timestamps.
And no, to the user they really are timestamps in the arguments of a
dynamic block, splitting syntactical hairs aside.

> so ISTM a correct fix would be to have the function you're calling (I
> don't remember it) use this instead of `org-at-timestamp-p'.

I already said that the fix might not be the right one, although it
would be in the same spirit as the exceptions already present for
properties drawers, planning lines and clocks and org-at-block-p only
matches in the first line of a dynamic block, so I'd say it's still
sufficiently constrained.

N.B.: The regex used in org-at-block-p is overbroad since it matches the
whole block, I think it should use org-at-dblock-start-re instead.

Anyway, when you changed the scope of that function you'd need to check
all users of the API and fix them where necessary.  The main users of
that predicate were and still are the org-shift* family of commands and
they do expect a looser recognition than what you implemented based on
the docstring.  Maybe that's true in other places also, I haven't
checked.  It's also obvious that the test coverage of this is bad.  So
that looser recognition would need to be factored out again or you
revert this predicate and apply the stricter check where it matters (the
agenda functions, most likely).

Also, again, I think that function is buggy even without these issues as
the only code I can find in org-element-context that deals with
timestamps is conditional on being on a planning line and if that's true
we should never get there.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] More clocktable breakage

2017-04-27 Thread Nicolas Goaziou
Achim Gratz  writes:

> Achim Gratz writes:
>> Nicolas Goaziou writes:
>>> At the moment, I cannot reproduce it. I tried M-up in the following
>>> document:
>>>
>>>  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend 
>>> "<2006-08-10 Thu 12:00>"
>>>  #+END: clocktable

These are not timestamps. Even though they look like timestamps, you
wouldn't want them to appear in the agenda. So `org-at-timestamp-p' is
correct, IMO. Moreover, its docstring says

  This function checks context and only return non-nil for valid
  time stamps.  If you need to match anything looking like a time
  stamp, or if you are sure about the context, consider using
  ‘org-in-regexp’, e.g.,

(org-in-regexp org-ts-regexp)

so ISTM a correct fix would be to have the function you're calling (I
don't remember it) use this instead of `org-at-timestamp-p'.

WDYT?

-- 
Nicolas Goaziou



Re: [O] More clocktable breakage

2017-04-27 Thread Achim Gratz
Achim Gratz writes:
> Nicolas Goaziou writes:
>> At the moment, I cannot reproduce it. I tried M-up in the following
>> document:
>>
>>  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 
>> Thu 12:00>"
>>  #+END: clocktable
>
> The breakage happens in this clause in org-at-timestamp-p:
>
>(match
> (let ((boundaries (org-in-regexp tsr)))
>   (save-match-data
> (cond ((null boundaries) nil)
>   ((org-at-planning-p))
>   ((org-at-property-p))
>   ;; CLOCK lines only contain inactive time-stamps.
>   ((and inactive-ok (org-at-clock-log-p)))
>   (t
>(eq 'timestamp
>(save-excursion
>  (when (= pos (cdr boundaries)) (forward-char -1))
>  (org-element-type (org-element-context))
>
> After matching the timestamp in the header argument correctly, the code
> falls through to the default cond, where (org-element-type
> (org-element-context)) returns 'dynamic-block, which isn't a 'timestamp.
> The successful match gets discarded and the timestamp doesn't get
> recognized.  An empty clause for (org-at-block-p) would fix it, but I'm
> not sure that is the right thing to do.  I haven't looked at
> org-element-context to see whether it might misinterpret something.

I did look at org-element-context and the code in org-at-timstamp-p
makes even less sense to me now.  The only time org-element-context
returns 'timestamp is when it is on a planning line, but
org-at-timstamp-p has already left the cond in that case in the second
clause.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] More clocktable breakage

2017-04-26 Thread Achim Gratz
Nicolas Goaziou writes:
> At the moment, I cannot reproduce it. I tried M-up in the following
> document:
>
>  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 
> Thu 12:00>"
>  #+END: clocktable

The breakage happens in this clause in org-at-timestamp-p:

--8<---cut here---start->8---
 (match
  (let ((boundaries (org-in-regexp tsr)))
(save-match-data
  (cond ((null boundaries) nil)
((org-at-planning-p))
((org-at-property-p))
;; CLOCK lines only contain inactive time-stamps.
((and inactive-ok (org-at-clock-log-p)))
(t
 (eq 'timestamp
 (save-excursion
   (when (= pos (cdr boundaries)) (forward-char -1))
   (org-element-type (org-element-context))
--8<---cut here---end--->8---

After matching the timestamp in the header argument correctly, the code
falls through to the default cond, where (org-element-type
(org-element-context)) returns 'dynamic-block, which isn't a 'timestamp.
The successful match gets discarded and the timestamp doesn't get
recognized.  An empty clause for (org-at-block-p) would fix it, but I'm
not sure that is the right thing to do.  I haven't looked at
org-element-context to see whether it might misinterpret something.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] More clocktable breakage

2017-03-29 Thread Nicolas Goaziou
Hello,

Achim Gratz  writes:

> I've just noticed that in my the clocktables at work I can't adjust the
> start and end ranges anymore with up/down.  Apparently the timestamps
> are not recognized anymore and the it falls through to some code that
> tries to adjust the :block argument (which is not present in that table
> since it's using :tstart / :tend) and fails with an error message.  I've
> bisected that behaviour to commit 2a59d2f76f.  Unfortunately I can't
> reproduce that here at home, maybe due to the fact that the language
> settings are different.  At home the timestamps are recognized and the
> clocktable is re-calculated accordingly.  However, I cannot refresh the
> clocktable via C-c C-c, which tells me it cannot do anything useful at
> that line.

At the moment, I cannot reproduce it. I tried M-up in the following
document:

 #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 
Thu 12:00>"
 #+END: clocktable

I'm interested in an ECM, if you can provide one.

Regards,

-- 
Nicolas Goaziou



[O] More clocktable breakage

2017-03-28 Thread Achim Gratz

I've just noticed that in my the clocktables at work I can't adjust the
start and end ranges anymore with up/down.  Apparently the timestamps
are not recognized anymore and the it falls through to some code that
tries to adjust the :block argument (which is not present in that table
since it's using :tstart / :tend) and fails with an error message.  I've
bisected that behaviour to commit 2a59d2f76f.  Unfortunately I can't
reproduce that here at home, maybe due to the fact that the language
settings are different.  At home the timestamps are recognized and the
clocktable is re-calculated accordingly.  However, I cannot refresh the
clocktable via C-c C-c, which tells me it cannot do anything useful at
that line.


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] more global keys in ox-bibtex

2017-02-03 Thread Nicolas Goaziou
Hello,

Sébastien Le Maguer  writes:

> I did a mini-patch to capture completely the key in bibtex export. For 
> example for the following key, in the bibtex2html produced file:
>
> Balestri etal., 1999
>
> only Balestri will be captured instead of Balestri etal., 1999
>
> As it is 3 characters, I just submit the patch here and hope it might
> help :)

Thank you.

Would you mind sending it using git format-patch and adding a commit
message?

Regards,

-- 
Nicolas Goaziou



[O] more global keys in ox-bibtex

2017-01-22 Thread Sébastien Le Maguer
Dear All,

I did a mini-patch to capture completely the key in bibtex export. For example 
for the following key, in the bibtex2html produced file:

Balestri etal., 1999

only Balestri will be captured instead of Balestri etal., 1999

As it is 3 characters, I just submit the patch here and hope it might help :)

Kind regards,
Sébastien
diff --git a/contrib/lisp/ox-bibtex.el b/contrib/lisp/ox-bibtex.el
index 56dec38..fb34a5e 100644
--- a/contrib/lisp/ox-bibtex.el
+++ b/contrib/lisp/ox-bibtex.el
@@ -235,7 +235,7 @@ Return new parse tree."
 	  ;; Update `org-bibtex-html-entries-alist'.
 	  (goto-char (point-min))
 	  (while (re-search-forward
-		  "a name=\"\\([-_a-zA-Z0-9:]+\\)\">\\(\\w+\\)" nil t)
+		  "a name=\"\\([-_a-zA-Z0-9:]+\\)\">\\([^<]+\\)" nil t)
 		(push (cons (match-string 1) (match-string 2))
 		  org-bibtex-html-entries-alist)))
 	;; Open produced HTML file, wrap references within a block and

--
Dr. Sébastien Le Maguer
Postdoctorate researcher

Saarland University
Campus C7.4 - room 2.03
D-66123 Saarbrücken
Germany

phone : +49-681-302-70030
Mail: slemag...@coli.uni-saarland.de
website :  http://www.coli.uni-saarland.de/~slemaguer/


Re: [O] more than 2 indexes in org-mode -> latex

2016-07-02 Thread Sharon Kimble
Sharon Kimble  writes:

> How many indexes can you have in an org-mode document exported to latex?
> My experience shows 2! So how can I have 3, or more please?
>
> This is the relevant part, I think, of my preamble of my file -
>
> #+latex_header: \usepackage{imakeidx}
> #+latex_header: \makeindex[title=Index,options=-s 
> ./index.ist,columnseprule,intoc]
> #+latex_header: \makeindex[name=ps,title=Index of Symptoms,options=-s 
> ./index.ist,columnseprule,intoc]
> # #+latex_header: \makeindex[name=se,title=Index of Side-effects,options=-s 
> ./index.ist,columnseprule,intoc]
>
> I can have any choice of 2, but not 3 as I would like.
>
> In a 'straight' latex file using the above commands I can have 3 or
> more, so how do I get it to allow 3 or more in org-mode please?
>

Answering my own question and saying you've made a cock-up! I'm using
the 'morewrites' package and if you include it after setting up the
indexes you will get this result with using 3 indexes -

--8<---cut here---start->8---
(/usr/local/texlive/2016/texmf-dist/tex/latex/morewrites/morewrites.sty
(/usr/local/texlive/2016/texmf-dist/tex/latex/morewrites/primargs.sty)
! No room for a new \write.
\e@ch@ck ...message {No room for a new \string #4}
  \fi \fi 
l.34 \newwrite \g__morewrites_iow
--8<---cut here---end--->8---

But if you put morewrites before the index setup, then 3 or more indexes
work perfectly well, with absolutely zero problems.

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.4, fluxbox 1.3.7, emacs 25.0.95


signature.asc
Description: PGP signature


[O] more than 2 indexes in org-mode -> latex

2016-07-01 Thread Sharon Kimble

How many indexes can you have in an org-mode document exported to latex?
My experience shows 2! So how can I have 3, or more please?

This is the relevant part, I think, of my preamble of my file -

--8<---cut here---start->8---
#+latex_header: \usepackage{imakeidx}
#+latex_header: \makeindex[title=Index,options=-s 
./index.ist,columnseprule,intoc]
#+latex_header: \makeindex[name=ps,title=Index of Symptoms,options=-s 
./index.ist,columnseprule,intoc]
# #+latex_header: \makeindex[name=se,title=Index of Side-effects,options=-s 
./index.ist,columnseprule,intoc]
--8<---cut here---end--->8---

I can have any choice of 2, but not 3 as I would like.

In a 'straight' latex file using the above commands I can have 3 or
more, so how do I get it to allow 3 or more in org-mode please?

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.4, fluxbox 1.3.7, emacs 25.0.95


signature.asc
Description: PGP signature


Re: [O] More questions about CSL and org-mode

2015-12-08 Thread John Kitchin

>> On export the in-text citations are transformed to unique text blobs,
>> e.g. uuids, and the document exported. The only important features of
>> these blobs is that they do not get changed on export, and they are
>> unique because we replace them later.
>>
>> The strings in the bibliography entry are "exported" to convert the
>> org-markup to the output format. The in-text citations, expanded
>> bibliography and style are sent to the citation processor, which outputs
>> replacements and a formatted bibliography in the desired output format.
>>
>> Finally, you replace each uuid with the appropriate replacement, and
>> insert the bibliography where it belongs. That should be the final
>> document.
>
> IIUC, the problem with this approach is that it will not work well when
> the citation style is note-based rather than inline.  The main
> motivation for going "back to Org" is that note-based styles require the
> document structure to change as a result of citation processing: new
> footnotes have to be inserted, and existing ones have to be renumbered.
> That is relatively hard to do if the rest of the document is already in
> the target format (except with LaTeX).  By doing citation processing
> early in the export process and converting the results to Org, we can
> rely on Org's footnote processing to handle this later in the export
> process.

I guess I don't understand what note-based citations look like, or why
you would have to renumber footnotes in this process. Does the order
change for some reason? Even if it does, it sounds like this might just
require another pass of calculations to figure out how to replace
things.

Any chance you could send me a document with note-based citations?

One place where text-based replacement doesn't work I guess is outputs
that aren't plain text based. Maybe, for example, to ODT where the
output creates multiple xml files in a zip file?

> As far as I can see, if it weren't for note-based styles, this approach
> would work fine.  (Indeed, it is pretty much what the existing org-cite
> code does, except that the mapping between citations and their
> replacements is done with Lisp data structures rather than via string
> replacement in the output buffer.  I stopped work on that right about
> the time I realized the existing approach wouldn't work very well with
> note-based styles.)
>
> But given the problem about nested formatting, going back to Org at the
> level of text replacements doesn't work.  In other words: both of the
> simple-minded approaches (process citations directly to text in the
> target format, or process them to Org text, then let Org convert them to
> the target format) face problems.
>
> I think probably what we'll have to do to accommodate both note-based
> styles and the possibility of nested formatting is to get the results of
> citation processing in some unambiguous format like HTML or JSON, then
> parse it, and then use the result to directly modify the parse tree for
> the Org document before continuing the export process.  I can't see an
> easier way...can anyone else?

Like getting an xml citation, and then using xslt to translate it to the
format you want? Or something equivalent? Your translation would still
have to be clever to avoid nested syntax, which I guess requires some
recursive parsing of the output.

Modifying the parse tree is more elegant than the replacement text idea.
I have to learn how to do this one day ;)

>
> Best,
> Richard

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



Re: [O] More questions about CSL and org-mode

2015-12-07 Thread John Kitchin

Richard Lawrence writes:

> Hi John,
>
> John Kitchin  writes:
>
>> Hi all,
>>
>> This is mostly for the people working on citations in org-mode.
>>
>> I have been reading about CSL more this weekend. IIRC, one of the
>> reasons to develop the new citation syntax was to get the ability to
>> have pre/post text in citations more conveniently than what is currently
>> possible.
>
> Yes, that is my understanding, too.
>
>> I have not seen any possibility for this with CSL, however. Is my
>> understanding correct? Is this a problem, or something partially handled
>> by org-export and partially by a citeproc?
>
> The CSL processors I've looked at support prefix and suffix text for
> individual references within a citation.  See, for example, the
> citeproc-js documentation:
>
> http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#citation-data-object
>
> prefix, suffix, and some other fields are supported.  pandoc-citeproc
> supports the same set of fields.

Interesting. I guess these are not standard for all processors? It also
looks like it would be hard to get something like an inline reference
formatted as [1] but refer to Reference 1, e.g. from citenum. It is
possible to have (Kitchin 2007) and (2007) but not a citation reference
to Kitchin that is derived from e.g. a citeauthor command in LaTeX. I am
not raising any objections here, just getting a sense for what is
feasible.

>
> However, my understanding is that neither citeproc-js nor
> pandoc-citeproc support a BibLaTeX-style "common" prefix/suffix that
> belongs to the citation as a whole, rather than the individual
> references within it, as is available in the multi-cite commands.  We
> currently have support for such common prefixes/suffixes in Org syntax.
>
> My solution to this in my org-citeproc wrapper for pandoc-citeproc is to
> prepend the common prefix to the prefix for the first reference in a
> citation, and append the common suffix to the last reference.  This is
> not a great solution, because it is not really defined what kind of
> punctuation (if any) should separate the common prefix from the first
> item's prefix, and so on.  But I figured that was not an important issue
> to address until we actually have people making use of common prefix and
> suffix syntax who are not exporting to LaTeX...

agreed.

>
>> IIUC, the current aim is to get a citeproc that will do the following on
>> export:
>> 1. replace in-text citation syntax with org-formatted replacements
>> 2. Insert an org-formatted bibliography somewhere in the document
>> 3. proceed with org-to-something export, with built-in
>> exporters.
>
> That's basically my understanding too.  There is one snag with the
> "org-formatted replacement" plan, though, which I saw in a Zotero dev
> discussion yesterday.  CSL processing might result in multiple levels of
> formatting, e.g. nested italics like
>
> Something with an internal Title
>
> and that won't translate very well back to Org syntax in general:
>
> /Something with an internal /Title//
>
> The suggestion was to just use HTML output, and then parse the HTML to
> get a data structure that could be directly rendered into HTML, LaTeX,
> etc., which support nested italics just fine.  I think we could do this,
> though maybe there's a better solution.  That is, we can take HTML from
> the citation processor and go directly to org-element objects, without
> producing and re-parsing citations in Org format.

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



Re: [O] More questions about CSL and org-mode

2015-12-07 Thread John Kitchin
Thanks.

Its an interesting jam. You want to have multiple outputs as a
possibility, but there isn't a robust markup that readily works across
all backends.

What about this. For now consider a bibliography database with
org-formatting in the entries, e.g. subscripts, superscripts, etc...
(but not like putting italics on titles or anything related to
bibliography formatting). So I can have a title like "The role of H_{2}O
in /d/-orbital splitting of \alpha particles" in an entry. I assume it
would also be ok to have utf-8 characters in it. Equations are still
problematic, as we use LaTeX syntax for those.

On export the in-text citations are transformed to unique text blobs,
e.g. uuids, and the document exported. The only important features of
these blobs is that they do not get changed on export, and they are
unique because we replace them later.

The strings in the bibliography entry are "exported" to convert the
org-markup to the output format. The in-text citations, expanded
bibliography and style are sent to the citation processor, which outputs
replacements and a formatted bibliography in the desired output format.

Finally, you replace each uuid with the appropriate replacement, and
insert the bibliography where it belongs. That should be the final
document.

If you did this with a bibtex file, it would probably break its use in
LaTeX without some clever transformation of the bibtex file to a new
file that was LaTeX formatted, and an on the fly change to the org
buffer to use this new file. But, since the point of this is for
non-LaTeX export, I guess this is ok.

I bet you could even expand the bibtex format to include journal
abbreviations, and directly use the fields that CSL uses (although I
strongly dislike "container-title" for the journal name!)

The downside is the processor now needs to output different formats, but
presumably there are a few standard ones that are a one-time investment
like html.


Richard Lawrence writes:

> Richard Lawrence  writes:
>
>>> IIUC, the current aim is to get a citeproc that will do the following on
>>> export:
>>> 1. replace in-text citation syntax with org-formatted replacements
>>> 2. Insert an org-formatted bibliography somewhere in the document
>>> 3. proceed with org-to-something export, with built-in
>>> exporters.
>>
>> That's basically my understanding too.  There is one snag with the
>> "org-formatted replacement" plan, though, which I saw in a Zotero dev
>> discussion yesterday.
>
> Here's the reference for that discussion, by the way:
>
> https://groups.google.com/d/msg/zotero-dev/Bz_IenruxX4/24QWuyEIp_IJ
>
> Best,
> Richard
>
> P.S.  John, thanks for your continued research on this.  I see that our
> procrastination habits are on the same schedule. :)

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



Re: [O] More questions about CSL and org-mode

2015-12-07 Thread Richard Lawrence
Hi John,

John Kitchin  writes:

> Thanks.
>
> Its an interesting jam. You want to have multiple outputs as a
> possibility, but there isn't a robust markup that readily works across
> all backends.

Yes, indeed.  

> On export the in-text citations are transformed to unique text blobs,
> e.g. uuids, and the document exported. The only important features of
> these blobs is that they do not get changed on export, and they are
> unique because we replace them later.
>
> The strings in the bibliography entry are "exported" to convert the
> org-markup to the output format. The in-text citations, expanded
> bibliography and style are sent to the citation processor, which outputs
> replacements and a formatted bibliography in the desired output format.
>
> Finally, you replace each uuid with the appropriate replacement, and
> insert the bibliography where it belongs. That should be the final
> document.

IIUC, the problem with this approach is that it will not work well when
the citation style is note-based rather than inline.  The main
motivation for going "back to Org" is that note-based styles require the
document structure to change as a result of citation processing: new
footnotes have to be inserted, and existing ones have to be renumbered.
That is relatively hard to do if the rest of the document is already in
the target format (except with LaTeX).  By doing citation processing
early in the export process and converting the results to Org, we can
rely on Org's footnote processing to handle this later in the export
process.

As far as I can see, if it weren't for note-based styles, this approach
would work fine.  (Indeed, it is pretty much what the existing org-cite
code does, except that the mapping between citations and their
replacements is done with Lisp data structures rather than via string
replacement in the output buffer.  I stopped work on that right about
the time I realized the existing approach wouldn't work very well with
note-based styles.)

But given the problem about nested formatting, going back to Org at the
level of text replacements doesn't work.  In other words: both of the
simple-minded approaches (process citations directly to text in the
target format, or process them to Org text, then let Org convert them to
the target format) face problems.

I think probably what we'll have to do to accommodate both note-based
styles and the possibility of nested formatting is to get the results of
citation processing in some unambiguous format like HTML or JSON, then
parse it, and then use the result to directly modify the parse tree for
the Org document before continuing the export process.  I can't see an
easier way...can anyone else?

Best,
Richard



Re: [O] More questions about CSL and org-mode

2015-12-06 Thread Richard Lawrence
Richard Lawrence  writes:

>> IIUC, the current aim is to get a citeproc that will do the following on
>> export:
>> 1. replace in-text citation syntax with org-formatted replacements
>> 2. Insert an org-formatted bibliography somewhere in the document
>> 3. proceed with org-to-something export, with built-in
>> exporters.
>
> That's basically my understanding too.  There is one snag with the
> "org-formatted replacement" plan, though, which I saw in a Zotero dev
> discussion yesterday.  

Here's the reference for that discussion, by the way:

https://groups.google.com/d/msg/zotero-dev/Bz_IenruxX4/24QWuyEIp_IJ

Best,
Richard

P.S.  John, thanks for your continued research on this.  I see that our
procrastination habits are on the same schedule. :)



Re: [O] More questions about CSL and org-mode

2015-12-06 Thread Richard Lawrence
Hi John,

John Kitchin  writes:

> Hi all,
>
> This is mostly for the people working on citations in org-mode.
>
> I have been reading about CSL more this weekend. IIRC, one of the
> reasons to develop the new citation syntax was to get the ability to
> have pre/post text in citations more conveniently than what is currently
> possible.

Yes, that is my understanding, too.

> I have not seen any possibility for this with CSL, however. Is my
> understanding correct? Is this a problem, or something partially handled
> by org-export and partially by a citeproc?

The CSL processors I've looked at support prefix and suffix text for
individual references within a citation.  See, for example, the
citeproc-js documentation:

http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#citation-data-object

prefix, suffix, and some other fields are supported.  pandoc-citeproc
supports the same set of fields.

However, my understanding is that neither citeproc-js nor
pandoc-citeproc support a BibLaTeX-style "common" prefix/suffix that
belongs to the citation as a whole, rather than the individual
references within it, as is available in the multi-cite commands.  We
currently have support for such common prefixes/suffixes in Org syntax. 

My solution to this in my org-citeproc wrapper for pandoc-citeproc is to
prepend the common prefix to the prefix for the first reference in a
citation, and append the common suffix to the last reference.  This is
not a great solution, because it is not really defined what kind of
punctuation (if any) should separate the common prefix from the first
item's prefix, and so on.  But I figured that was not an important issue
to address until we actually have people making use of common prefix and
suffix syntax who are not exporting to LaTeX...

> IIUC, the current aim is to get a citeproc that will do the following on
> export:
> 1. replace in-text citation syntax with org-formatted replacements
> 2. Insert an org-formatted bibliography somewhere in the document
> 3. proceed with org-to-something export, with built-in
> exporters.

That's basically my understanding too.  There is one snag with the
"org-formatted replacement" plan, though, which I saw in a Zotero dev
discussion yesterday.  CSL processing might result in multiple levels of
formatting, e.g. nested italics like

Something with an internal Title

and that won't translate very well back to Org syntax in general:

/Something with an internal /Title//

The suggestion was to just use HTML output, and then parse the HTML to
get a data structure that could be directly rendered into HTML, LaTeX,
etc., which support nested italics just fine.  I think we could do this,
though maybe there's a better solution.  That is, we can take HTML from
the citation processor and go directly to org-element objects, without
producing and re-parsing citations in Org format.

> The current contenders for a citeproc are Zotero and Pandoc.
>
> Has anyone looked at https://pypi.python.org/pypi/citeproc-py/
> or https://github.com/inukshuk/citeproc-ruby
>
> The ruby one looks pretty advanced.

I haven't looked at them closely.  My impression was that the Python
version was quite incomplete; and unfortunately, I don't know Ruby, so I
would be the wrong person to evaluate it (or write code for it).

Best,
Richard



[O] More questions about CSL and org-mode

2015-12-06 Thread John Kitchin
Hi all,

This is mostly for the people working on citations in org-mode.

I have been reading about CSL more this weekend. IIRC, one of the
reasons to develop the new citation syntax was to get the ability to
have pre/post text in citations more conveniently than what is currently
possible.

I have not seen any possibility for this with CSL, however. Is my
understanding correct? Is this a problem, or something partially handled
by org-export and partially by a citeproc?

IIUC, the current aim is to get a citeproc that will do the following on
export:
1. replace in-text citation syntax with org-formatted replacements
2. Insert an org-formatted bibliography somewhere in the document
3. proceed with org-to-something export, with built-in
exporters.

The current contenders for a citeproc are Zotero and Pandoc.

Has anyone looked at https://pypi.python.org/pypi/citeproc-py/
or https://github.com/inukshuk/citeproc-ruby

The ruby one looks pretty advanced.






--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



Re: [O] more helm-bibtex/org-ref questions

2015-06-27 Thread Ramon Diaz-Uriarte
Dear John,


On Fri, 26-06-2015, at 22:58, John Kitchin jkitc...@andrew.cmu.edu wrote:
 You could have multiple file fields I suppose, and adapt [1] to give you
 a choice of which one to open.

That is an intriguing suggestion. I'll try to play with it.


 Personally, I have one pdf per bibtex entry, named by the key of the
 entry, in a directory called bibtex-pdfs somewhere defined by
 org-ref-pdf-directory. There are ~1300 pdfs in there now. I always
 access them through helm bibtex.

 admittedly, I don't have the SI or other stuff around usually. I don't
 use bibtex to keep track of the directories where I write manuscripts
 either.


I don't use bibtex to keep track of the dirs where I write manuscripts
either, but SI et al I often do want to store. The SI more and more as time
goes by, given the current policy of many journals of moving the methods
details to SI ---I could merge PDFs into a single one, but that is another
step.


 You could always make links to these other things in the associated
 notes entry. or put org-links in a bibtex field, and then you can open
 them with C-c o (if you setup links to work everywhere). That way,
 opening the pdf is easy, and opening the other things is just opening
 the entry and running the link open command.

That is a great suggestion. However, I just realized that I would not be
able to then open any of the links in an Android device (where I do part of
my reading) or in, say, JabRef (I'd need to have a script run to reformat
them, but then propagating changes both ways starts getting very
cumbersome).



I need to think some more about this. Thanks for your suggestions.


Best,

R.


 Ramon Diaz-Uriarte writes:

 Dear All,

 (I am not sure this is the appropriate place, but this is neither a bug
 report nor an feature request about helm-bibtex or org-ref, but a question
 from ignorance and I am learning quite a bit from the other helm-bibtex
 questions).


 How do people deal with multiple files that are logically associated to an
 entry?


 I've been used to keeping the main file, supplementary materials,
 associated code, etc, in a directory per entry. This kind of modus operandi
 is something I adopted (fell into?)  easily with Zotero and Mendeley. But I
 am not sure that this is the best way to proceed.


 If I end up with multiple files per directory, helm-bibtex-find-pdf[1]
 cannot know which one I want to open. I could keep the main file in the
 general directory, so it is found directly by helm-bibtex-find-pdf and
 specify other files (of secondary usage) in the file field (and maybe
 open them via ebib when/if needed)?  But this does not seem
 elegant. Another is to have an entry per file, with unique key, but this
 does not seem right.



 Thanks,

 R.


 [1] Thanks to Titus' help
 (https://github.com/tmalsburg/helm-bibtex/issues/53), opening a PDF that is
 given in the file field with the directory name is now within my reach.

-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz



Re: [O] more helm-bibtex/org-ref questions

2015-06-26 Thread John Kitchin
You could have multiple file fields I suppose, and adapt [1] to give you
a choice of which one to open.

Personally, I have one pdf per bibtex entry, named by the key of the
entry, in a directory called bibtex-pdfs somewhere defined by
org-ref-pdf-directory. There are ~1300 pdfs in there now. I always
access them through helm bibtex.

admittedly, I don't have the SI or other stuff around usually. I don't
use bibtex to keep track of the directories where I write manuscripts
either.

You could always make links to these other things in the associated
notes entry. or put org-links in a bibtex field, and then you can open
them with C-c o (if you setup links to work everywhere). That way,
opening the pdf is easy, and opening the other things is just opening
the entry and running the link open command.

Ramon Diaz-Uriarte writes:

 Dear All,

 (I am not sure this is the appropriate place, but this is neither a bug
 report nor an feature request about helm-bibtex or org-ref, but a question
 from ignorance and I am learning quite a bit from the other helm-bibtex
 questions).


 How do people deal with multiple files that are logically associated to an
 entry?


 I've been used to keeping the main file, supplementary materials,
 associated code, etc, in a directory per entry. This kind of modus operandi
 is something I adopted (fell into?)  easily with Zotero and Mendeley. But I
 am not sure that this is the best way to proceed.


 If I end up with multiple files per directory, helm-bibtex-find-pdf[1]
 cannot know which one I want to open. I could keep the main file in the
 general directory, so it is found directly by helm-bibtex-find-pdf and
 specify other files (of secondary usage) in the file field (and maybe
 open them via ebib when/if needed)?  But this does not seem
 elegant. Another is to have an entry per file, with unique key, but this
 does not seem right.



 Thanks,

 R.


 [1] Thanks to Titus' help
 (https://github.com/tmalsburg/helm-bibtex/issues/53), opening a PDF that is
 given in the file field with the directory name is now within my reach.

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



[O] more helm-bibtex/org-ref questions

2015-06-26 Thread Ramon Diaz-Uriarte
Dear All,

(I am not sure this is the appropriate place, but this is neither a bug
report nor an feature request about helm-bibtex or org-ref, but a question
from ignorance and I am learning quite a bit from the other helm-bibtex
questions).


How do people deal with multiple files that are logically associated to an
entry?


I've been used to keeping the main file, supplementary materials,
associated code, etc, in a directory per entry. This kind of modus operandi
is something I adopted (fell into?)  easily with Zotero and Mendeley. But I
am not sure that this is the best way to proceed.


If I end up with multiple files per directory, helm-bibtex-find-pdf[1]
cannot know which one I want to open. I could keep the main file in the
general directory, so it is found directly by helm-bibtex-find-pdf and
specify other files (of secondary usage) in the file field (and maybe
open them via ebib when/if needed)?  But this does not seem
elegant. Another is to have an entry per file, with unique key, but this
does not seem right.



Thanks,

R.

 
[1] Thanks to Titus' help
(https://github.com/tmalsburg/helm-bibtex/issues/53), opening a PDF that is
given in the file field with the directory name is now within my reach.

-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz



[O] More export filter examples out there?

2015-03-17 Thread Allen S. Rout

I'm trying to accomplish a custom export task which I'd hoped to be
pretty simple:  something like:


In each status section, only export the first child headline.


After several dumb ideas, I decided that doing it with a filter was
probably the Right Place.  I built a filter intended to be used on

:filter-parse-tree

and attempted to express:

If you're parent is a headline
and your parent's title is 'Status'
and you're not the first of your siblings

then don't be included.  I've added my malfunctioning filter below,to
clearly display my thinking.

I don't seem to be able to get the title as a string.  org-export-data
seems to expect a different 'info' than the 'info' present at filter
time.  I get complaints about

org-export-data: Wrong type argument: hash-table-p, nil

if I uncomment the attempt to string compare the title.


I'm finding my experience with XSLT to be a handicap; I bring
expectations to the table that are misguided.  Is there a pretty-printer
or other dump for the export parse tree?   The dump I sometimes get in
*Messages* is not all that readable.

Should I be thinking of this as a parse-table operation, or should I be
reasoning about it from :filter-headline?


More generally, anyone got some art for some similar reconstruction
they've done, which they might like to share?


- Allen S. Rout




(defun ox-asr-only-first-status  ( tree backend info )
   Arrange that, under headlines marked 'Status', only the first of
them is included.


  ( org-element-map tree (remq 'item org-element-all-elements)

( lambda (e)
  ( let* ( ( parent   ( org-element-property :parent e) )
   ( first-sib( car (org-element-contents parent )))
   ( parent-type  ( org-element-type parent ))
   ( parent-title ( org-element-property :title e))
;  ( pt-string( org-export-data parent-title info ))
   )

(if (and
 ( eq parent-type 'headline )
 ( not (eq e first-sib ))
;( string= (org-export-data parent-title) Status)
 )
( org-element-set-contents e  -- parent-title ---  
(org-element-contents e))
  )

)
  )

)


  tree
  )





Re: [O] More export filter examples out there?

2015-03-17 Thread Nicolas Goaziou
Hello,

Allen S. Rout a...@ufl.edu writes:

 I'm trying to accomplish a custom export task which I'd hoped to be
 pretty simple:  something like:


 In each status section, only export the first child headline.


 After several dumb ideas, I decided that doing it with a filter was
 probably the Right Place.  I built a filter intended to be used on

 :filter-parse-tree

 and attempted to express:

 If you're parent is a headline
 and your parent's title is 'Status'
 and you're not the first of your siblings

 then don't be included.  I've added my malfunctioning filter below,to
 clearly display my thinking.

Untested:

  (defun ox-asr-only-first-status (tree backend info)
(org-element-map tree 'headline
  (lambda (h)
(let ((parent (org-export-get-parent-headline h)))
  (when (and parent
 (string= (org-element-property :raw-value parent) Status)
 (not (org-export-first-sibling-p h info)))
(org-element-extract-element h)
tree)

 I don't seem to be able to get the title as a string.

Use `:raw-value' property.

 org-export-data seems to expect a different 'info' than the 'info'
 present at filter time. I get complaints about

 org-export-data: Wrong type argument: hash-table-p, nil

 if I uncomment the attempt to string compare the title.

Indeed. One cannot use `org-export-data' during parse tree filtering.
Export output really depends on the tree and the options, which are
being re-arranged.


Regards,

-- 
Nicolas Goaziou



Re: [O] More helm awesomeness

2015-01-19 Thread John Kitchin
You can do something like this to get just the TODO headlines in the
current buffer. If you make the helm-todo-candidates map over all the
files in (org-agenda-files) you can make it give all the TODO
headings. You can change the match criteria in org-map-entries to be
more selective.

#+BEGIN_SRC emacs-lisp :results raw
(defun helm-todo-candidates ()
  (let ((results '()))
(org-map-entries
 (lambda ()
   (add-to-list 'results
(cons
 (concat (make-string (nth 1 (org-heading-components)) ?*)
  TODO 
 (nth 4 (org-heading-components)))
 (point-marker
 TODO=\TODO\)
results))
#+END_SRC

#+RESULTS:
((** post it . #marker at 977 in blog.org) (** work it out . #marker at 941 
in blog.org))

Now to run helm, there is a subtle point. We need to map the current buffer 
/before/ running helm, otherwise we will map an empty helm buffer.

#+BEGIN_SRC emacs-lisp
(defun helm-todo ()
  Helm interface to headlines with TODO status in current buffer.
  (interactive)
  (let ((candidates (helm-todo-candidates)))
(setq helm-todo-source '((name . TODO headlines)
 (candidates . candidates)
 (action . ((open . goto-char)
(helm :sources '(helm-todo-source

(helm-todo)
Simon Thum writes:

 Hi all,

 I recently updated my helm install so it includes
 helm-org-agenda-headings which is just AWESOME (to me at least). A bit
 like org-goto but across all agenda files at once, with goto, refile,
 linking built in. If you haven't tried it, I definitely recommend to do so.


 Yet I'm missing a few things so far, I would like to have different
 datasources differentiated by tags, in particular the ARCHIVE tag, and
 the infamous FILETAGS so I cannot just regex my way through as the
 current approach does.

 This requires making more use of org-ode when filling helm's buffers. My
 elisp isn't great but I might be able to get there if the approach is sane.

 Any pointers are welcome! If you might help me please read on.

 I would like to ask what would be the best approach for better utilising
 org infrastructure so I may have separate helm sources for
 live/archived, private/work, the clocking history, stuff like that.

 The helm-org definition looks deceptively simple:

 https://github.com/emacs-helm/helm/blob/master/helm-org.el

 (defun helm-org-agenda-files-headings ()
 (interactive)
 (helm :sources (helm-source-org-headings-for-files (org-agenda-files))
 :candidate-number-limit 9
 :buffer *helm org headings*))


 FWICT, in effect helm-org is chewing itself through the buffers:

 (defun helm-get-org-candidates-in-file (filename min-depth max-depth
 optional fontify)
 (with-current-buffer (find-file-noselect filename)
 (and fontify (jit-lock-fontify-now))
 (let ((match-fn (if fontify 'match-string 'match-string-no-properties)))
 (save-excursion
 (goto-char (point-min))
 (cl-loop while (re-search-forward org-complex-heading-regexp nil t)
 if (let ((num-stars (length (match-string-no-properties 1
 (and (= num-stars min-depth) (= num-stars max-depth)))
 collect `(,(funcall match-fn 0) . ,(point-marker)))

 I don't really get what it does but I have a hunch that org-element or
 other org-mode functions could be used to achieve the same with more
 precision. That's what I would need to do. FWIW I'd be happy to take a
 performance hit.

 Thanks in advance,

 Simon

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



Re: [O] More helm awesomeness

2015-01-19 Thread Simon Thum

Hi John,

thank you for the fast response! That's more than I had hoped for, I'm 
sure I'll get through now. I'll report back when something tangible is 
there.


Cheers,

Simon

On 01/19/2015 04:57 PM, John Kitchin wrote:

You can do something like this to get just the TODO headlines in the
current buffer. If you make the helm-todo-candidates map over all the
files in (org-agenda-files) you can make it give all the TODO
headings. You can change the match criteria in org-map-entries to be
more selective.

#+BEGIN_SRC emacs-lisp :results raw
(defun helm-todo-candidates ()
   (let ((results '()))
 (org-map-entries
  (lambda ()
(add-to-list 'results
 (cons
  (concat (make-string (nth 1 (org-heading-components)) ?*)
   TODO 
  (nth 4 (org-heading-components)))
  (point-marker
  TODO=\TODO\)
 results))
#+END_SRC

#+RESULTS:
((** post it . #marker at 977 in blog.org) (** work it out . #marker at 941 in 
blog.org))

Now to run helm, there is a subtle point. We need to map the current buffer 
/before/ running helm, otherwise we will map an empty helm buffer.

#+BEGIN_SRC emacs-lisp
(defun helm-todo ()
   Helm interface to headlines with TODO status in current buffer.
   (interactive)
   (let ((candidates (helm-todo-candidates)))
 (setq helm-todo-source '((name . TODO headlines)
  (candidates . candidates)
  (action . ((open . goto-char)
 (helm :sources '(helm-todo-source

(helm-todo)
Simon Thum writes:


Hi all,

I recently updated my helm install so it includes
helm-org-agenda-headings which is just AWESOME (to me at least). A bit
like org-goto but across all agenda files at once, with goto, refile,
linking built in. If you haven't tried it, I definitely recommend to do so.


Yet I'm missing a few things so far, I would like to have different
datasources differentiated by tags, in particular the ARCHIVE tag, and
the infamous FILETAGS so I cannot just regex my way through as the
current approach does.

This requires making more use of org-ode when filling helm's buffers. My
elisp isn't great but I might be able to get there if the approach is sane.

Any pointers are welcome! If you might help me please read on.

I would like to ask what would be the best approach for better utilising
org infrastructure so I may have separate helm sources for
live/archived, private/work, the clocking history, stuff like that.

The helm-org definition looks deceptively simple:

https://github.com/emacs-helm/helm/blob/master/helm-org.el

(defun helm-org-agenda-files-headings ()
(interactive)
(helm :sources (helm-source-org-headings-for-files (org-agenda-files))
:candidate-number-limit 9
:buffer *helm org headings*))


FWICT, in effect helm-org is chewing itself through the buffers:

(defun helm-get-org-candidates-in-file (filename min-depth max-depth
optional fontify)
(with-current-buffer (find-file-noselect filename)
(and fontify (jit-lock-fontify-now))
(let ((match-fn (if fontify 'match-string 'match-string-no-properties)))
(save-excursion
(goto-char (point-min))
(cl-loop while (re-search-forward org-complex-heading-regexp nil t)
if (let ((num-stars (length (match-string-no-properties 1
(and (= num-stars min-depth) (= num-stars max-depth)))
collect `(,(funcall match-fn 0) . ,(point-marker)))

I don't really get what it does but I have a hunch that org-element or
other org-mode functions could be used to achieve the same with more
precision. That's what I would need to do. FWIW I'd be happy to take a
performance hit.

Thanks in advance,

Simon


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu





Re: [O] More helm awesomeness

2015-01-19 Thread John Kitchin
Here is a more advanced function that works on your agenda files: You
run the second one:
M-x helm-query-agenda

and enter your search query in org syntax, e.g. TODO=PREPARATION will
give you a helm menu of headlines with that TODO state.

I am not that sophisticated a user of org queries like this, so I can't
vouch it works for all of them ;)

#+BEGIN_SRC emacs-lisp
(defun helm-agenda-candidates (query)
  (let ((results '()))
(mapc (lambda (f)
  (with-current-buffer (find-file-noselect f)
(org-map-entries
 (lambda ()
   (add-to-list 'results
(cons
 (concat
  (file-name-nondirectory f)  | 
  (make-string (nth 1 (org-heading-components)) ?*)
   
  (org-get-heading))
 (point-marker
 query))) (org-agenda-files))
results))


(defun helm-query-agenda (query)
  Helm interface to headlines with TODO status in current buffer.
  (interactive sQuery: )
  (let ((candidates (helm-agenda-candidates query)))
(helm :sources '(((name . TODO headlines)
  (candidates . candidates)
  (action . ((open . (lambda (m)
 (switch-to-buffer (marker-buffer 
m))
 (goto-char m)
 (show-children))
#+END_SRC


Simon Thum writes:

 Hi John,

 thank you for the fast response! That's more than I had hoped for, I'm
 sure I'll get through now. I'll report back when something tangible is
 there.

 Cheers,

 Simon

 On 01/19/2015 04:57 PM, John Kitchin wrote:
 You can do something like this to get just the TODO headlines in the
 current buffer. If you make the helm-todo-candidates map over all the
 files in (org-agenda-files) you can make it give all the TODO
 headings. You can change the match criteria in org-map-entries to be
 more selective.

 #+BEGIN_SRC emacs-lisp :results raw
 (defun helm-todo-candidates ()
(let ((results '()))
  (org-map-entries
   (lambda ()
 (add-to-list 'results
  (cons
   (concat (make-string (nth 1 (org-heading-components)) 
 ?*)
TODO 
   (nth 4 (org-heading-components)))
   (point-marker
   TODO=\TODO\)
  results))
 #+END_SRC

 #+RESULTS:
 ((** post it . #marker at 977 in blog.org) (** work it out . #marker at 
 941 in blog.org))

 Now to run helm, there is a subtle point. We need to map the current buffer 
 /before/ running helm, otherwise we will map an empty helm buffer.

 #+BEGIN_SRC emacs-lisp
 (defun helm-todo ()
Helm interface to headlines with TODO status in current buffer.
(interactive)
(let ((candidates (helm-todo-candidates)))
  (setq helm-todo-source '((name . TODO headlines)
   (candidates . candidates)
   (action . ((open . goto-char)
  (helm :sources '(helm-todo-source

 (helm-todo)
 Simon Thum writes:

 Hi all,

 I recently updated my helm install so it includes
 helm-org-agenda-headings which is just AWESOME (to me at least). A bit
 like org-goto but across all agenda files at once, with goto, refile,
 linking built in. If you haven't tried it, I definitely recommend to do so.


 Yet I'm missing a few things so far, I would like to have different
 datasources differentiated by tags, in particular the ARCHIVE tag, and
 the infamous FILETAGS so I cannot just regex my way through as the
 current approach does.

 This requires making more use of org-ode when filling helm's buffers. My
 elisp isn't great but I might be able to get there if the approach is sane.

 Any pointers are welcome! If you might help me please read on.

 I would like to ask what would be the best approach for better utilising
 org infrastructure so I may have separate helm sources for
 live/archived, private/work, the clocking history, stuff like that.

 The helm-org definition looks deceptively simple:

 https://github.com/emacs-helm/helm/blob/master/helm-org.el

 (defun helm-org-agenda-files-headings ()
 (interactive)
 (helm :sources (helm-source-org-headings-for-files (org-agenda-files))
 :candidate-number-limit 9
 :buffer *helm org headings*))


 FWICT, in effect helm-org is chewing itself through the buffers:

 (defun helm-get-org-candidates-in-file (filename min-depth max-depth
 optional fontify)
 (with-current-buffer (find-file-noselect filename)
 (and fontify (jit-lock-fontify-now))
 (let ((match-fn (if fontify 'match-string 'match-string-no-properties)))
 (save-excursion
 (goto-char (point-min))
 (cl-loop while (re-search-forward org-complex-heading-regexp nil t)
 if (let ((num-stars (length (match-string-no-properties 1
 (and (= num-stars min-depth) (= num-stars max-depth)))
 collect 

[O] More helm awesomeness

2015-01-18 Thread Simon Thum

Hi all,

I recently updated my helm install so it includes 
helm-org-agenda-headings which is just AWESOME (to me at least). A bit 
like org-goto but across all agenda files at once, with goto, refile, 
linking built in. If you haven't tried it, I definitely recommend to do so.



Yet I'm missing a few things so far, I would like to have different 
datasources differentiated by tags, in particular the ARCHIVE tag, and 
the infamous FILETAGS so I cannot just regex my way through as the 
current approach does.


This requires making more use of org-ode when filling helm's buffers. My 
elisp isn't great but I might be able to get there if the approach is sane.


Any pointers are welcome! If you might help me please read on.

I would like to ask what would be the best approach for better utilising 
org infrastructure so I may have separate helm sources for 
live/archived, private/work, the clocking history, stuff like that.


The helm-org definition looks deceptively simple:

https://github.com/emacs-helm/helm/blob/master/helm-org.el

(defun helm-org-agenda-files-headings ()
(interactive)
(helm :sources (helm-source-org-headings-for-files (org-agenda-files))
:candidate-number-limit 9
:buffer *helm org headings*))


FWICT, in effect helm-org is chewing itself through the buffers:

(defun helm-get-org-candidates-in-file (filename min-depth max-depth
optional fontify)
(with-current-buffer (find-file-noselect filename)
(and fontify (jit-lock-fontify-now))
(let ((match-fn (if fontify 'match-string 'match-string-no-properties)))
(save-excursion
(goto-char (point-min))
(cl-loop while (re-search-forward org-complex-heading-regexp nil t)
if (let ((num-stars (length (match-string-no-properties 1
(and (= num-stars min-depth) (= num-stars max-depth)))
collect `(,(funcall match-fn 0) . ,(point-marker)))

I don't really get what it does but I have a hunch that org-element or 
other org-mode functions could be used to achieve the same with more 
precision. That's what I would need to do. FWIW I'd be happy to take a 
performance hit.


Thanks in advance,

Simon



[O] More detail in the agenda logbook?

2014-08-06 Thread hymie!
Hi again.

So I've got a few repetitive tasks, for example

* TODO machine backups
** TODO machine 1
*** TODO create backup
*** TODO copy backup to DVD
** TODO machine 2
*** TODO create backup
*** TODO copy backup to DVD
** TODO machine 3
*** TODO create backup
*** TODO copy backup to DVD
** TODO machine 4
*** TODO create backup
*** TODO copy backup to DVD

It's the same set of tasks for each machine.

When I complete these tasks and look at the Agenda Logbook, I see
this:

  State: (DONE) DONE create backup
  State: (DONE) DONE create backup
  State: (DONE) DONE create backup
  State: (DONE) DONE create backup
  State: (DONE) DONE copy backup to DVD
  State: (DONE) DONE copy backup to DVD
  State: (DONE) DONE copy backup to DVD
  State: (DONE) DONE copy backup to DVD

I'd really like to see something along the lines of
  State: (DONE) DONE machine backups / machine 1 / create backup
  State: (DONE) DONE machine backups / machine 2 / create backup
  State: (DONE) DONE machine backups / machine 3 / create backup
  State: (DONE) DONE machine backups / machine 4 / create backup

or

  State: (DONE) DONE machine backups 
 machine 1 
 create backup
  State: (DONE) DONE machine backups 
 machine 2 
 create backup
  State: (DONE) DONE machine backups 
 machine 3 
 create backup
  State: (DONE) DONE machine backups 
 machine 4 
 create backup

Is this possible?

--hymie!http://lactose.homelinux.net/~hymiehy...@lactose.homelinux.net




[O] more from org-babel newbie

2014-04-28 Thread Steven Arntson
I'm trying to get going with org-babel and lilypond music markup. I have
the system basically functioning, but there's an elementary issue I
can't seem to wrap my brain around.

The reason I'm excited to use org with lilypond files is the foldable
headers *, **, *** etc, as well as drawers and tables. However, that's
available only in an org-mode buffer, and I'm also wanting to use
lilypond-mode, which gives excellent colored markup and indentation. How
do I get the advantages of both? Or is that not even what I should be
after? I may be fundamentally missing what's potentially useful about
all of this for my musical use case!

Thank you,
Steven Arntson




Re: [O] more from org-babel newbie

2014-04-28 Thread Thomas S. Dye
Aloha Steven,

Steven Arntson ste...@stevenarntson.com writes:

 The reason I'm excited to use org with lilypond files is the foldable
 headers *, **, *** etc, as well as drawers and tables. However, that's
 available only in an org-mode buffer, and I'm also wanting to use
 lilypond-mode, which gives excellent colored markup and indentation. How
 do I get the advantages of both? Or is that not even what I should be
 after? I may be fundamentally missing what's potentially useful about
 all of this for my musical use case!

I haven't used babel for lilypond, but the usual way to edit a source
code block in the emacs mode for the language is to press C-c ' in the
source code block.

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com



Re: [O] more from org-babel newbie

2014-04-28 Thread Steven Arntson
t...@tsdye.com (Thomas S. Dye) writes:

 Aloha Steven,

 Steven Arntson ste...@stevenarntson.com writes:

 The reason I'm excited to use org with lilypond files is the foldable
 headers *, **, *** etc, as well as drawers and tables. However, that's
 available only in an org-mode buffer, and I'm also wanting to use
 lilypond-mode, which gives excellent colored markup and indentation. How
 do I get the advantages of both? Or is that not even what I should be
 after? I may be fundamentally missing what's potentially useful about
 all of this for my musical use case!

 I haven't used babel for lilypond, but the usual way to edit a source
 code block in the emacs mode for the language is to press C-c ' in the
 source code block.

 hth,
 Tom

This is embarrassing ... I'd tried that and hadn't managed to get it to
work, and now I realize I was using C-c ` and not C-c '. The devil is in
the details.

I'm still a little mystified about using org markup in the context of
the lilypond file, but maybe now I can do a little more experimenting.

Thank you!
Steven




Re: [O] more from org-babel newbie

2014-04-28 Thread Thomas S. Dye
Steven Arntson ste...@stevenarntson.com writes:

 I'm still a little mystified about using org markup in the context of
 the lilypond file, but maybe now I can do a little more experimenting.

Have you seen this?

http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html

There are some example org-mode files there that might help you on your
way. 

hth,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com



[O] --more--?

2013-12-24 Thread Sharon Kimble
I'm publishing a rather long org-mode document and want it to break
after the first paragraph  so that you have to explicitly click the
document title to get it all to show. In WordPress its done with
'--more--' but what is it done with in org-mode please? I've been
looking at the org-mode 'org manual 8.2.3c' but cant find it. Is there
such a thing in org-mode please?

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
efever = http://www.efever.blogspot.com/
efever = http://sharon04.livejournal.com/
my git repo = https://bitbucket.org/boudiccas/dots
Debian testing, Fluxbox 1.3.5, LibreOffice 4.1.3.2
Registered Linux user 561944


signature.asc
Description: PGP signature


Re: [O] --more--?

2013-12-24 Thread Puneeth Chaganti
On Tue, Dec 24, 2013 at 6:24 PM, Sharon Kimble boudic...@talktalk.net wrote:
 I'm publishing a rather long org-mode document and want it to break
 after the first paragraph  so that you have to explicitly click the
 document title to get it all to show. In WordPress its done with
 '--more--' but what is it done with in org-mode please? I've been
 looking at the org-mode 'org manual 8.2.3c' but cant find it. Is there
 such a thing in org-mode please?


You just put it in as raw html.  See the last item in org2blog's FAQ [1].

[1] - https://github.com/punchagan/org2blog#faq



Re: [O] --more--?

2013-12-24 Thread Sharon Kimble
On Tue, 24 Dec 2013 18:28:49 +0530
Puneeth Chaganti puncha...@gmail.com wrote:

 On Tue, Dec 24, 2013 at 6:24 PM, Sharon Kimble
 boudic...@talktalk.net wrote:
  I'm publishing a rather long org-mode document and want it to break
  after the first paragraph  so that you have to explicitly click the
  document title to get it all to show. In WordPress its done with
  '--more--' but what is it done with in org-mode please? I've been
  looking at the org-mode 'org manual 8.2.3c' but cant find it. Is
  there such a thing in org-mode please?
 
 
 You just put it in as raw html.  See the last item in org2blog's FAQ
 [1].
 
 [1] - https://github.com/punchagan/org2blog#faq

Thanks, its working brilliantly now, so much quicker than using
wordpresses own editor! :)

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
efever = http://www.efever.blogspot.com/
efever = http://sharon04.livejournal.com/
my git repo = https://bitbucket.org/boudiccas/dots
Debian testing, Fluxbox 1.3.5, LibreOffice 4.1.3.2
Registered Linux user 561944


signature.asc
Description: PGP signature


[O] More koma confusion: subject option

2013-11-24 Thread James Harkins
According to [1], #+OPTIONS: subject:nil should suppress printing the 
#+TITLE at the top of the letter. It seems that the previous bug prevents 
the expected line \KOMAoption{subject}{untitled} from being generated.


Okay... so, what if I set #+OPTIONS: subject:untitled? Then I get 
something like:


\KOMAoption{subject}{untitled}
\setkomavar{subject}{The title}

.. and LaTeX prints The title in bold, above the salutation.

If I remove the #+TITLE line (or comment it out), then the exporter assumes 
that the title should be the file name, minus the .org extension. This 
conflicts with [1], which claims that the default subject is an empty 
string.


I can suppress the subject by providing an empty #+TITLE line, but the 
documentation suggests that this should not be necessary.


??

hjh

[1] http://orgmode.org/worg/exporters/koma-letter-export.html



Re: [O] More koma confusion: subject option

2013-11-24 Thread Rasmus
James Harkins jamshar...@gmail.com writes:

 According to [1], #+OPTIONS: subject:nil should suppress printing
 the #+TITLE at the top of the letter. It seems that the previous bug
 prevents the expected line \KOMAoption{subject}{untitled} from being
 generated.

I cannot reproduce.

 Okay... so, what if I set #+OPTIONS: subject:untitled? Then I get
 something like:

 \KOMAoption{subject}{untitled}
 \setkomavar{subject}{The title}

As expected...

 .. and LaTeX prints The title in bold, above the salutation.

 If I remove the #+TITLE line (or comment it out), then the exporter
 assumes that the title should be the file name, minus the .org
 extension. This conflicts with [1], which claims that the default
 subject is an empty string.

No.  Title in inherited from ox-latex.el and thus works exactly as in
the LaTeX backend.  I don't know if I like this, as both subject and
title is defined in scrlttr2 (the latter in inaccessible from
ox-koma-letter).

Untitled is defined in KOMA-script and you didn't appreciate it's
meaning.  Try to compare subject:titeled to untiteled.  Hint:
(un)titled governs whether it says subject: mysubject or
mysubject.

I think you want to /suppress/ subject-generation.  This is archived
with #+OPTIONS: subject:nil.

Here's an example working from emacs -q and git-emacs:

#+TITLE: A simple letter
#+CLOSING: Yours truly,
#+SIGNATURE: Jane
#+OPTIONS: subject:nil

* Pre  :noexport:
#+BEGIN_SRC emacs-lisp
(require 'ox-koma-letter)
(org-koma-letter-plug-into-ox)
(add-to-list 'org-latex-packages-alist '(AUTO babel nil))
#+END_SRC

* opening
compare the above with =subject:nil=

* FROM :from:
Some Street 1

* TO :to:
John Doe

–Rasmus

-- 
Don't panic!!!




Re: [O] More generic taskjuggler export proposal

2013-04-14 Thread Suvayu Ali
Hi Christian,

On Fri, Apr 12, 2013 at 03:08:17PM +0200, Christian Egli wrote:
 Buddy Butterfly buddy.butter...@web.de writes:
  Here I would suggest that one can place this data inbetween
 
   #+BEGIN_TASKJUGGLER
   #+END_TASKJUGGLER
 
 This is something I'd like to add support for. I just never got around
 to look at how this could be implemented. It has some implications as
 you could destroy your otherwise valid tjp file. But it might cover some
 of your use cases above. Do you know how this could be done in the new
 exporter?

I believe you can use the :export-block property when defining the
backend to specify blocks.

Quoting from the docstring of org-export-define-backend:

  :export-block

String, or list of strings, representing block names that
will not be parsed.  This is used to specify blocks that will
contain raw code specific to the back-end.  These blocks
still have to be handled by the relative `export-block' type
translator.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] More generic taskjuggler export proposal

2013-04-12 Thread Christian Egli
Hi Buddy

Buddy Butterfly buddy.butter...@web.de writes:

 I would like propose the following for taskjuggler export
 as base for a discussion to change export functionality.

Thanks for your detailed proposal. It's been a few years since I wrote
the taskjuggler exporter and I don't remember all the design decisions.
Your idea with the prefix to the attributes is an interesting one.

However, the fundamental problem here is that IMHO there is no
one-to-one mapping between all the concepts in taskjuggler and org-mode.
Fundamentally taskjuggler is a system to plan and track a multi-resource
project. I see org-mode more geared towards planing and tracking a
single user. Taskjuggler has the concept of scenarios where you can
compare a plan against another plan or an actual execution (based on
reported effort). This might be doable in org-mode but is not really a
natural thing to do.

So in essence what I'm trying to say is that the goal behind the
taskjuggler exporter was never to give you a complete taskjuggler
development environment. For that you are probably better of just
editing the tjp files directly. Instead the goal was to let the user
take their normal org-mode files and have them export to taskjuggler
with minimal changes (i.e. mark the tasks, efforts and the resources).

The same holds for the dependency system. As far as I remember it was an
explicit decision not to support the taskjuggler dependency system and
use the one provided by org-mod instead. I think taskjuggler's
dependency system is very low level. The one provided by org-mode fit my
use cases (for the occasional dependency) much better (and have support
for higher level concepts such as the ORDERED or previous-sibling
attribute).

  The dependency between tasks is one thing that should be supported by org.
  I do not know what would be the best solution here. Maybe we could get
  a completion list for the values when adding :tj_depends: properties.

I don't quite understand this part of your message. As I said above I
think the support for dependencies in the taskjuggler is IMHO quite nice
:-).

 Here I would suggest that one can place this data inbetween

  #+BEGIN_TASKJUGGLER
  #+END_TASKJUGGLER

This is something I'd like to add support for. I just never got around
to look at how this could be implemented. It has some implications as
you could destroy your otherwise valid tjp file. But it might cover some
of your use cases above. Do you know how this could be done in the new
exporter?

 I still would like to discuss the organisation with multiple projects.
 What do you think about it?

Are you referring to the problem of handling multiple projects and
similar resources? I have never done this. How do you do it in plain
taskjuggler?

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland




[O] More generic taskjuggler export proposal

2013-04-03 Thread Buddy Butterfly
Hi,

I would like propose the following for taskjuggler export
as base for a discussion to change export functionality.
Here I will refer to the example project of taskjuggler 3.

Pre-requesites:
- Functionality of tj should be kept in tj as much as possible
- org export should be as generic as possible such that changes
  in tj will not impact org.

Suggestions:
- There should be configurable global taskjuggler prefix to define
  what shoudl be exported. Here we will take tj_ as an example.

- tj elements of the form
  : keyword id name { attributes }
  should be implemented as tagged tasks (like already done for resources
and project).
  The org tag should be prefixed by the tj prefix and the tag name
should automatically
  be exported as the keyword of tj. Org task should go into tj name
and the org
  property tj_id should go into id.

  The attributes should be org properties prefixed by the prefix (here
tj_).
  
  Example for the project tag:

  The tj example project lists the following project keyword header:

  project your_project_id Your Project Title  2011-11-11-0:00--0500 +4m {
timezone America/New_York
timeformat %Y-%m-%d
numberformat -  , . 1
currencyformat ( ) , . 0
now 2011-12-24
currency USD

# You can define multiple scenarios here if you need them.
#scenario plan Plan {
#  scenario actual Actual
#}

# You can define your own attributes for tasks and resources. This
# is handy to capture additonal information about the project that
# is not directly impacting the project schedule but you like to
# keep in one place.
#extend task {
#  reference spec Link to Wiki page
#}
#extend resource {
#  text Phone Phone
#}
  }

  This would be written in org like

  * Your Project Title :tj_project:
:PROPERTIES:
:tj_id: your_project_id
:tj_timezone: America/New_York
:tj_timeformat: %Y-%m-%d
:tj_numberformat:  -  , . 1
:tj_currencyformat: ( ) , . 0
:tj_now: 2011-12-24
:tj_currency: USD
:END:

* Plan   :tj_scenario:
  :PROPERTIES:
  :tj_scenario: actual Actual
  :END:

* task   :tj_extend:
  :PROPERTIES:
  :tj_reference: spec Link to Wiki page
  :END:

* resource   :tj_extend:
  :PROPERTIES:
  :tj_text: Phone Phone
  :END:

  As we can see, org can export everything in a generic way with mainly
stripping
  the prefix tj_ from the tags and properties and export as is to
taskjuggler.
  
  This also maps to the well known resource mapping:

  # This is a set of example resources.
  resource r1 Resource 1
  resource t1 Team 1 {
managers r1
resource r2 Resource 2
resource r3 Resource 3
  }

  # This is a resource that does not do any work.
  resource s1 System 1 {
efficiency 0.0
rate 600.0
  }

  Would be written in org-mode like:

  * Resource 1 :tj_resource:
:PROPERTIES:
:tj_id: r1
:END:

  * Team 1 :tj_resource:
:PROPERTIES:
:tj_id: t1
:tj_managers: r1
:END:
   
* Resource 2
  :PROPERTIES:
  :tj_id: r2
  :END:

* Resource 3
  :PROPERTIES:
  :tj_id: r3
  :END:

  * System 1 :tj_resource:
:PROPERTIES:
:tj_id: s1
:tj_efficiency: 0.0
:tj_rate: 600.0
:END:
   

 Here the fact of inheritance of org tags have been taken into account in
 org task Team 1 for resource Resource 2 and Resource 3.

 For the tasks the same holds:

 task project Project {
  task wp1 Workpackage 1 {
task t1 Task 1
task t2 Task 2
  }
  task wp2 Work package 2 {
depends !wp1
task t1 Task 1
task t2 Task 2
  }
  task deliveries Deliveries {
task Item 1 {
  depends !!wp1
}
task Item 2 {
  depends !!wp2
}
  }
  }

  Org mode:

  * Project  :tj_task:
:PROPERTIES:
:tj_id: project
:END:

* Workpackage 2
  :PROPERTIES:
  :tj_id: wp2
  :END:

  * Task 1
:PROPERTIES:
:tj_id: t1
:tj_depends: !wp1
:END:
  * Task 2
:PROPERTIES:
:tj_id: t2
:END:


Also accounts could be easily generated with this
method:

account cost Project Cost {
  account dev Development
  account doc Documentation
}

---

 * Project Cost  :tj_account:
   :PROPERTIES:
   :tj_id: cost
   :END:

   * Development
 :PROPERTIES:
 :tj_id: dev
 :END:
   * Documentation
 :PROPERTIES:
 :tj_id: doc
 :END:

 There is still the question how to implement properties that go into
 the global part of a tj file. Here I would suggest that one can place
 this data inbetween

 #+BEGIN_TASKJUGGLER
 # The ProfitLoss analysis 

Re: [O] More decoration for babel output

2013-03-06 Thread Bastien
Hi Ken,

Ken Williams ken.willi...@windlogics.com writes:

 Would this be helpful to include by default?  Patch attached.

I committed something deeply inspired by your patch, 
but slightly different.  Please have a look (from master)
and let me know if you think this is okay.

Thanks for this idea!

-- 
 Bastien



Re: [O] More decoration for babel output

2013-01-24 Thread Bastien
Hi Ken,

Ken Williams ken.willi...@windlogics.com writes:

 Hi all,

 When exporting to HTML I always add some extra CSS to my org-mode config,
 for the purpose of identifying which chunks are input vs. output, and for
 identifying the language of the code in code chunks.  Language is
 identified by a little label on the box, and input/output is identified by
 green/red.

 Would this be helpful to include by default?  Patch attached.

This look fine -- can you send a screenshot?

I cannot apply the patch until you assign your copyright to the FSF.
Would be nice if you can do it!  Here is the form:

http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt

Thanks,

-- 
 Bastien



Re: [O] More decoration for babel output

2013-01-24 Thread Gunnar Wolf
Gunnar Wolf dijo [Wed, Jan 23, 2013 at 11:25:43AM -0600]:
  When exporting to HTML I always add some extra CSS to my org-mode
  config, for the purpose of identifying which chunks are input
  vs. output, and for identifying the language of the code in code
  chunks.  Language is identified by a little label on the box, and
  input/output is identified by green/red.
  
  Would this be helpful to include by default?  Patch attached.
 
 As for me, with slight adaptations, I am including it in my operating
 systems class notes. Thanks!

FWIW, the only changes I did to your css is to use darker backgrounds
(#33 instead of #F5FFF5), as the code is hardwired to somewhat
inconvenient colors (some very dark, some very bright) and the result
was hard to read.



[O] More decoration for babel output

2013-01-23 Thread Ken Williams
Hi all,

When exporting to HTML I always add some extra CSS to my org-mode config, for 
the purpose of identifying which chunks are input vs. output, and for 
identifying the language of the code in code chunks.  Language is identified by 
a little label on the box, and input/output is identified by green/red.

Would this be helpful to include by default?  Patch attached.

--
Ken Williams, Senior Research Scientist
WindLogics
http://windlogics.com




CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended 
recipient(s) and may contain confidential and privileged information. Any 
unauthorized review, use, disclosure or distribution of any kind is strictly 
prohibited. If you are not the intended recipient, please contact the sender 
via reply e-mail and destroy all copies of the original message. Thank you.
From 37ba52c7911b88c6879179311571654ded0273dd Mon Sep 17 00:00:00 2001
From: Ken Williams ken.willi...@windlogics.com
Date: Wed, 23 Jan 2013 10:14:50 -0600
Subject: [PATCH 1/1] Add background color and language-label to CSS for babel
 blocks.

---
 lisp/org-html.el |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/lisp/org-html.el b/lisp/org-html.el
index 224a103..5e34385 100644
--- a/lisp/org-html.el
+++ b/lisp/org-html.el
@@ -170,6 +170,30 @@ for the JavaScript code in this tag.
 font-size: 90%;
 overflow:auto;
   }
+
+  /* Some decoration for source code blocks and their output. */
+  pre.src {
+background-color: #F5FFF5;
+position: relative;
+overflow: visible;
+margin-right: auto;
+  }
+  pre.src:before {
+position: absolute;
+top: -15px;
+background: #ff;
+padding: 1px;
+border: 1px solid #00;
+font-size: small;
+  }
+  pre.src-sh:before   { content: 'sh'; }
+  pre.src-bash:before { content: 'sh'; }
+  pre.src-R:before{ content: 'R'; }
+  pre.src-perl:before { content: 'Perl'; }
+  pre.src-java:before { content: 'Java'; }
+  pre.src-sql:before  { content: 'SQL'; }
+  pre.example { background-color: #FFF5F5; }
+
   table { border-collapse: collapse; }
   td, th { vertical-align: top;  }
   th.right  { text-align:center;  }
-- 
1.7.9



Re: [O] More decoration for babel output

2013-01-23 Thread Gunnar Wolf
Ken Williams dijo [Wed, Jan 23, 2013 at 04:26:54PM +]:
 Hi all,
 
 When exporting to HTML I always add some extra CSS to my org-mode
 config, for the purpose of identifying which chunks are input
 vs. output, and for identifying the language of the code in code
 chunks.  Language is identified by a little label on the box, and
 input/output is identified by green/red.
 
 Would this be helpful to include by default?  Patch attached.

As for me, with slight adaptations, I am including it in my operating
systems class notes. Thanks!



Re: [O] More flyspell-overlays removed

2012-08-07 Thread Jeffrey Spencer
Re-dl'ed and works fine. Sorry about that.

On Tue, Aug 7, 2012 at 7:18 PM, Bastien b...@gnu.org wrote:

 Hi Jeffrey,

 Jeffrey Spencer jeffspenc...@gmail.com writes:

  Just gave this a go and seems to work well but still forgot to add I
  believe:
 
  TYP_TODO
  and
  ATTR_LATEX

 The two words above are already skipped for me.

 --
  Bastien



Re: [O] More flyspell-overlays removed

2012-08-07 Thread Bastien


Hi Jeffrey,

Jeffrey Spencer jeffspenc...@gmail.com writes:

 Just gave this a go and seems to work well but still forgot to add I
 believe:

 TYP_TODO
 and
 ATTR_LATEX

The two words above are already skipped for me.

-- 
 Bastien




Re: [O] More flyspell-overlays removed

2012-08-06 Thread Jeffrey Spencer
Just gave this a go and seems to work well but still forgot to add I
believe:

TYP_TODO
and
ATTR_LATEX

Cheers,
Jeff

On Wed, Aug 1, 2012 at 1:32 AM, Bastien b...@gnu.org wrote:



 Sebastien Vauban
 wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

  I would allow fly-prog-mode in the listins, as one normally does for
 plain
  code, no?

 This is indeed the case right now.

 --
  Bastien





Re: [O] More flyspell-overlays removed

2012-07-31 Thread Jeffrey Spencer
I don't have any problem with natbib cite commands including \ref, \cite,
\citet, \citep, etc

Maybe your version of flyspell?? But it should act exactly as it does in
auctex or your latex mode of emacs. I would check in there if it works
properly because should parse the same way if not maybe debug from there.

Cheers,
Jeff

On Mon, Jul 30, 2012 at 9:44 PM, Bjarte Johansen bjo...@student.uib.nowrote:


 On 30 Jul, 2012, at 13:03 , Bastien b...@gnu.org wrote:

  I've pushed a fix which should let flyspell ignore more commonly
  used Org keywords.  Please test it.

 This works great. You forgot #+LATEX_CLASS_OPTIONS: though.


 On 30 Jul, 2012, at 13:13 , Jeffrey Spencer jeffspenc...@gmail.com
 wrote:

  Will give it a test later in the week and let you know.
 
  Also you can add this hook to make it act like the fly-spell mode in
 auctex (if familiar with that) which skips most tex based commands (trips
 up though if you have only one $ because assumes another $ sign later so
 won't check spelling in that block. I would just do \$ if you need a single
 dollar sign. This is the only really limitation I have found to adding this
 that I have noticed thus far.
  (add-hook 'org-mode-hook (lambda () (setq ispell-parser 'tex)))

 I tried this and it does work for most things, but for some reason it
 doesn't like the natbib \cite commands.


Re: [O] More flyspell-overlays removed

2012-07-29 Thread Jeffrey Spencer
I was also thinking about this recently but hadn't gotten as far as writing
a patch.

I was thinking some tags you know you want to remove the fly-spell overlays
but for example caption you might or might not want the flyspell overlays
removed. If there was a variable that could be set to choose some that
might or might not want the overlays to remove. Not sure if this is
possible but what I was originally looking at doing but hadn't gotten time.

Cheers,
Jeff

On Sun, Jul 29, 2012 at 8:38 AM, Bjarte Johansen bjo...@student.uib.nowrote:

 On 28 Jul, 2012, at 11:27 , Bastien b...@gnu.org wrote:

 I cannot apply it because it adds keywords at the wrong place.
 For example you cannot add startup: in the first (cond ((...)))
 because startup: is not a backend specific content.  And some
 other discrepencies.


 OK, I understand. I should have spent some more time trying to
 understand the code.


 I'd welcome a patch for removing more flyspell overlays, but it
 has to be rewritten.  I'm not using flyspell so someone else will
 have to do roll his sleeves.


 I'd be willing to put in the effort to make a proper patch, but I need
 some
 help to understand what is going on in this function. It is not obvious to
 me.

 The places flyspell-overlays needs to be removed are in the startup,
 options, latex_header.  Some of structures that might be used in latex
 like
 lstlisting and verbatim where the text also should not have
 flyspell-overlays.

 There are also some other places like label, caption and attr.



Re: [O] More flyspell-overlays removed

2012-07-28 Thread Bastien
Hi Bjarte,

Bjarte Johansen bjo...@student.uib.no writes:

 I made a patch to remove some more flyspell-overlays in #-blocks. The
 reason for no : in the latex_header is that for some reason the : does
 not get captured in dc1. flyspell is also removed for the full
 verbatim, lstlisting and src blocks.

 I hope you guys can use the patch.

I cannot apply it because it adds keywords at the wrong place.  
For example you cannot add startup: in the first (cond ((...)))
because startup: is not a backend specific content.  And some
other discrepencies.

I'd welcome a patch for removing more flyspell overlays, but it
has to be rewritten.  I'm not using flyspell so someone else will
have to do roll his sleeves.

Thanks anyway for the patch!

-- 
 Bastien



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-10 Thread Bastien
Hi Eric,

Eric S Fraga e.fr...@ucl.ac.uk writes:

 Thorsten Jolitz tjol...@googlemail.com writes:

 [...]

 What I mainly did was updating from the git repo and changing the order
 of hooks (orgstruct++-mode last). And I had to get rid of
 emacs-goodies-el too, but that was probably my specific configuration. 

 Ahh, interesting data point.  I have emacs-goodies.el installed.  What
 is it about this package that causes problems?  

This package contains filladapt.el and filladapt.el _overwrites_ some
fundamental variables about filling.  Even if you are not using
filladapt.el, it fill replace those variables... which is obvisouly
plain wrong.

 This could be why Bastien cannot reproduce the behaviour we have been
 seeing?

I think so.

 I did see another reference to this package on one of the emacs mailing
 lists, implying that it wasn't necessary with Emacs 24, but I think I do
 use a few bits from it (bar-cursor, dict, matlab, maybe others).  Maybe
 these are in emacs 24...  but I don't think so.  Any insight into this
 would be most welcome!

(setq cursor-type 'bar) or (setq cursor-type 'hbar) works here.

As for dict, matlab, you can still download them from their original
locations I guess.

HTH,

-- 
 Bastien



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-10 Thread Sebastien Vauban
Hi,

Bastien wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 I have emacs-goodies.el installed. What is it about this package that
 causes problems?

 This package contains filladapt.el and filladapt.el _overwrites_ some
 fundamental variables about filling. Even if you are not using filladapt.el,
 it fill replace those variables... which is obvisouly plain wrong.

FWIW, I do use filladapt.el (version 2.12, directly downloaded from the Web,
long time ago), and never experienced troubles yet (in Gnus, with
orgstruct++-mode).

Bastien, you say we should get rid of it, but it seems the reason I have it on
my system is (or was) because it does a better job than Emacs builtin
Adaptative Fill mode. Anybody: any comment on this?

#+begin_src emacs-lisp
  ;; enable FillAdapt (does a better job than Emacs builtin Adaptative
  ;; Fill mode)
  (autoload 'turn-on-filladapt-mode filladapt
Unconditionally turn on Filladapt mode in the current buffer.)
  (autoload 'turn-off-filladapt-mode filladapt
Unconditionally turn off Filladapt mode in the current buffer.)

  (defun my/enable-filling ()
Enable AutoFill and FillAdapt minor modes.

;; when inserting text, *automatically* break line at a previous
;; space, if the current column number is greater than the value of
;; `fill-column'
(turn-on-auto-fill)

;; turn on FillAdapt mode everywhere but in ChangeLog files
(cond ((equal mode-name Change Log) t)
  (t (turn-on-filladapt-mode

  ;; enable AutoFill and FillAdapt in Text and Org modes
  (add-hook 'text-mode-hook 'my/enable-filling)
  (add-hook 'org-mode-hook 'my/enable-filling)
#+end_src

In Gnus, this is my config:

#+begin_src emacs-lisp
  ;; operates on messages you send
  (defun my/message-mode-hook ()

;; tab completion for alias in `.mailrc'
(local-set-key (kbd M-tab) 'mail-abbrev-complete-alias)

;; enable automatic word-wrap when composing messages
(setq fill-column 78)
(turn-on-auto-fill)

(when (locate-library org.el)

  ;; turn on the `org-mode' table editor
  (turn-on-orgtbl)

  ;; turn on (the enhanced version of) orgstruct-mode
  (turn-on-orgstruct++)

  ;; make `orgstruct-hijacker-command-22' rebind `M-q' to a message
  ;; specific function to fill a paragraph
  (setq fill-paragraph-function 'message-fill-paragraph))

(when (locate-library auto-complete.el)
  (auto-complete-mode)))

  (add-hook 'message-mode-hook 'my/message-mode-hook)
#+end_src

Notice that I had to add:

#+begin_src emacs-lisp
  ;; make `orgstruct-hijacker-command-22' rebind `M-q' to a message
  ;; specific function to fill a paragraph
  (setq fill-paragraph-function 'message-fill-paragraph)
#+end_src

a couple of weeks ago, because the filling did not behave anymore like it did.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-10 Thread Bastien



Hi Sébastien,

perhaps the problem with filladapt was specific to Thorsten's
installation, it's hard to guess.

IMHO the real question is: what do you need filladapt for?

You wouldn't install a new software called Emacs-For-The-Real-Men just
because it advertizes itself as Make a better job than Emacs... unless
you can tell if this is true, and for what.

But I don't have /a priori/ concerns with anyone using filladapt.el, and
my advice was just to be taken as it is: a personal point of view.

My concern is Should Org work even if people are shooting themselves in
the foot with libraries that are perhaps obsolete and that replace
fundamental variables of Emacs?  The simple answer is: Yes, if this is
both reasonable and feasible.

Regarding filladapt, if it really does a better job at filling, then 
it should be somehow merged into Emacs.  For now, it replaces functions
like `do-auto-fill' and Org cannot really be expected to understand such
replacements done outside Emacs.

 Notice that I had to add:

 #+begin_src emacs-lisp
   ;; make `orgstruct-hijacker-command-22' rebind `M-q' to a message
   ;; specific function to fill a paragraph
   (setq fill-paragraph-function 'message-fill-paragraph)
 #+end_src

 a couple of weeks ago, because the filling did not behave anymore like it did.

That's why it works now.  

You enable orgstruct++-mode but you don't use its `org-fill-paragraph'
function, you use `message-fill-paragraph' instead.  As for auto-filling,
you don't use `auto-fill-function', but filladapt's internal ̀do-auto-fill'
instead.

So, unless you really know why you need/enjoy filladapt, I think it's
not _that_ unreasonable not using it.

2 cents,

-- 
 Bastien





[O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Bernt Hansen
Hi Bastien,

Auto-fill wrapping has stopped working correctly lately.

I have orgstruct++-mode added to my message mode hook as 

--8---cut here---start-8---
(add-hook 'message-mode-hook 'orgstruct++-mode 'append)
(add-hook 'message-mode-hook 'turn-on-auto-fill 'append)
(add-hook 'message-mode-hook 'orgtbl-mode 'append)
--8---cut here---end---8---

and lately auto-fill doesn't work correctly when text starts in column
0.  Text wraps to the start of the second word on the line.

,[ orgstruct++-mode off with auto fill ]
| this is a long line which should auto fill but not wrap to 2nd word on
| the line
| 
`

,[ orgstruct++-mode on with auto fill ]
| this is a line that is really long and autofilll with org struct mode
|  does not work properly.  It indents line 2+ by 5 chars
| 
| whatifthe word is really long on the first line how does that make
|   autofilll rec
`

For now I've dropped orgstruct++-mode from my message-mode hook but I'm
going to miss this for lists in my emails.

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
on raven, modified by Debian

Org-mode version 7.8.09 (release_7.8.09-489-g541288 @
/home/bernt/git/org-mode/lisp/org-install.el)

Regards,
Bernt



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Christopher Schmidt
Bernt Hansen be...@norang.ca writes:

 For now I've dropped orgstruct++-mode from my message-mode hook but
 I'm going to miss this for lists in my emails.

orgstruct-mode/orgtbl-mode work fine and do not break anything.

Christopher



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Thorsten Jolitz
Bernt Hansen be...@norang.ca writes:

Hi Bernt,

 Auto-fill wrapping has stopped working correctly lately.

I had exactly the same problem you describe (no wonder because I just
copied your configuration) and solved it with Bastiens help. 

You can search for subject Strange indentation in message-mode in the
gnus.user mailing list to find the thread. 

What I mainly did was updating from the git repo and changing the order
of hooks (orgstruct++-mode last). And I had to get rid of
emacs-goodies-el too, but that was probably my specific configuration. 

 I have orgstruct++-mode added to my message mode hook as 

 --8---cut here---start-8---
 (add-hook 'message-mode-hook 'orgstruct++-mode 'append)
 (add-hook 'message-mode-hook 'turn-on-auto-fill 'append)
 (add-hook 'message-mode-hook 'orgtbl-mode 'append)
 --8---cut here---end---8---

 and lately auto-fill doesn't work correctly when text starts in column
 0.  Text wraps to the start of the second word on the line.

 ,[ orgstruct++-mode off with auto fill ]
 | this is a long line which should auto fill but not wrap to 2nd word on
 | the line
 | 
 `

 ,[ orgstruct++-mode on with auto fill ]
 | this is a line that is really long and autofilll with org struct mode
 |  does not work properly.  It indents line 2+ by 5 chars
 | 
 | whatifthe word is really long on the first line how does that make
 |   autofilll rec
 `

 For now I've dropped orgstruct++-mode from my message-mode hook but I'm
 going to miss this for lists in my emails.

 GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
 on raven, modified by Debian

 Org-mode version 7.8.09 (release_7.8.09-489-g541288 @
 /home/bernt/git/org-mode/lisp/org-install.el)

 Regards,
 Bernt


-- 
cheers,
Thorsten




Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Bastien
Hi Bernt,

Bernt Hansen be...@norang.ca writes:

 Auto-fill wrapping has stopped working correctly lately.

It seems you're behind latest git HEAD by ~55 commits and 
there has been bug fixes in this area.

Please pull again (even temporarily) and let me know if this
happens again with your configuration.

 I have orgstruct++-mode added to my message mode hook as 

 (add-hook 'message-mode-hook 'orgstruct++-mode 'append)
 (add-hook 'message-mode-hook 'turn-on-auto-fill 'append)
 (add-hook 'message-mode-hook 'orgtbl-mode 'append)

I can't reproduce this with latest Org here.  I load emacs -Q 
then eval your three add-hook above then C-x m and I get the 
expected behavior.

HTH,

-- 
 Bastien



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Bernt Hansen
Bastien b...@gnu.org writes:

 Hi Bernt,

 Bernt Hansen be...@norang.ca writes:

 Auto-fill wrapping has stopped working correctly lately.

 It seems you're behind latest git HEAD by ~55 commits and 
 there has been bug fixes in this area.

 Please pull again (even temporarily) and let me know if this
 happens again with your configuration.

OK - I'll update and try again - I browsed the shortlog and didn't see
anything relevant but maybe I missed it.

Thanks,
Bernt



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Bastien
Hi Bernt,

Bernt Hansen be...@norang.ca writes:

 Bastien b...@gnu.org writes:

 Hi Bernt,

 Bernt Hansen be...@norang.ca writes:

 Auto-fill wrapping has stopped working correctly lately.

 It seems you're behind latest git HEAD by ~55 commits and 
 there has been bug fixes in this area.

 Please pull again (even temporarily) and let me know if this
 happens again with your configuration.

 OK - I'll update and try again - I browsed the shortlog and didn't see
 anything relevant but maybe I missed it.

Check these two:

035ab39e * | Another fix to `org-indent-line-function'.
99c97fbf * | Fix bug in `org-indent-line-function'.

HTH,

-- 
 Bastien



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Bernt Hansen
Bernt Hansen be...@norang.ca writes:

 Bastien b...@gnu.org writes:

 Hi Bernt,

 Bernt Hansen be...@norang.ca writes:

 Auto-fill wrapping has stopped working correctly lately.

 It seems you're behind latest git HEAD by ~55 commits and 
 there has been bug fixes in this area.

 Please pull again (even temporarily) and let me know if this
 happens again with your configuration.

 OK - I'll update and try again - I browsed the shortlog and didn't see
 anything relevant but maybe I missed it.

 Thanks,
 Bernt

This seems to work just fine now so I think it's fixed.  Thanks and
sorry for the noise.

Bernt



Re: [O] More problems with orgstruct++-mode, message-mode and auto fill

2012-05-09 Thread Eric S Fraga
Thorsten Jolitz tjol...@googlemail.com writes:

[...]

 What I mainly did was updating from the git repo and changing the order
 of hooks (orgstruct++-mode last). And I had to get rid of
 emacs-goodies-el too, but that was probably my specific configuration. 

Ahh, interesting data point.  I have emacs-goodies.el installed.  What
is it about this package that causes problems?  This could be why
Bastien cannot reproduce the behaviour we have been seeing?

I did see another reference to this package on one of the emacs mailing
lists, implying that it wasn't necessary with Emacs 24, but I think I do
use a few bits from it (bar-cursor, dict, matlab, maybe others).  Maybe
these are in emacs 24...  but I don't think so.  Any insight into this
would be most welcome!

thanks,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org release_7.8.09-544-g505cc7




Re: [O] More than one column view in a file

2012-05-01 Thread Ippei FURUHASHI
Hi Sebastien,

Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

 I'd like to have a couple of different (column) views in my Org file

How about trying this patch which let you have another format in column
view?

After applying this patch, try this.
  M-: (org-columns %66ITEM(Task) %6Effort(Estim.){:})

Best,
IP
From ee660fcb0c5a3a547681d8390284bb57399e05bf Mon Sep 17 00:00:00 2001
From: Ippei FURUHASHI top.tuna+orgm...@gmail.com
Date: Tue, 1 May 2012 12:11:06 +0900
Subject: [PATCH] org-colview.el: Add functions to column view with formats
 selectively

* lisp/org-colview.el (org-columns): Give new argument
`columns-fmt-string'.
* lisp/org-colview.el (org-columns-get-format-end-top-level): Split
this function into 2 functions, `org-columns-get-format' and
`org-columns-goto-top-level'.

For example, even if the item (or the parent) has the property,
  :COLUMNS:  %66ITEM(Task) %6Effort(Estim.){:} %6CLOCKSUM(Time)
Org can offer column view with another format by typing
  M-: (org-columns %66ITEM(Task) %6Effort(Estim.){:})
---
 lisp/org-colview.el |   30 ++
 1 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 5409701..c7b5d45 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -665,27 +665,41 @@ (defun org-columns-open-link (optional arg)
 (org-open-link-from-string value arg)))
 
 (defun org-columns-get-format-and-top-level ()
-  (let (fmt)
+  (let (fmt (org-columns-get-format))
+(org-columns-goto-top-level)
+fmt))
+
+(defun org-columns-get-format (optional fmt-string)
+  (interactive)
+  (let (fmt-as-property)
 (when (condition-case nil (org-back-to-heading) (error nil))
-  (setq fmt (org-entry-get nil COLUMNS t)))
-(setq fmt (or fmt org-columns-default-format))
+  (setq fmt-as-property (org-entry-get nil COLUMNS t)))
+(setq fmt (or fmt-string fmt-as-property org-columns-default-format))
 (org-set-local 'org-columns-current-fmt fmt)
 (org-columns-compile-format fmt)
+fmt))
+
+(defun org-columns-goto-top-level ()
+  (let ()
+(when (condition-case nil (org-back-to-heading) (error nil))
+  (org-entry-get nil COLUMNS t)
 (if (marker-position org-entry-property-inherited-from)
 	(move-marker org-columns-top-level-marker
 		 org-entry-property-inherited-from)
-  (move-marker org-columns-top-level-marker (point)))
-fmt))
+  (move-marker org-columns-top-level-marker (point))
 
-(defun org-columns ()
-  Turn on column view on an org-mode file.
+(defun org-columns (optional columns-fmt-string)
+  Turn on column view on an org-mode file.  When `COLUMNS-FMT-STRING'
+is specified e.g. \%66ITEM(Task) %6Effort(Estim.){:}\), it is
+treated as format for columns, COLUMNS property.
   (interactive)
   (org-verify-version 'columns)
   (org-columns-remove-overlays)
   (move-marker org-columns-begin-marker (point))
   (let ((org-columns-time (time-to-number-of-days (current-time)))
 	beg end fmt cache maxwidths)
-(setq fmt (org-columns-get-format-and-top-level))
+(org-columns-goto-top-level)
+(setq fmt (org-columns-get-format columns-fmt-string))
 (save-excursion
   (goto-char org-columns-top-level-marker)
   (setq beg (point))
-- 
1.7.9.msysgit.0



Re: [O] More than one column view in a file

2012-05-01 Thread Ippei FURUHASHI
Hi Sebastien,

Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

 Hello,

 I'd like to have a couple of different (column) views in my Org file

How about trying this patch which lets you have another format in column
view?

After applying this patch, try this at the Tasks tree in your example.
 M-: (org-columns %66ITEM(Task) %6CLOCKSUM(Time) %6Effort(Estim.){:})
to compare with the result of
 M-: (org-columns)

Best,
IP

(snip)

 #+TITLE: Effort vs Estimate
 #+AUTHOR:Seb Vauban

 * Tasks
   :PROPERTIES:
   :ID:   49380c04-9b6e-4298-aff8-d936d9679d8e
   :COLUMNS:  %6TODO %66ITEM(Task) %6Effort(Estim.){:}
   :END:

 ** TODO A
(snip and end)

From ee660fcb0c5a3a547681d8390284bb57399e05bf Mon Sep 17 00:00:00 2001
From: Ippei FURUHASHI top.tuna+orgm...@gmail.com
Date: Tue, 1 May 2012 12:11:06 +0900
Subject: [PATCH] org-colview.el: Add functions to column view with formats
 selectively

* lisp/org-colview.el (org-columns): Give new argument
`columns-fmt-string'.
* lisp/org-colview.el (org-columns-get-format-end-top-level): Split
this function into 2 functions, `org-columns-get-format' and
`org-columns-goto-top-level'.

For example, even if the item (or the parent) has the property,
  :COLUMNS:  %66ITEM(Task) %6Effort(Estim.){:} %6CLOCKSUM(Time)
Org can offer column view with another format by typing
  M-: (org-columns %66ITEM(Task) %6Effort(Estim.){:})
---
 lisp/org-colview.el |   30 ++
 1 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 5409701..c7b5d45 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -665,27 +665,41 @@ (defun org-columns-open-link (optional arg)
 (org-open-link-from-string value arg)))
 
 (defun org-columns-get-format-and-top-level ()
-  (let (fmt)
+  (let (fmt (org-columns-get-format))
+(org-columns-goto-top-level)
+fmt))
+
+(defun org-columns-get-format (optional fmt-string)
+  (interactive)
+  (let (fmt-as-property)
 (when (condition-case nil (org-back-to-heading) (error nil))
-  (setq fmt (org-entry-get nil COLUMNS t)))
-(setq fmt (or fmt org-columns-default-format))
+  (setq fmt-as-property (org-entry-get nil COLUMNS t)))
+(setq fmt (or fmt-string fmt-as-property org-columns-default-format))
 (org-set-local 'org-columns-current-fmt fmt)
 (org-columns-compile-format fmt)
+fmt))
+
+(defun org-columns-goto-top-level ()
+  (let ()
+(when (condition-case nil (org-back-to-heading) (error nil))
+  (org-entry-get nil COLUMNS t)
 (if (marker-position org-entry-property-inherited-from)
 	(move-marker org-columns-top-level-marker
 		 org-entry-property-inherited-from)
-  (move-marker org-columns-top-level-marker (point)))
-fmt))
+  (move-marker org-columns-top-level-marker (point))
 
-(defun org-columns ()
-  Turn on column view on an org-mode file.
+(defun org-columns (optional columns-fmt-string)
+  Turn on column view on an org-mode file.  When `COLUMNS-FMT-STRING'
+is specified e.g. \%66ITEM(Task) %6Effort(Estim.){:}\), it is
+treated as format for columns, COLUMNS property.
   (interactive)
   (org-verify-version 'columns)
   (org-columns-remove-overlays)
   (move-marker org-columns-begin-marker (point))
   (let ((org-columns-time (time-to-number-of-days (current-time)))
 	beg end fmt cache maxwidths)
-(setq fmt (org-columns-get-format-and-top-level))
+(org-columns-goto-top-level)
+(setq fmt (org-columns-get-format columns-fmt-string))
 (save-excursion
   (goto-char org-columns-top-level-marker)
   (setq beg (point))
-- 
1.7.9.msysgit.0



Re: [O] More than one column view in a file

2012-05-01 Thread Ippei FURUHASHI
Hi Sebastien

Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

 Hello,

 I'd like to have a couple of different (column) views in my Org file, for
 example:

 - one (public) view with the estimated time only
 - another one (private, I mean not exported) with the real clocked time

My previous patch and this patch cooperate to generate
the columnview dynamic block with given columns format.

The result for your example is shown below, and I hope you like it.
Please regard #+BEGIN line as 1 line, though it seems to be wrapped.


#+TITLE: Effort vs Estimate
#+AUTHOR:Seb Vauban

* Tasks
  :PROPERTIES:
  :ID:   49380c04-9b6e-4298-aff8-d936d9679d8e
  :COLUMNS:  %66ITEM(Task) %6Effort(Estim.){:} %6CLOCKSUM(Time)
  :END:

** TODO A

*** TODO A1
:PROPERTIES:
:Effort:   12:00
:END:
:LOGBOOK:
CLOCK: [2012-03-01 Thu 09:00]--[2012-03-01 Thu 17:00] =  8:00
CLOCK: [2012-03-02 Fri 09:00]--[2012-03-02 Fri 17:00] =  8:00
CLOCK: [2012-04-05 Thu 09:00]--[2012-04-05 Thu 12:45] =  3:45
CLOCK: [2012-04-16 Mon 09:00]--[2012-04-16 Mon 14:45] =  5:45
:END:

*** TODO A2
:PROPERTIES:
:Effort:   24:00
:END:

** TODO B
   :PROPERTIES:
   :Effort: 1:00
   :END:
   :LOGBOOK:
   CLOCK: [2012-03-01 Thu 09:00]--[2012-03-01 Thu 09:30] =  0:30
   :END:

* Budget estimate

We have estimated the budget as follows:

#+tblname: dblock-tasks
#+BEGIN: columnview :hlines 1 :id 49380c04-9b6e-4298-aff8-d936d9679d8e 
:maxlevel 3 :format %6TODO %66ITEM(Task) %6Effort(Estim.){:}
| TODO | Task| Estim. |
|--+-+|
|  | * Tasks |  37:00 |
| TODO | ** A|  36:00 |
| TODO | *** A1  |  12:00 |
| TODO | *** A2  |  24:00 |
| TODO | ** B|   1:00 |
#+END:

* Worked hours :noexport:

We have worked that much, and can compare with what had been estimated:

#+tblname: dblock-tasks
#+BEGIN: columnview :hlines 1 :id 49380c04-9b6e-4298-aff8-d936d9679d8e 
:maxlevel 3 :format %6TODO %66ITEM(Task) %6Effort(Estim.){:} %6CLOCKSUM(Time)
| TODO | Task| Estim. |  Time |
|--+-++---|
|  | * Tasks |  37:00 | 26:00 |
| TODO | ** A|  36:00 | 25:30 |
| TODO | *** A1  |  12:00 | 25:30 |
| TODO | *** A2  |  24:00 |   |
| TODO | ** B|   1:00 |  0:30 |
#+END:


Best regards,
IP


From 50701702a646064034eb4fc718862aa8b7f53bcd Mon Sep 17 00:00:00 2001
From: Ippei FURUHASHI top.tuna+orgm...@gmail.com
Date: Wed, 2 May 2012 05:23:00 +0900
Subject: [PATCH] lisp/org-colview.el: add new param of format to columnview
 dblock

* lisp/org-colview.el (org-dblock-write:columnview): Add a new param,
:format which specifies the column view format to be output as
columnview dynamic block.

One can generate columnview dynamic block with chosen format:
  #+BEGIN: columnview :format %6TODO %66ITEM(Task) %6Effort(Estim.){:}
  #+END:

TINYCHANGE
---
 lisp/org-colview.el |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index c7b5d45..d3fb601 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -1229,13 +1229,16 @@ (defun org-dblock-write:columnview (params)
 :vlines   When t, make each column a colgroup to enforce vertical lines.
 :maxlevel When set to a number, don't capture headlines below this level.
 :skip-empty-rows
-	  When t, skip rows where all specifiers other than ITEM are empty.
+	  When t, skip rows where all specifiers other than ITEM are empty.
+:format   When a non-nil string like \%66ITEM(Task) %6Effort(Estim.){:}\,
+  it specifies the format of column view.
   (let ((pos (move-marker (make-marker) (point)))
 	(hlines (plist-get params :hlines))
 	(vlines (plist-get params :vlines))
 	(maxlevel (plist-get params :maxlevel))
 	(content-lines (org-split-string (plist-get params :content) \n))
 	(skip-empty-rows (plist-get params :skip-empty-rows))
+	(columns-fmt (plist-get params :format))
 	(case-fold-search t)
 	tbl id idpos nfields tmp recalc line
 	id-as-string view-file view-pos)
@@ -1265,7 +1268,7 @@ (defun org-dblock-write:columnview (params)
 	(save-restriction
 	  (widen)
 	  (goto-char (or view-pos (point)))
-	  (org-columns)
+	  (org-columns columns-fmt)
 	  (setq tbl (org-columns-capture-view maxlevel skip-empty-rows))
 	  (setq nfields (length (car tbl)))
 	  (org-columns-quit
-- 
1.7.9.msysgit.0



Re: [O] More than one column view in a file

2012-04-20 Thread Bastien
Hi Sébastien,

Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 I'd like to have a couple of different (column) views in my Org file

This is currently not possible and would require a lot of work. 

Best,

-- 
 Bastien



Re: [O] More than one column view in a file

2012-04-20 Thread Sebastien Vauban
Hi Bastien,

Bastien wrote:
 Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 I'd like to have a couple of different (column) views in my Org file

 This is currently not possible and would require a lot of work.

A pity, but I completely conceive it was not clear that it could have be more
promising this way (using the columns definition of the caller tree, not the
callee one).

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] More than one column view in a file

2012-04-20 Thread Johnny
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 Bastien wrote:
 Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 I'd like to have a couple of different (column) views in my Org file

 This is currently not possible and would require a lot of work.

This is something I have been looking for as well and it would be a
great feature, if someone feels the inspiration to work on it! However,
I went on to use different specification lines and choosing the one to
use by commenting the ones not to use. This is a reasonable work around
until I learn enough lisp to change it. :)

 A pity, but I completely conceive it was not clear that it could have be more
 promising this way (using the columns definition of the caller tree, not the
 callee one).


?

Regards,

J

-- 
Johnny



Re: [O] More than one column view in a file

2012-04-20 Thread Bastien
Hi Johnny,

Johnny yggdra...@gmx.co.uk writes:

 Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 Bastien wrote:
 Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 I'd like to have a couple of different (column) views in my Org file

 This is currently not possible and would require a lot of work.

 This is something I have been looking for as well and it would be a
 great feature, if someone feels the inspiration to work on it! However,
 I went on to use different specification lines and choosing the one to
 use by commenting the ones not to use. This is a reasonable work around
 until I learn enough lisp to change it. :)

Mhh... you made me reread Sébastien'd proposal more carefully and I now
understand.  If the idea is to have the choice between several column
views, then it's easily feasible.  I thought the question was to have
several different overlays *simultaneously*... (and got half crazy by
just trying to imagine this.)

So, yes, let's think about this.

-- 
 Bastien



[O] More than one column view in a file

2012-04-17 Thread Sebastien Vauban
Hello,

I'd like to have a couple of different (column) views in my Org file, for
example:

- one (public) view with the estimated time only
- another one (private, I mean not exported) with the real clocked time

I thought about setting the columns I wish to display in the corresponding
sections... but it appears that the column specification that's taken into
account must be defined where the tasks are (file-wide, or in the Tasks
subtree) -- not where the table will be generated.

This, by no way, is a bug: nobody said it should be working the way I'd like
it to be working right now.

Though, I have the impression the current way is quite limiting.

But my question is simply: do you have any idea for a way to work around this?

In the following ECM, you see (on purpose) that PRIOR is displayed in both
columns, while only set in the PROPERTY of the Tasks subtree.

Best regards,
  Seb

--8---cut here---start-8---
#+TITLE: Effort vs Estimate
#+AUTHOR:Seb Vauban

* Tasks
  :PROPERTIES:
  :ID:   49380c04-9b6e-4298-aff8-d936d9679d8e
  :COLUMNS:  %6TODO %66ITEM(Task) %6Effort(Estim.){:}
  :END:

** TODO A

*** TODO A1
:PROPERTIES:
:Effort:   12:00
:END:
:LOGBOOK:
CLOCK: [2012-03-01 Thu 09:00]--[2012-03-01 Thu 17:00] =  8:00
CLOCK: [2012-03-02 Fri 09:00]--[2012-03-02 Fri 17:00] =  8:00
CLOCK: [2012-04-05 Thu 09:00]--[2012-04-05 Thu 12:45] =  3:45
CLOCK: [2012-04-16 Mon 09:00]--[2012-04-16 Mon 14:45] =  5:45
:END:

*** TODO A2
:PROPERTIES:
:Effort:   24:00
:END:

** TODO B
   :PROPERTIES:
   :Effort: 1:00
   :END:
   :LOGBOOK:
   CLOCK: [2012-03-01 Thu 09:00]--[2012-03-01 Thu 09:30] =  0:30
   :END:

* Budget estimate
  :PROPERTIES:
  :COLUMNS:  %66ITEM(Task) %6Effort(Estim.){:}
  :END:

We have estimated the budget as follows:

#+tblname: dblock-tasks
#+BEGIN: columnview :hlines 1 :id 49380c04-9b6e-4298-aff8-d936d9679d8e 
:maxlevel 3
| TODO | Task| Estim. |
|--+-+|
|  | * Tasks |  37:00 |
| TODO | ** A|  36:00 |
| TODO | *** A1  |  12:00 |
| TODO | *** A2  |  24:00 |
| TODO | ** B|   1:00 |
#+END:

* Worked hours  :noexport:
  :PROPERTIES:
  :COLUMNS:  %66ITEM(Task) %6CLOCKSUM(Time) %6Effort(Estim.){:}
  :END:

We have worked that much, and can compare with what had been estimated:

#+tblname: dblock-tasks
#+BEGIN: columnview :hlines 1 :id 49380c04-9b6e-4298-aff8-d936d9679d8e 
:maxlevel 3
| TODO | Task| Estim. |
|--+-+|
|  | * Tasks |  37:00 |
| TODO | ** A|  36:00 |
| TODO | *** A1  |  12:00 |
| TODO | *** A2  |  24:00 |
| TODO | ** B|   1:00 |
#+END:
--8---cut here---end---8---

-- 
Sebastien Vauban




[O] More specific LaTeX output classes

2011-12-02 Thread Ken Williams
If I export the following code to LaTeX:

--
#+begin_src R
CV.t.hat - rowMeans(loss)[m]
CV.t.hat
#+end_src

#+results:
: [1] 1.135857
--

, then it looks like this in the *.tex file:

--
\begin{verbatim}
CV.t.hat - rowMeans(loss)[m]
CV.t.hat
\end{verbatim}

\begin{verbatim}
 [1] 1.135857
\end{verbatim}
--

So there's no distinction between input  output, nor between various types of 
input (e.g. different programming languages).

Would it be possible for the export process to define various classes that 
default to being exactly like 'verbatim', but could be customized?  After that, 
a next step might be to provide nice defaults that do things like 
syntax-highlighting (through the 'minted' package, perhaps), or at least add a 
visual marker distinguishing between input  output.

Or of course it's possible some of this is already implemented and I've missed 
it. =)

--
Ken Williams, Senior Research Scientist
WindLogics
http://windlogics.com



CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended 
recipient(s) and may contain confidential and privileged information. Any 
unauthorized review, use, disclosure or distribution of any kind is strictly 
prohibited. If you are not the intended recipient, please contact the sender 
via reply e-mail and destroy all copies of the original message. Thank you.



Re: [O] More specific LaTeX output classes

2011-12-02 Thread Niels Giesen
Ken Williams ken.willi...@windlogics.com writes:


[...]

 Would it be possible for the export process to define various classes
 that default to being exactly like 'verbatim', but could be
 customized? After that, a next step might be to provide nice defaults
 that do things like syntax-highlighting (through the 'minted' package,
 perhaps), or at least add a visual marker distinguishing between input
  output.

 Or of course it's possible some of this is already implemented and I've 
 missed it. =)

Yes it is:

#+begin_src emacs-lisp
  (setq org-export-latex-listings 'minted)
  (add-to-list 'org-export-latex-packages-alist '( minted)
#+end_src

See also `org-export-latex-listings-langs' for a mapping of Emacs modes
to languages known to pygmentize.

Also see

C-h v org-export-latex-listings RET

for more information (e.g. about the --shell-escape option you'll have
to pass to the LaTeX process).

Regards, Niels.
-- 
http://pft.github.com/



Re: [O] More specific LaTeX output classes

2011-12-02 Thread Nick Dokos
Niels Giesen niels.gie...@gmail.com wrote:

 Ken Williams ken.willi...@windlogics.com writes:
 
 
 [...]
 
  Would it be possible for the export process to define various classes
  that default to being exactly like 'verbatim', but could be
  customized? After that, a next step might be to provide nice defaults
  that do things like syntax-highlighting (through the 'minted' package,
  perhaps), or at least add a visual marker distinguishing between input
   output.
 
  Or of course it's possible some of this is already implemented and I've 
  missed it. =)
 
 Yes it is:
 
 #+begin_src emacs-lisp
   (setq org-export-latex-listings 'minted)
   (add-to-list 'org-export-latex-packages-alist '( minted)
 #+end_src
 

NB: there's a closing paren missing in the add-to-list line.

 See also `org-export-latex-listings-langs' for a mapping of Emacs modes
 to languages known to pygmentize.
 
 Also see
 
 C-h v org-export-latex-listings RET
 
 for more information (e.g. about the --shell-escape option you'll have
 to pass to the LaTeX process).
 

Thanks for this (and the pointers that you - and others? - have
provided previously): it finally motivated me to try out minted.

One problem I ran into was that the version of minted.sty that I have
uses which -s to find pygmentize, ``which'' complains about -s and the
run fails. I ended up editing minted.sty to get rid of the -s and
everything works smoothly.

The version I have says

\ProvidesPackage{minted}[2010/01/27 v1.6 Yet another Pygments shim for LaTeX]

I checked CTAN and the most recent version is 1.7: that has excised the -s.

Nick




Re: [O] More on macros: Defined edebug-spec

2011-08-16 Thread Bastien
Hi David,

David Maus dm...@ictsoc.de writes:

 I just pushed a commit to master that adds edebug specifications to
 all macros defined by Org mode. 

This answers questions I've been asking myself for very long!

 With these specifications in place it
 is now possible to step through macros with edebug like a normal
 function call.

 Information about instrumenting macro calls can be found here:

 http://www.gnu.org/software/emacs/elisp/html_node/Instrumenting-Macro-Calls.html

Thanks *a lot* for the link.

Best,

-- 
 Bastien



[O] More on macros: Defined edebug-spec

2011-08-12 Thread David Maus
I just pushed a commit to master that adds edebug specifications to
all macros defined by Org mode. With these specifications in place it
is now possible to step through macros with edebug like a normal
function call.

Information about instrumenting macro calls can be found here:

http://www.gnu.org/software/emacs/elisp/html_node/Instrumenting-Macro-Calls.html

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpvbOcRPBfqA.pgp
Description: PGP signature


Re: [O] More on macros: Defined edebug-spec

2011-08-12 Thread Nick Dokos
David Maus dm...@ictsoc.de wrote:

 I just pushed a commit to master that adds edebug specifications to
 all macros defined by Org mode. With these specifications in place it
 is now possible to step through macros with edebug like a normal
 function call.
 
 Information about instrumenting macro calls can be found here:
 
 http://www.gnu.org/software/emacs/elisp/html_node/Instrumenting-Macro-Calls.html

Thank you, thank you, thank you!

Nick