Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Robert Horn]

Ihor Radchenko  writes:

> Robert Horn  writes:
>
>>> Not really. Countries may change DST at any moment in future. Or decide
>>> to switch calendars (consider countries near the day transition line).
>>>
>>> And "past local time, according to the DST rules in effect at the time"
>>> is also an option that might be useful in certain scenarios.
>>>
>> The issue is clarity of the expected rules for the format.  If I
>> schedule a meeting for 10:05 DST, but the rules change so that it is not
>> DST at that location at that time in the future, what is the expected
>> interpretation?  It could be:
>
> Let me clarify. I do not think that we need to offer selecting DST/no
> DST in the timestamp. Instead, we offer something like
> <2028-12-11 18:00@Europe/Berlin>, specifying local time, including
> possible DST transitions or any other political decisions the country
> might make regarding the local time rules.
>

That would cover it for me.  So, 18:00@Europe/Berlin is the "then local
time", 18:00@CET would be Central European standard time and 18:00@CEST
would be Central European Summer Time.  18:00@UTC would be 19:00@CET and
18:00@CEST. I've found that by far the most common scheduling uses the
"then local time" because that's what people usually want.  I know when
someone schedules a meeting in late March they rarely figure out whether
it will be summer time or standard time.


> Or, if the preference is specifying time in such a way that it is
> unaffected by the local time rules (for example, "+1 hours from now,
> no matter what the DST/no DST or whatever rules will happen in the
> middle"), one can use explicit UTC offsets like <2028-12-11
> 18:00@UTC+02>

Interesting question.  Some uses (like scheduling physical process) want
+4 hours to mean 4 hours later regardless of leap seconds or summer time
changes.  But most people scheduling issues where they say "in 24 hours"
they actually mean +24 in local time.  At the transition to or from
summer time the phrase "within 24 hours" usually means 24 hours except
on the transition days when it's 23 or 25 hours.

Don't worry about TAI.  People who are working in TAI are unlikely to
expect org to support TAI. 


-- 
Robert Horn
rjhorn...@gmail.com

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Robert Horn]

Tom Gillespie  writes:

>> Getting the rules and explanation clear is the issue.  It's a mistake
>> that a great many people make with scheduling meetings.  Those two
>> behaviors need different encodings because they behave differently.
>
> This is related to why I suggested splitting timezones and offsets into
> two separate categories. I think we have to assume that the written
> content of timestamps in an org file cannot/will-not be changed
> automatically.
>

The solution that we used in an operational scheduling system was to
invent a new family of time zones, the "Then Local Time There".  So you
would schedule something like "10:05 TLT (NorthAmerica/New York)".  This
was the most commonly used scheduled time.  It's what most people mean
when they schedule something.  Then the scheduled time encoding did not
change, but the displayed time could.  It was displayed in a format that
met the needs of the users.  When you're dealing with people in many
locations you need to separate the concept of scheduled time in the org
file from the concept of time display in a format useful to the user.

Those who wanted astronomical or other relationships would usually
specify UTC or TAI.  They might use a fixed offset for UTC.  People who
are into the demands of TAI (e.g., orbital mechanics) generally don't
want to deal with the offsets or other issues that come up with UTC, so
they wanted TAI.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Robert Horn]

Ihor Radchenko  writes:

> Robert Horn  writes:
>
>>> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>>>certain times a year or in future or in the past:
>>>- DST transitions are not stable and change from year to year
>>>  according to strange rules that may involve Julian dates or
>>>  counting weekdays
>>>- DST transition rules may change over time
>>>- The new year day itself is not necessarily fixed (England
>>>- Julian/Gregorian transitions happened at different times in
>>>  different countries
>>
>> Note that as a result "time when it happened" has different rules than
>> "future time when it is scheduled".  There are lots of other times that are
>> scheduled as "future local time, subject to changing DST rules".  This
>> is particularly tricky for repeating times for regularly scheduled events.
>
> Not really. Countries may change DST at any moment in future. Or decide
> to switch calendars (consider countries near the day transition line).
>
> And "past local time, according to the DST rules in effect at the time"
> is also an option that might be useful in certain scenarios.
>

The issue is clarity of the expected rules for the format.  If I
schedule a meeting for 10:05 DST, but the rules change so that it is not
DST at that location at that time in the future, what is the expected
interpretation?  It could be:

 a) the meeting should be at 10:05 ST, because the intent was to meet at
 10AM in the then local time.
 
 b) the meeting should be at 11:05 ST, because the time was chosen to
 correspond to a particular sun angle.

Getting the rules and explanation clear is the issue.  It's a mistake
that a great many people make with scheduling meetings.  Those two
behaviors need different encodings because they behave differently.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Robert Horn]

Ihor Radchenko  writes:

> https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> To summarize:
>
> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>certain times a year or in future or in the past:
>- DST transitions are not stable and change from year to year
>  according to strange rules that may involve Julian dates or
>  counting weekdays
>- DST transition rules may change over time
>- The new year day itself is not necessarily fixed (England
>- Julian/Gregorian transitions happened at different times in
>  different countries
>

Note that as a result "time when it happened" has different rules than
"future time when it is scheduled".  There are lots of other times that are
scheduled as "future local time, subject to changing DST rules".  This
is particularly tricky for repeating times for regularly scheduled events.

> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>astronomical Earth observations
>

Fortunately, the most recent vote reached majority for eliminating leap
seconds, hopefully within 8 years.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: Help requested: Support for basic Org mode support in tools outside of Emacs

[Robert Horn]

Karl Voit writes:

> I'm collecting information on basic Org mode support in tools that
> are not Emacs.
>

If email integration is considered support, you can add

mu (searching for mu4e will eliminate most of the false positives for
"mu" when searching)
notmuch

They both have org-mode integrations.  E.g., create an org-mode task
from within the email reader, with link back to the email.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Robert Horn]

Colin Baxter writes:

>>>>>> Robert Horn  writes:
>
> > Timothy writes:
>
> >> Ihor Radchenko  writes:
> >> 
> >> Maybe this is a good time to start a discussion about moving
> >> Org's minimum supported Emacs to 25...?
>
> > I checked Red Hat, Centos, Debian, SuSE, and Ubuntu.  They are all
> > 25.1 or later in their current distributions.  So that will
> > probably not cause too much breakage.
>
> > -- Robert Horn rjh...@alum.mit.edu
>
> Debian 9.13 (which is still supported) has emacs-24. 

Interesting question about LTS.  How far back should we consider when
estimating the impact of a change like this?  I was looking at current
stable versions to estimate the impact of the change.  Lots of users
avoid the bleeding edge distribution releases, but most update to track
the current stable/LTS releases.  Or they won't complain that it's
unfair for org to expect them to update emacs to the current stable/LTS
version.

Ubuntu, Red Hat, CentOS and SuSE are 25.1 or above for their most recent
long term support releases.  Some of these distributions go a lot
further with various forms of long term support.  I think Red Hat goes
back 8 years for example, and that emacs is really old.

It looks like 25.1 is available, but not yet the default for Debian
"stretch" (Debian 9.13), which is the "oldstable" for Debian. With
Debian backport efforts I don't know if this means months or years.  The
web page for Emacs25inStretch has not changed since 2017, so it might
never happen.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Robert Horn]

Timothy writes:

> Ihor Radchenko  writes:
>
> Maybe this is a good time to start a discussion about moving Org's
> minimum supported Emacs to 25...?

I checked Red Hat, Centos, Debian, SuSE, and Ubuntu.  They are all 25.1
or later in their current distributions.  So that will probably not
cause too much breakage.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: Headline generation as in diary?

[Robert Horn]

Eric S Fraga writes:

> On Tuesday,  1 Sep 2020 at 18:10, Robert Pluim wrote:
> * Birthdays
>
> and then a number of %%(diary-anniversary ...) entries all under this
> headline.
>

Note that you can also use %%(org-anniversary ...) with slightly
different dependencies.

I also use modifications of diary to insert sunrise and sunset.

But I think that these %% functiotns only show up as part of agenda processing.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: A small idea to simplify (further) time input in the date/time prompt

[Robert Horn]

Gustavo Barros writes:

> Hi Robert,
>
> I do appreciate your arguments.  But in reading them, I'd like to
> emphasize that I'm not in any way suggesting the timestamps be changed
> at all.  The suggestion regards exclusively adding and extra way to
> input such times in the date/time prompt.  And one which I feel is

In this context I don't mind, it's the timestamp storage that shouldn't
change.  I lost that detail in the mail trace.  It's something to make
clear and will likely cause confusion among users too.

Detlef,

the dot notation is from DIN 1355 and DIN 5008.  It was changed to use
colons in 1995 to match ISO 8601.  There are still many traditionalists
and old documents.  Look for phrases like "6.30 Uhr" in old documents.
You will find a lot like that.  I didn't like the dot notation and agreed
with the 1995 change, but it's still a reality.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: A small idea to simplify (further) time input in the date/time prompt

[Robert Horn]

Eric S Fraga writes:

> On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote:
>> So I'd like to suggest a simplification there, which is: a string in
>> the format "hour h minute" (that's small caps letter "H"), but in
>
> I would be strongly in favour of having this option.  This is how I
> write times in email messages, for instance, so would be more consistent
> for me.  And especially when I communicate with my European partners
> when referring to times after 12 noon.
>

I would be opposed.  There are already dozens of different formats used
in different situations and locations for writing the time.  This would
be yet another different time format.  It is relatively unique in that
there is no other place in the world that uses it.  I don't think that
uniqueness is an argument in its favor.

There some other formats that are actually in widespread use worldwide
that I would prefer as available alternatives:

European dot notation.  Many people use the dot rather than the colon,
so 13:05 is written as 13.05.  I think this is mostly a keyboard, pen, and
pencil thing.  Colon is harder to write.  It's inconveniently located on
many keyboards.  The problem with dot notation is potential confusion
for more detailed time.  "15:53:00.322348" is easy to guess and
understand.  "15.53.00.322348" is more confusing.

Military time, which is used in most militaries, aviation, etc.

  hhmmZ - Time in UTC on a 24-hr clock, also called "Zulu time".  The
  ISO 8601 time "11:21:00 -0400" would be 1521Z.  This is almost
  mandatory when dealing with multi-location scheduling so that everyone
  uses the same time base.
  
  hhmmJ or hhmmh - Time in local zone on a 24-hr clock.  It's widely
  used in military organizations for times that do not need
  multi-location scheduling.  The time "1121J" or "1121h" is usually
  spoken in English as "eleven twenty one hours".  These times are also
  lack the colon typing problem.  

I've not pushed for these mostly because convenience typing military
time isn't worth figuring out all the changes that would be needed.

It's worth looking at all the issues discussed in ISO 8601 and
understanding them before you leap into time formatting changes.  ISO
8601 is a compromise solution with lots of warts, but it is widely
supported and understood.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: [O] converting many ics files to a single org file

[Robert Horn]

The golang ical2org (https://github.com/rjhorniii/ical2org) definitely
does this.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: [O] please read: bug when marking tasks done

[Robert Horn]

Nicolas Goaziou writes:

> However, I also suggest to add a new hook, run after repeating
> timestamps. With this hook, and a proper, user-specific, markup, it
> should be possible to pick inactive timestamps in the section and
> "repeat" them manually, i.e., on a case-by-case basis.
>
> WDYT?
>

I like this solution.  I've got several repeating tasks that do not have
simple rules.  (For example, alternating Monday morning/Thursday evening
and adjusting for local holidays, but different rules in July and
August.)  No simple syntax will ever handle these, but I can easily
write an elisp hook to capture the rules.

--
Robert Horn
rjh...@alum.mit.edu

[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

[Robert Horn]

Nicolas Floquet writes:

> Actually, it's an ethical issue. That are not always easily solved with
> technical solutions, I guess…
>

Perhaps you could clarify the ethical issues.  The initial RMS comment
on this issue in this thread is:

/* from RMS email

Emacs should not advise people to load anything from outside Emacs
(counting ELPA).  So this needs to be deleted.

If htmlize is useful, we should put it into Emacs.
Is there some obstacle to that?

*/

I can hypothesize various ethical, marketing, operational, and user
experience reasons for not advising people to load ...

Could you explain the ethical issue(s) that are of specific concern.

Further from RMS was the suggested technical fix

/* from RMS email later in thread
To motivate people to do this, I say we shouild not ship another
release with that reference to GitHub.  Eli, do you agree?
*/

This makes it clearly the reference to Github that is the concern.  I
could accept a change such as replacing that reference with text saying
"use  to find html..."  I'm not sure what to suggest since Google,
duck-duck-go, and other search engines are all commercial non-free
operations.

Rehosting onto a free platform, perhaps gnu.org, might be an option.  A
simple mirror onto a free platform might suffice.  Linux, python, and
other major open source efforts deal with platform issues by providing
their own primary distribution platform.

I can seem some ethical concerns with using a proprietary platform.  Git
was created due to problems with a dependency on a proprietary platform,
although in that case it was more related to a divergence in business
strategic directions than ethical issues.

--
Robert Horn
rjhorn...@gmail.com

[O] ical2org release

[Robert Horn]

It's been over a week without problems, so ical2org is released at 1.0

It is a go command line program that is suitable for importing bulk Ical (.ics)
records, Ical attached to emails, and fetching Ical from google.  They
are converted into an org structured file.

Details are at https://github.com/rjhorniii/ical2org-go

The primary problem remaining is one that cannot easily be solved.
There are many sources of appointments.  They do not all implement Ical
the same way.  They do not all handle time zones the same way.  The
strategy that I used is based on the most common behavior that I've
revceived.  It does not alway work right in applying the right time to an
event.

An example of my mu4e integration and systemd integration for google
synchronization is also documented.

-- 
Robert Horn
rjhorn...@gmail.com

Re: [O] Agenda bug

[Robert Horn]

Nicolas Goaziou writes:

> Could you provide an ECM? I tried to set `org-agenda-files' to a file
> containing the three lines above, and launched an agenda view, without
> error. So, what are the steps required to exhibit a failure?

Apologies.  It's an org version problem on my end.  There is no error with org
9.1.  Somehow that machine was never upgraded or got restored to an old
version.  It was still on 8.2.

-- 
Robert Horn
rjh...@alum.mit.edu

[O] ical2org ready

[Robert Horn]

Version 0.97 of ical2org is available at
https://github.com/rjhorniii/ical2org-go.  It converts from Ical format,
e.g., .ics files, into an org-mode file.

It is feature complete.  It has been tested with ICal files from several
sources, and it is successfully processing my personal Google calendar
with a regular repeating automatic download.  It's ready for wider use.
After a few weeks use without problems reported, I'll make it a release.

For mu4e users, I've tested using attachment pipe processing with it.
It does correctly convert ics files that are attached to emails, but the
process is awkward.  There is a lot of typing.  Creating a little lisp
command for mu4e is likely the right solution.

--
Robert Horn
rjhorn...@gmail.com

Re: [O] Agenda bug

[Robert Horn]

Eric S Fraga writes:

> On Tuesday,  6 Mar 2018 at 11:23, Robert Horn wrote:
>> I discovered that the lines ( the body of a headline):
>> *** real headline
>>* example
>>:SCHEDULED: 
>>
>> cause agenda processing to fail.  It tries to parse  as a
>> timestamp.  The parser used by agenda appears not to enforce the
>> requirement that headlines begin with asterisks on the left margin.
>
> I think the issue is that SCHEDULED and DEADLINE entries must appear
> immediately after the headline.  You have a line (* example) in between
> the SCHEDULED line and the headline.

You have characterized the bug.  That ":SCHEDULED:" should not have been
considered a SCHEDULED entry.  It should have been ignored, based on the
description for org format in the manual.  

I was putting together an example for someone and was composing a full
example of an org file.  I just stumbled across this when trying various
forms of verbatim, code, and other blocks.  I was not expecting the
agenda display and processing to completely fail.

I created my example by eliminating one of the colons and explaining
that in a real org file you would need the colon.  But that
leaves the bug that this particular error causes agenda creation to
fail.  I was expecting the parser to treat the SCHEDULED line as just
more body text, and ignore it.

--
Robert Horn
rjhorn...@gmail.com

[O] Agenda bug

[Robert Horn]

I discovered that the lines ( the body of a headline):
*** real headline
   * example
   :SCHEDULED: 

cause agenda processing to fail.  It tries to parse  as a
timestamp.  The parser used by agenda appears not to enforce the
requirement that headlines begin with asterisks on the left margin.

Removing either the leading colon or the asterisk on example fixes the
problem.

Regular display parsing does not get confused.  The highlighting and
font changes do not consider the "   * example" to be a headline.

-- 
Robert Horn
rjh...@alum.mit.edu

Re: [O] Ical to org, in Go lang.

[Robert Horn]

Eric S Fraga writes:

> If you use gnus, it comes with a gnus-icalendar package which will
> convert calendar attachments to org entries.  You can export to org &
> accept/decline events.  I use this all the time.

I use mu4e, but I may steal from gnus-icalendar.

Thanks

-- 
Robert Horn
rjhorn...@gmail.com

[O] Ical to org, in Go lang.

[Robert Horn]

timestamps in the org file.

--
Robert Horn
rjhorn...@gmail.com

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Robert Horn]

Allen Li writes:

> On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter  wrote:
>
> I don’t see a use case for checking all heading data.
>

I can see such cases arising from templates and time tracking.  I can
have a template that captures telephone calls.  The call comes in and I
start the template.  At this point the heading is just "Received Phone
Call" and a time tracking start.  Time tracking is eventually kept in a
drawer, not in the headline.

I might eventually go back an revise the headline based on notes from
the call, but that will not happen during the call.  It's quite likely
that sorting out the calls will happen at the end of the day or the next
day.

Similarly, I receive lab results.  These will initially be a headline
with just "Lab Result", a time tag like CLOCK, and a tag to indicate
that it is a lab result.  Some time later I might move them around to
attach them to a patient or project, but often by just moving them as
element into the right section for that patient or project.  So these
also have the same headline contents and different headline data.

R Horn

Re: [O] How to include diary anniversary entries into default org-agenda?

[Robert Horn]

stardiviner writes:

> I have an org-mode file:
>
> #+begin_src org
> ,* Anniversary
>
> ,** my first child anniversary
>
> %%(diary-anniversary 10 26 2017)
>
> ,** Funeral Arrangement
>
> ,*** kk
>
> %%(diary-anniversary 12 8 2007)
> #+end_src
>
> How to include and show them in default org-agenda day view by 
> configuring org-mode?

Try org-anniversary.  The line

%%(org-anniversary 2016 12 20) Test anniversary

Generates an anniversary in the agenda.  In the default daily agenda it
is mixed in with the tasks and deadlines, so it may be easy to miss.

Note the order of the date elements is year, month, day and all three
are needed.  There is an option final element of type MARK what could be
used to adjust fonts and the like.

R Horn

Re: [O] Trying to get chart from table working

[Robert Horn]

Peter Davis writes:

> Basically, I want to plot a time series graph showing my PSA (prostate
> specific antigen) over time. The PSA is measured at irregular intervals,
> and has been for over 4 years (and hopefully will continue for many more
> years.) That should be a simple enough graph. I've already got a
> javascript d3 example that does this, but I'd like to embed it in a
> document, and to be able to generate PDF.
>
> Further, I want to be able to show different time intervals with tinted
> bands spanning the full range of the graph, and having specific start
> and end dates. These would represent various medical treatments I've
> undergone. I have a rough example I've mocked up in Photoshop, but, of
> course, I want to be able to add new data and re-generate the chart as
> needed. I don't know if I can attach a PNG to an email on this list.
>

I do something similar for managing diabetes.

I use org-mode to manage some (not all) of the data tables and org-babel
to control a graphics and statistics analysis in R.  R can also handle
input in other formats, such as CSV, that I get from some sources. The
results are also displayed in the org window as output from R.

This is a much heavier weight solution, since it involves learning R.  But
the graphics capabilities are immensely richer than gnuplot and the
mathematical capabilities for statistics and time series analysis are
immensely richer in R.

If learning R benefits your work or career you might explore this.

R Horn

Re: [O] Confused about the explanation for 'org-cycle'

[Robert Horn]

Nicolas Goaziou writes:

> Completeness is not possible. For example, we do not document every
> variable in the manual. Besides, when reading a pile of special rules
> for special cases, the reader may lose focus and miss the whole concept.
>
> BTW, a "docstring" is the documentation you get when using, e.g., `C-h
> v' or `C-h f'.
>

Actually, an effective way to deal with this is to have two sections: "All
external org functions" and "All external org variables" that merely lists them
all alphabetically, and begins with a short paragraph on what a
doc-string is and how to get it for these.

This might also be a place to put a short paragraph about how internal org
functions and variables are identified, and why it is a good idea to
avoid using them in added features.  E.g., the fact that they may be
replaced, removed, or revised drastically by subsequent org releases.

It's not quite as simple as doing a search for defun, pruning, and
sorting, but it shouldn't be much more than that.

This would probably help new users a lot.

R Horn

Re: [O] [ANN] Agenda speed up

[Robert Horn]

I'll note that I use %%( entries for sunset/sunrise, e.g.,
%%(diary-sunrise), and for some schedules that need logic that does "shift one
day if Monday is a holiday".

That means I will need the %%( functionality to keep working.  I suspect
I'm not alone.  These are some fairly old and stable functions that I'd
actually forgotten about until I tried org-super-agenda and noticed that
it broke them.  (Now fixed).

R Horn

[O] Issue with org-super-agenda and %%diary

[Robert Horn]

I want to have sunrise and sunset in my time grid.  I do this with two lines 
with "%%(diary-sunrise)" and "%%(diary-sunset)" in them.

With the regular org-agenda this works, e.g.,

  18:00.. 
  weather:19:42.. Sunset (EDT) :weather:
  20:00.. 

but with org-super-agenda it does not work.  The weather line is not in the 
grid.

  18:00.. 
  20:00.. 

I can add a tag criteria, but then the weather line comes after the grid:
  
  18:00.. 
  20:00.. 
  weather:19:42.. Sunset (EDT) :weather:

>From looking at the lisp, it appears that org-super expects that time grid to 
>be tagged with a text property.  Org-agenda seems to set the text property, 
>but it's sufficiently complex that I don't really understand the code.  I 
>think the problem is that by the time the results reach org-super-agenda this 
>property is not there for the sunrise/sunset lines.

It could be that it's never set for the special case of lisp execution like 
"%%(diary-sunset)" or that it is set, used by org-agenda, and then cleared.

I would like clues about where to look and/or how to fix this.

R Horn
rjh...@alum.mit.edu

Re: [O] org mode moves to GNU emacs core

[Robert Horn]

Bastien Guerry writes:

> Hi Philip,
>
> phillip.l...@russet.org.uk (Phillip Lord) writes:
>
>> I presume you do see this as an advantage? The issue is, surely,
>> that it's too much of a PITA for the advantage that you gain?
>
> Well, it's not really about PITA-or-not-PITA, it's just that I want
> org-mode to be the default mode for some files in Emacs, and having
> org-mode in Emacs' core is the most simple way to go for this.
>

I just did a quick check of my git repositories for org-mode and emacs.
There is a significant difference in release cycle policies, and this
will affect users.  Emacs makes a release about once every 9 months,
usually a point release.  Major feature releases are less frequent.
Org-mode makes a release about once per month, also usually a point
release.

I think that switching to the emacs cycle would be perceived as making
org-mode far less responsive to problem reports and feature improvements.

There are ways that the git repositories and release policies can be
organized to enable more rapid response to minor bugs and small features
while still integrating into core emacs.  I think that you should figure
out a mutually acceptable means of maintaining the present rapid
responsiveness.  With a suitable structuring of make files, etc., you
can probably also deal with the performance issues associated with
building updated versions.  The emacs maintainers would have to agree.

It does call for a little more setup work, and probably a semi-permanent
branch structure in git to allow for org updates, while gaining most of
what you want.

It would also mean that those who want to stay on the leading edge of
org-mode would need to maintain git synchronization with emacs rather
than org-mode.  With good explanation and documentation that shouldn't
be too much of a problem.  I do it already on an ad-hoc basis because I
found elpa to be too problematic.

R Horn

Re: [O] [RFC] The "c" Org macro

[Robert Horn]

Eric S Fraga writes:

> On Monday,  8 May 2017 at 11:26, Nicolas Goaziou wrote:
>> Hello,
>>
>> I would like to scratch a long-standing itch and introduce the "c"
>> macro, which is basically a way to handle multiple counters in an Org
>> document. So, the following document
>
> This sounds like a very useful macro to have.  Some suggestions:
>
> 1. I would prefer the argument to be called "COUNTER" instead of "SEED"
> as the latter is more commonly associated with random number
> generators.  This would make the documentation clearer potentially.
Yes.  I was confused by this initially.
>
> 2. I wonder if a second argument could be optionally available to allow
> the counter to start at an arbitrary number and/or be reset?
>
'm frequently preparing documents that update something with lists.
Being able to start at a specific value makes that much more useful.

R Horn

Re: [O] How do you store web pages for reference?

[Robert Horn]

There is also a Firefox plugin "ScrapBook X", which is a successor to
Scrapbook.  It can capture the web page alone (with links to outside
world) and allows you to select by depth or link additional pages
that are also to be captured.  (If you have infinite time and storage
with the right links you might attempt to capture the entire Internet.
Something like capture all pages to link depth 1000 comes to mind.)

I use it to capture a variety of things.  Each capture is stored in a
directory tree of html, css, etc. rooted at a time-date tag for when the
capture was performed.

I have not seen nor attempted to integrate it with org or any other
tools.  This is feasible in theory, since the file
/index.html is a valid page starting point and links are been
rewritten as appropriate.  Something like "firefox
scrapbook-root/20170115205014/index.html" would be a proper reference.
The more the page content becomes active content like javascript, the
less likely that the page capture will save what you want, but that's
inherent with active content.

It would be nice to capture more metadata (like Zotero), but it only
preserves minimal metadata about the capture.

R Horn
rjh...@alum.mit.edu

[O] ELPA vs 9.0.1 release (still issues)

[Robert Horn]

I'm not enough of an ELPA guru to figure this out.  I tried org-mode
9.0.1 using ELPA, found some issues I'll describe, and find that using
the direct git version does not have those issues.

All of this is with Emacs 24.5.2, GTK+ version 2.24.31.  This is a fresh
setup, no other packages installed, but my .emacs is from a working
setup.

My first test of a new version is a babel invocation of R with a large
table sent as a variable to R:

#+name: glucose_analysis
#+begin_src R :file 1.png :results graphics :var data=glucose :width 1200 
:height 600

library(ggplot2)
...

Test results:

1) The ELPA install from org repository of 20161118 had numerous compile
issues.  The immediately relevant one is:

Compiling file /home/hornrj/.emacs.d/elpa/org-20161118/org-element.el at Sun 
Nov 20 13:33:22 2016

In org-element--get-node-properties:
org-element.el:938:25:Warning: reference to free variable
`org-planning-line-re'

In org-element--get-time-properties:
org-element.el:953:45:Warning: reference to free variable
`org-planning-line-re'

In org-element--current-element:
org-element.el:3850:26:Warning: reference to free variable
`org-planning-line-re'
org-element.el:3862:21:Warning: reference to free variable `org-clock-line-re'

In end of data:
org-element.el:6124:1:Warning: the following functions are not known to be 
defined: org-link-types,
org-macro-extract-arguments


The invocation of R failed with an error that org-link-types was not
known.

2) I deleted all the .elc files in the ELPA directory

The result was an incredibly slow invocation of R.  It took 6 minutes to
parse and prepare the table.  (It's only about 2,000 line table.)  Then
it invoked R, generated the diagram, etc.  So it passed the test but was
incredibly slow.

3) I removed the ELPA installed directory, cloned the git repository,
did a "make compile" which generated no errors, and linked from elpa to
the lisp directory.

The test ran in a few seconds.

So there remains something wrong in the ELPA setup.

R Horn rjh...@alum.mit.edu

Re: [O] Why no secure code retrieval

[Robert Horn]

Konstantin Kliakhandler writes:

>
> Sufficient for what? I believe we were discussing security (that was my
> intention at least, and so did your previous email seem to indicate). And
> if this is the case, you have just contradicted yourself. I apologize for
> pointing it out so directly, and also if I misunderstood you.

Sufficient for current risk mitigation in my opinion.  You disagree.

We both agree that signed tags would be better.

Choices are based on an evaluation of risks, threats, and mitigation
costs.  Emacs has had very few security vulnerabilities
discovered. There are only 18 CVE since 2000.  None of these allowed
priviledge escalation, and the two most severe required local user
assistance.  So org-mode is not in a high risk location.

That means that I look for very low cost steps, i.e., very simple easy
changes.  Signing tags falls into that category because it only affects
a few people and is not particularly difficult to manage for very small
groups.

Another step that I would take is to establish and publish the planned
security processes.  These should be established and understood well
before any event takes place.  Taking adhoc reactive steps in an
emergency often causes more problems.

> I believe that these days elpa is accessed by default via https and that
> archives are signed, though please correct me here. Assuming it is the
> case, there isn't much one can do beyond the currently suggested steps, I
> think.
>

I took a quick look inside package.el and it is still incomplete.  It's
also got a big todo list, so I expect this to change with subsequent
releases.  As of Emacs 24.3 ELPA did not have package signatures.  Emacs
24.5 has package signatures, but no way for the user to verify that what
is installed matches the signature.

As of 24.5, the default behavior in package.el is:
 - package signatures are optional
 - package signatures are only checked to confirm that the tar file that
 is downloaded matches the signature.  There is no tooling for subsequent
 verifications.
 - invalid signatures are ignored by default
 - missing signatures are ignored by default
 - package.el has dependencies on programs external to emacs.  If these
 dependencies are not met, it reverts to default behavior.

This is clearly better than 24.3.

Again, in terms of risk/cost/mitigation evaluation I would have the tool
that creates the ELPA package for org-mode also create a signature.  It
might do that already.  Package.el does not indicate which packages are
signed.  I would let the folks taking care of ELPA deal with the rest in
later releases.

Use of https for most ELPA repositories does protect against in transit
content corruption, but not necessarily much else.  Looking at
elpa.gnu.org I notice:
 - Their certificate expired today and has not been updated, oops
 - They use Let's Encrypt as signing authority.  This means that the
 certificate verifies that whoever responds to the domain name http port
 controls the TLS certificate and web content.  That's enough for
 many purposes, but it doesn't mean much in terms of server security.

In transit MITM is a minor threat for software distribution.  I've only
detected MITM activity in public locations once in the real world.  (I
was thrilled.  It's a really rare event.)  It was in a very high threat
location (Washington DC area, a public wifi).

The big MITM threat is the dangers from malicious javascript insertion
into unprotected browser activity.

R Horn
rjh...@alum.mit.edu

Re: [O] Why no secure code retrieval

[Robert Horn]

Konstantin Kliakhandler writes:

> Hello Robert,
>
> I am the OP.
>
> For what it is worth, the current discussion is actually precisely what I
> was aiming at. I agree with your analysis of my Intended goals but
> completely disagree that SHA1 alone is any sort of guarantee.. To be
> precise, I don't just think that it doesn't provide much, but rather that
> alone it provides none at all. This is because I have no idea who produced
> a given SHA1 - whether it was Bastien, or a MITM attacker, or just someone
> who compromised the server.

The SHA1's are created by the git processes at the git server that you
connect to.  Or, in the case of a malicious source, by the malicious
source appearing to be the git server.  The SHA1's are reference
elements used throughout git, and are primarily for integrity protection
against accidents, not against attackers.  Hence it's sufficient that
they be maintained by the git processes.

The plain vanilla git process does not include distribution of SHA1
values by an independent path, so it's not easy to verify against a
trusted source for the correct values.

As Achim Gratz says:
>If the server or repo gets compromised, then it is game over
>until someone notices that the server suddenly doesn't match up the
>local clone.

The most common and appropriate next step (assuming git is used for
distribution) is to make use of PGP signing of tagged versions in git.  This is 
a
strong signature traceable to some release person or process.  It
provides strong verification and authentication for the contents of a
specific tagged release.  This protects against distribution server and repo
compromises, but not against development process compromises.

This would be a reasonable step for org-mode releases.  The release
process only involves a few people, and key management would not be too
hard.  It doesn't solve the problem for non-git distribution methods.
My guess is that the ELPA users are the most exposed.  Fixing that
really belongs to ELPA, but if I were putting together the cyber
security plan for org-mode I would call out this gap and make clear that
it is a gap that can't be easily solved by org-mode.  (Maybe tweaking
someone more familier with ELPA to tell me how to solve it for ELPA.)

Signed tags do not provide much extra protection for developers.  The
usual git process of using SSH keys to authenticate developers is much
easier to manage than individually signed changes.  It's vulnerable to
all the usual attacks.  Overall integrity depends upon the release
testing and verification process.  Signed commits can reduce these
risks.

Signed commits are a lot more work than the SSH key methods.  I doubt
that the committers have the appetite to deal with all the issues
involved.

R Horn

Re: [O] Why no secure code retrieval

[Robert Horn]

I think that the original question was looking at a different problem,
and discussion of hosted tooling may be a distraction.  The issues that
normally come up for cyber-security discussions of distribution need to
be looked at.  The following is a start at organizing those for
org-mode.

I think that the problem that started this discussion was a question
about whether an org-mode user could verify the integrity and
authenticity of an org-mode version distribution, or perhaps the
integrity and authenticity of an installed version.  It may be in the
context of ELPA for that user.  A full answer for all org-mode users
would certainly include ELPA.

I personally use a combination of "git clone" and "git checkout" to
manage my org-mode versions.  That provides adequate protection at the
moment, but SHA1 is not sufficient in the long term.

R Horn
rjh...@alum.mit.edu

 [2016-07-03 Sun 12:15] Org security
* Org cyber-security
** Process questions
*** How are security flaws discovered
 Is there a known public reporting channel?
 Are they privately and publicly tracked.
 For example, are CVE numbers obtained for public tracking, reporting, 
status, etc.
 Are patches tracked relative to CVE numbers?
 Are security-only patches and releases made?
 - For current development and release versions?
 - For widely deployed older versions?
*** Are security processes understood, maintained, staffed, performed?
** Development process related questions
   I'll let these wait for now.
** Release and Distribution process related questions
*** Org has multiple release and distribution chains.  
- The underlying git structure is used by developers and some of the 
end users
- Direct git clone is used by some, and is one distribution chain
- Git hosting is used by some.  This is git plus extra hosting 
facilities
- ELPA is used by some.
- Tar-ball distribution is still used by some
- Bundled distributions (Red Hat, Ubuntu, etc.) are used by some
- Other distribution methods can be ignored for now (in my opinion)
*** How are releases identified?
 GIT
 - GIT identifies changes and tagged releases by SHA1 hash.  SHA1 hash 
remains excellent as integrity verification against accidental damage.  SHA1 is 
end of life against intentional attack.  It is expected to be vulnerable to 
well funded attackers by 2020.
 - see also below on verification and identification
 GIT hosting
 depends on the host.  
 ELPA
 ELPA is seriously lacking, at least in terms of documentation.  This 
is probably the source of the initial user question. ELPA can identify version 
strings.
 Tar-ball
 Nothing appears to be set up for robust identification of tar balls 
for org-mode.
 Bundled distributions
 Distributions have identification systems that do not always match the 
org-mode system.
*** How does distribution process protect integrity and authentication of a 
release?
- Is there integrity check and authenticated verification from 
development release to end user installation?
- Can an end user verify the integrity and authenticate the installed 
software?
 GIT
 - GIT can provide PGP signing for tagged releases.  Org does not 
currently use this feature.  PGP signing is considered secure for integrity and 
authentication verification, provided the security processes are sufficient in 
the development release system.
 - GIT can provide PGP signing for individual updates.  Org does not 
currently use this feature.  PGP signing at the individual update level is 
often too burdensome for projects.  Every committer must be familiar with PGP 
signing and properly protect their keys.  There is a key management headache 
for project administration.
 Git Hosting
 - Depends of the hosting.  Hosted verification often changes the risks 
rather than eliminate them.  If hosting facility protection is used instead of 
git PGP signing, the risk changes from PGP management flaws into host service 
user management flaws.  Instead of PGP headaches there are the headaches from 
lost SSH keys and user spoofing.
 ELPA
 - ELPA does not appear to have any verification or authentication 
capability
 Tar-ball
 Nothing appears to be set up for verification or authentication of 
tar-balls for org-mode
 Bundled distributions
 The bundled distributions use signed packages.  Some distributions can 
verified installed packages, while others don't provide this feature.  The 
distribution chain from "bundler" to end user install is well protected.  
Protection from org-mode developer to "bundler" is unknown.
*** Update process
- When a new release is made, is integrity and authentication verified? 
to distributor? to end user? How 

Re: [O] A proposed enhancement in entering timestamps

[Robert Horn]

>>> On 2016-03-18, at 17:51, Marcin Borkowski  wrote:
>>>
 I'm now reading org-read-date-analyze to be able to enable US military
 format for hours (e.g., 2100 instead of 21:00).  This is potentially
 very useful (at least for me), since I'll be able to enter the hour with

This would be very convenient for me, but when it comes time to document
it a more proper name is 24-hour notation.  It's used by much more than
the US military.  It's standard for railway schedules in most of the
world, medical records in most of the world, aviation worldwide, and
other places.

I work mostly in 24-hr notation and putting that colon in the right
place is mistake prone.

R Horn

Re: [O] font bug in 0.9.16

[Robert Horn]

Robert Horn writes:

Apologies, sent to the wrong list

R Horn
-- 
Sent with my mu4e

[O] font bug in 0.9.16

[Robert Horn]

I just tried 0.9.16 by

1) clone from github
2) git checkout v0.9.16
3) make install
4) start fresh emacs
5) M-x mu4e
6) "bt"

when displaying a non-empty headers from search (e.g., "bt" or "bu" when
unread mail is present, I get the following

Debugger entered--Lisp error: (void-function add-face-text-property)
  add-face-text-property(0 63 mu4e-header-face t #("08:31:05 PM  S  
   Robert Horn+ testing" 0 11 (help-echo "Mon 25 Jan 2016 08:31:05 
PM EST") 13 14 (help-echo "(seen)")))
  mu4e~headers-line-apply-flag-face((:docid 163426 :thread (:path "00" :level 0 
:has-child t) :subject "testing" :from (("Robert Horn" . 
"rjh...@alum.mit.edu")) :to ((nil . "rjh...@alum.mit.edu")) :date (22182 52313 
0) :size 284 :message-id "m3k2mx6s9y@alum.mit.edu" :path 
"/home/other-disk/hornrj/mail/sent/cur/20160125-a57c19-quad:2,S" :maildir 
"/sent" :priority normal :flags (seen)) #("08:31:05 PM  S 
Robert Horn+ testing" 0 11 (help-echo "Mon 25 Jan 2016 08:31:05 PM 
EST") 13 14 (help-echo "(seen)")))
  mu4e~headers-line-handler((:docid 163426 :thread (:path "00" :level 0 
:has-child t) :subject "testing" :from (("Robert Horn" . 
"rjh...@alum.mit.edu")) :to ((nil . "rjh...@alum.mit.edu")) :date (22182 52313 
0) :size 284 :message-id "m3k2mx6s9y@alum.mit.edu" :path 
"/home/other-disk/hornrj/mail/sent/cur/20160125-a57c19-quad:2,S" :maildir 
"/sent" :priority normal :flags (seen)) #("08:31:05 PM  S     
Robert Horn+ testing" 0 11 (help-echo "Mon 25 Jan 2016 08:31:05 PM 
EST") 13 14 (help-echo "(seen)")))
  mu4e~headers-header-handler((:docid 163426 :thread (:path "00" :level 0 
:has-child t) :subject "testing" :from (("Robert Horn" . 
"rjh...@alum.mit.edu")) :to ((nil . "rjh...@alum.mit.edu")) :date (22182 52313 
0) :size 284 :message-id "m3k2mx6s9y@alum.mit.edu" :path 
"/home/other-disk/hornrj/mail/sent/cur/20160125-a57c19-quad:2,S" :maildir 
"/sent" :priority normal :flags (seen)))
  byte-code("\306   \205
\307\310\311   #\210\312   \313\"\203\n   
!\210\202
\312  \314\"\203+\312\314\"!\210\202
\312
\315\"\203<\f\312   \315\"!\210\202
\312\316\"\203I
 \210\202
\312  \317\"\203_&\312   \320\"\312  \321\"\"\210\202
\312   
\322\"\203q'\312   \323\"!\210\202
\324\325\"\203\203(\312
\325\"!\210\202
\312\326\"\203\231)\312\326\"\312  
\327\"\"\210\202
\312   \330\"\203\253*\312\330\"!\210\202
\312
\331\"\203\305+\312\331\"\312  \332\"\312  \333\"#\210\202
\312
\334\"\203\343,\312\334\"\312  \335\"\312  \320\"\312  
\336\"$\210\202
\312\337\"\203\362-!\210\202
\312  
\340\"\203.\312   \340\"\312  \341\"\"\210\202
\342\343   
\"\210\306\344\345\217\211\204\306)\207" [inhibit-quit sexp mu4e-header-func 
mu4e-found-func mu4e-view-func mu4e-erase-func nil mu4e-log from-server "%S" 
plist-get :date :found :view :erase :sent :docid :path :pong :props 
plist-member :contacts :update :move :remove :compose :original :include :temp 
:what :param :info :error :message mu4e-message "Unexpected data from server 
[%S]" (byte-code "\305  \"\306\211\211\205;\307\310\311\"\312\"   
 G\313\225\\Y\205;  \313\225\306O\314\315   \313O\316\317#!\211\205;  
 \306O\n@+\207" [mu4e~cookie-matcher-rx mu4e~proc-buf objcons sexp-len b 
string-match nil string-to-number match-string 1 16 0 read-from-string 
decode-coding-string utf-8 t] 6) ((error)) mu4e-sent-func mu4e-pong-func 
mu4e-contacts-func mu4e-update-func mu4e-remove-func mu4e-compose-func 
mu4e-temp-func mu4e-info-func mu4e-error-func] 8)
  mu4e~proc-filter(# "\376172\377(\n  :docid
  163426\n  :thread (:path \"00\" :level 0 :has-child t)\n  :subject
  \"testing\"\n :from ((\"Robert Horn\" . \"rjh...@alum.mit.edu\"))\n
  :to ((nil . \"rjh...@alum.mit.edu\"))\n   :date (22182 52313 0)\n
  :size 284\n   :message-id \"m3k2mx6s9y@alum.mit.edu\"\n   :path
  \"/home/other-disk/hornrj/mail/sent/cur/20160125-a57c19-quad:2,S\"\n
  :maildir \"/sent\"\n  :priority normal\n  :flags
  (seen)\n)\n\n\376199\377(\n   :docid 163427\n :thread (:path \"00:00\"
  :level 1 :first-child t :duplicate t)\n   :subject \"testing\"\n
  :from ((\"Rob

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

[Robert Horn]

Bastien Guerry writes:

 My simple point is: let's get more information and let's take a
 proper decision.  Let's not force the change.

I took a look at what is presently supported by Red Hat, Ubuntu, and
OpenSuSE in their long term support releases.  The results:

emacs 23.1 (RHEL 6.0, Ubuntu 12.04 LTS)
emacs 24.3 (OpenSUSE 13.x, RHEL 7, Ubuntu 14.04 LTS)
emacs 24.5 (OpenSUSE latest rolling, SUSE SLE-12)

In my opinion the goal of Org should be to run on the oldest version of
emacs that includes features needed by Org.  The long term support
versions are indicative of what we should expect from the
non-experimental users who just need Org to work.  They are not
exploratory development users.

Since three major distributions are still at emacs 24.3 for their most
recent long term support versions, that argues for Org not going beyond
24.3.  It's reasonable to expect the non-experimental not bleeding edge
users to be one the most recent long term support version.

-- 
Sent with my mu4e

Re: [O] How to extract TODOs from date-tree

[Robert Horn]

Jay Iyer writes:

 If there are use cases out there, it might be worth collecting them and
 then thinking about how to support them better. If there aren't, maybe
 it should be thrown out.

It's most definitely useful.  I'm not sure what you think would be
better.  I make extensive use of date tree for maintaining various log
book journals.  I've got various capture templates set up so that the
two characters: F* char take me to the right file and date tree.  I
type in the note, then C-c C-c takes me back where I had been
previously.  The template capures the date and time for the note, plus
other context information per the template.  This creates very nice time
tagged logs.

The only gap that I see, and it's minor, is that there is just one date
tree per file.  

R Horn

Re: [O] org-cook

[Robert Horn]

I also use tables, and have one big recipe.org file.  I considered
ingredient properties, etc., but ended up just text and find recipes by
using simple searches.  They look like this:

* Texas Skillet Corn Bread

| Ingredient | Quantity | Instructions|
|+--+-|
| Bacon drippings or oil | 1/4 cup  | |
| Yellow CornMeal| 1 cup| |
| All Purpose Flour  | 1 cup| |
| Salt   | 1/2 tsp  | |
| Baking Power   | 1 tsp| |
| Baking Soda| 1 tsp| |
| Sugar  | 1 tbs| optional|
| Buttermilk | 1 cup| |
| Eggs   | 2| slightly beaten |
|+--+-|

  1. Heat drippings in iron skillet

  2. In large mixing bowl, mix cornmeal, flour, salt, baking x, and sugar.

  3. Add buttermilk and stir rapidly.

  4. Add eggs and mix

  5. Add drippings

  6. Pour into skillet, cover, and cook on low heat until lightly
 browned and almost cooked through.

Re: [O] link interfering with brackets when abbreviated

[Robert Horn]

I'm a user who doesn't much care about link following command behavior,
but Bastien's point about context is important.  The behavior of a
command needs to depend upon much more than just syntax.

Two really dramatic examples are region narrowing and outline folding.
When operating on a narrowed region there are a great many differences
in how commands behave.  Similarly, when a headline is folded, commands
behave very differently.

So be very careful to include consideration of the context when defining
commands. Some context is much more subtle.

My one link related comment is that I'm very puzzled by those who think
that links in comments should not be followed.  In programs I make heavy
use of links in comments so that the comment can include a see this
[document] as part of the comment.  It's a link that other programmers
want to follow.  I don't often put comments into my org files, but I
would expect to follow links in them also.  In programming a comment
means don't try to compile or execute this.  It doesn't mean
destruction of all other semantic value.  It means a highly selective
removal of semantics.

I would expect links in comments to still be followable.

R Horn

Re: [O] [SYNC] How do you sync your org-mode files between n devices (n 2)

[Robert Horn]

Alan Schmitt writes:

 I can't promise anything, but I can try to write something. What
 external merging tool should I use?


There was some work done in a Summer of Code last year or the year
before.  I don't know how much more work remains.  It was an effort for
a delta operator for git.

I use a multi-system git environment, and the one area that is beyond
the git capabilities at present is the following kind of problem:

There is a repeating daily task with a log file.  On machine A, the task
is finished on Monday, Wednesday, and Friday.  On machine B, the task is
finished on Tuesday, Thursday, and Saturday.

Git does not understand the task structure, nor does it understand date
oriented logs.  It recognizes that there is a stretch of logfile and
task structure that needs my human intervention and leaves that part for
me to fix.  I have to cut the log entries from machine A version and put them
into the log from machine B version in proper date order.  The last
complete and next lines will come from machine B because they are more
recent.  I understand the date orientation, task structure, etc.  Git
does not.

Proper understanding of things like interleaving date related entries is
a difficult task to get right.  It would be enough to get it 80% right
with 0% improper fixes, and 20% identified for human merging.  But to
reach this level means understanding all the different users of date
tagged lines, entries, headlines, etc. in the org structure.

R Horn

Re: [O] Extending org-contacts with properties: naming properties

[Robert Horn]

Karl Voit writes:

 * David Rogers davidandrewrog...@gmail.com wrote:

 I agree that this kind of simple thing looks like a better
 idea. However, it would also be nice to be able to call it some name
 where a person who encounters the software capability but doesn't yet
 know what it's for will understand what it's for just from reading the
 name. 

 This is my goal, yes.

 Given is simple and sounds clear, but it doesn't say who did the
 giving so the clarity is over-rated. CustomerInfoIGaveThem is a bit
 long. :) (and TheirRecordOfMe is hardly any better.) :)


My first reaction was to use a short sentence like itoldthem.  I can't
think of any single english word that doesn't also need a subject to
describe which direction the transfer went.

R Horn

Re: [O] possible org-insert-heading bug?

[Robert Horn]

I've noticed a probably related bug.  In a file like

* before
  break between

If I put the cursor between break and between, M-ret causes the result

* before
* break between

rather than what I expected:

* before
  break
* between

With the holiday coming I might look at it also and figure out what is
happening.

R Horn

Carsten Dominik writes:

 Hi,

 yes, org-insert-heading is broken - nad I am trying to find time
 to rewrite it.  My top Org priority.

 - Carsten

 On 3.7.2013, at 00:11, John Hendy jw.he...@gmail.com wrote:

 Hi Erik,
 
 
 Glad to see you around :)
 
 These all may be quite related. I haven't seen activity on those
 threads suggesting whether a) the documentation is, in fact, right or
 wrong or b) whether anyone has taken action to fix or adjust the
 behavior of M-RET or C-RET based on the complaints/counter-intuitive
 observations.
 
 Let me know if those are similar to your issue. Perhaps Bastien can
 comment on the state of these thread, now at least four in number...
 
 - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg70718.html
 - http://osdir.com/ml/emacs-orgmode-gnu/2013-05/msg00846.html
 - http://permalink.gmane.org/gmane.emacs.orgmode/72399
 
 I've taken to using C-RET in the meantime, as it seems to do what I
 often expect when reflexively pressing M-RET. Also, someone once
 corrected me on the documentation that at the end of the line might
 mean before the ellipsis, not after?
 
 
 Hope that helps!
 John
 
 
 On Tue, Jul 2, 2013 at 1:53 PM, Erik Iverson erikriver...@gmail.com wrote:
 Hello,
 
 I am using a current git pull (Org-mode version 8.0.3,
 release_8.0.3-345-g239aa7) and noticed behavior that's easiest to show
 with a small example. If you save and visit the following org file,
 
 https://dl.dropboxusercontent.com/u/7514404/test.org
 
 you will see the behavior described and documented (assuming it's
 reproducible under your version of emacs and orgmode).
 
 Briefly M-RET at the end of a *folded* headline that contains plain
 list items will insert a new plain list item at the end of the
 subtree, instead of a new top-level headline. I believe this conflicts
 with the documentation for M-RET, which currently reads:
 
 ... If the command is used at the end of a folded subtree (i.e.,
 behind the ellipses at the end of a headline), then a headline like
 the current one will be inserted after the end of the subtree...
 
 Best,
 --Erik
 
 

Re: [O] possible org-insert-heading bug?

[Robert Horn]

Erik Iverson writes:

 Robert,

 I noticed that behavior, too. But that does seem documented under M-RET:

 When this command is used in the middle of a line, the line is split
 and the rest of the line becomes the new item or headline.

 Footnote 10 is referenced, which says:

 If you do not want the line to be split, customize the variable
 org-M-RET-may-split-line.


That's what I wanted and expected.  That's not what happened.  The line
was not split.  The whole line became a new headline.  What I wanted was
the line to be split and the tail end to be the new headline.

 I've noticed a probably related bug.  In a file like

 * before
   break between

 If I put the cursor between break and between, M-ret causes the result

 * before
 * break between

 rather than what I expected:

 * before
   break
 * between

 With the holiday coming I might look at it also and figure out what is
 happening.

 R Horn

 Carsten Dominik writes:

 Hi,

 yes, org-insert-heading is broken - nad I am trying to find time
 to rewrite it.  My top Org priority.

 - Carsten

 On 3.7.2013, at 00:11, John Hendy jw.he...@gmail.com wrote:

 Hi Erik,


 Glad to see you around :)

 These all may be quite related. I haven't seen activity on those
 threads suggesting whether a) the documentation is, in fact, right or
 wrong or b) whether anyone has taken action to fix or adjust the
 behavior of M-RET or C-RET based on the complaints/counter-intuitive
 observations.

 Let me know if those are similar to your issue. Perhaps Bastien can
 comment on the state of these thread, now at least four in number...

 - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg70718.html
 - http://osdir.com/ml/emacs-orgmode-gnu/2013-05/msg00846.html
 - http://permalink.gmane.org/gmane.emacs.orgmode/72399

 I've taken to using C-RET in the meantime, as it seems to do what I
 often expect when reflexively pressing M-RET. Also, someone once
 corrected me on the documentation that at the end of the line might
 mean before the ellipsis, not after?


 Hope that helps!
 John


 On Tue, Jul 2, 2013 at 1:53 PM, Erik Iverson erikriver...@gmail.com 
 wrote:
 Hello,

 I am using a current git pull (Org-mode version 8.0.3,
 release_8.0.3-345-g239aa7) and noticed behavior that's easiest to show
 with a small example. If you save and visit the following org file,

 https://dl.dropboxusercontent.com/u/7514404/test.org

 you will see the behavior described and documented (assuming it's
 reproducible under your version of emacs and orgmode).

 Briefly M-RET at the end of a *folded* headline that contains plain
 list items will insert a new plain list item at the end of the
 subtree, instead of a new top-level headline. I believe this conflicts
 with the documentation for M-RET, which currently reads:

 ... If the command is used at the end of a folded subtree (i.e.,
 behind the ellipses at the end of a headline), then a headline like
 the current one will be inserted after the end of the subtree...

 Best,
 --Erik

[O] org-checklist warning/elpa related?

[Robert Horn]

I'm getting warnings about org-checklist that don't seem to be related
to any real problem.  I've noticed no functional problems with
org-checklist.

This is with org elpa 20130522.  I get the following warnings in
*Messages* when I change emacs color themes.

Auto-saving...done   --- harmless automatic save
Invalid face reference: nil [4 times]  --- from themes with glitches
Problems while trying to load feature `org-checklist'
Auto-saving...  --- automatic save, with no face warning from good themes
Problems while trying to load feature `org-checklist'

I'm not sure what is causing the Problems while trying to load feature
'org-checklist'.  

Whatever it is does not seem to have any affect on proper behavior of
checklists in org, so I suspect some packaging or elpa related issue.

R Horn

Re: [O] posting guide?

[Robert Horn]

Bastien writes:

 No objection of course, but it feels both formal and empty to me.


I share Bastien's opinion.  My experience with community building is
that describing and rewarding exemplary behavior is much more useful
than attempting to set strict rules of behavior.  You need some basic
rules, but then emphasize describing excellence.

It's much better for people trying be be like her, because everyone
respects and honors her, rather than following some set of detailed
rules.

R Horn
rjh...@alum.mit.edu

Re: [O] Always use utf-8 for HTML export (No support for other coding systems)

[Robert Horn]

Achim Gratz writes:

 Jambunathan K writes:
 Always use utf-8 for HTML export (No support for other coding systems).

 For or against.  Please register your views.

 It is becoming more rare these days, but still possible that the
 document encoding cannot be UTF-8 for whatever reason.  So if it's not
 unduly complicating things, I'd suggest to avoid prescribing the UTF-8
 encoding for any and all exports.


Chinese law mandates use of GB-18030, not UTF-8.  The two are losslessly
and unambiguously convertable, but their bit encodings are different.
They are accustomed to dealing with UTF-8 from other parts of the world,
but might prefer to generate local pages in compliance with the law.

R Horn
rjh...@alum.mit.edu

Re: [O] Prefix arguments, checklists, and lists

[Robert Horn]

Nicolas Goaziou writes:

 Hello,

 Robert Horn rjh...@alum.mit.edu writes:

 As a rule of thumb, C-c C-c on a list will operate on every top level
 items and C-c C-c on a item will operate on the item. You are considered
 to be on a list when calling C-c C-c from affiliated keywords or from
 the very beginning of the first line in the first item. Note that
 element-wise navigation (like M-{ and M-}) behaves the same.


This is different than your initial response, and still needs to be
documented.  My major concern (and the bug that Bastien fixed) was that
it was applying the whole list logic whenever the point was on the first
*item* of the list.  Restricting it to being different when on the first
*character of the first item* is different, and at least allows the
commands to be used on the first line.

I still think it's poor user interface design.  The impact when you go
through the documentation for each command and add ... except when on
the first character of the first item of the list, in which case the
behavior is  may make this clear.  The user has to add that into
their thought processes when using lists.  This constant side nag of
where am I on this line? which item am I on? is an indication of a
user interface problem.

The other times that emacs and org-mode care about where you are on the
line are situations where you are directly editing and changing the
contents of the line.  It feels natural to pay attention to the location
on the line when editing the text.  And, even then, the change is
restricted to that location on the line.  It is only when using a
prefixed commands that the changes affect other locations.

That's why I prefer using a different prefix to mean whole list.  That
leaves all of the list related commands that affect the current item to
be C-u prefixed.  If you have a different prefix that means whole
list, you eliminate the where is the point? mental effort.  It adds
the ability to have that different prefix enable whole list when on
any item in any location in the list.

R Horn
rjh...@alum.mit.edu

Re: [O] Prefix arguments, checklists, and lists

[Robert Horn]

Nicolas Goaziou n.goaz...@gmail.com writes:

 I plan to rewrite C-c C-c using Elements, so the behaviour will slightly
 change.

 It will be better to discuss about checkboxes when this change is done.


I've got no problem waiting, but it would be a good idea to figure out a
consistent non-contradictory key-binding in advance, so you can switch
to that when you make the other changes.

R Horn
rjh...@alum.mit.edu

[O] Prefix arguments, checklists, and lists

[Robert Horn]

The keystroke bindings for lists need some examination and repair.  In 7.9.3 
the situation is:

| Keystrokes  | First Item| Any other item  
  |
|-+---+---|
| C-c C-c | Toggle completion this item   | Toggle this item
  |
| C-u C-c C-c | Toggle checkbox on/off whole list | Toggle checkbox 
this item |
| C-u C-u C-c C-c | Set in-progess whole list | Set in-progress 
this item |
| M-- C-c C-c | Toggle completion whole list  | Toggle this item
  |
| M-- C-u C-c C-c | Toggle completion whole list  | Toggle this item
  |
| M-- C-u C-u C-c C-c | Toggle completion whole list  | Toggle this item
  |


Is this what is really intended?  The present behavior has the odd result that 
there is no sequence to toggle presence of checkbox for the first item, and 
there is no sequence to set in-progress for the first item.  The first item 
must be manually edited.  (Or maybe there's another sequence that I haven't 
found.)

I think this is a bug.  But the intended behavior is unclear, and the proper 
fix is unclear. 

I personally find that I want to apply a change to individual items far more 
often than I want to change the whole list.  So I would pick the prefixes C-u 
and C-u C-u for the single item behavior in all cases, and add a different 
prefix to mean apply to whole list.  Perhaps a numeric prefix of -1?  
That's not unreasonably hard to type.  Then toggling checkbox presence for the 
whole list would be M-- C-u C-c C-c, and toggling the whole list for 
in-progress would be M-- C-u C-u C-c C-c.  The user mental model becomes M-- 
means apply to whole list, which means tracking down any other relevant 
commands and fixing them too. The current implementation is close to this.


R Horn
rjh...@alum.mit.edu

[O] Checklist bug in version 7.9.3a

[Robert Horn]

There is a bug in checklist handling.  The following list will show the problem.

1. [ ] Use Cases
2. [ ] Threat Model
3. [ ] ITI Wiki
4. [ ] Maynard stuff
5. [ ] Annual Transition
  - wiki changes
  - ftp changes

Context:

Org-mode version 7.9.3a (release_7.9.3a @ 
/home/hornrj/.emacs.d/src/org-mode/lisp/)

Git commit 4cac751536e9e75f822fae18d75de6df694c8f6f

GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-11-08 on 
lakoocha, modified by Debian

How to reproduce:

If you go to the first line in the list of check boxes, line Use Cases, and 
use C-u C-u C-c C-c, it will set all of the checkboxes in the list to partial 
[-].  If you try it again you get the error user-error: Cannot toggle this 
checkbox (uncheccked subitems?).  If the checkbox has an [X] for complete, 
C-u C-u C-c C-c will also set the entire list to partial.

This only occurs for the first item on a checkbox list.  C-u C-u C-c C-c 
behaves properly for all the other items.

I suspect a context confusion, since the bulk change to [-] also changes the 
indent level for the two non-checkbox items in the list below item 5.

R Horn
rjh...@alum.mit.edu

Re: [O] Checklist bug in version 7.9.3a

[Robert Horn]

Nicolas Goaziou n.goaz...@gmail.com writes:


 Calling C-c C-c with an argument on the first item of a list or sub-list
 will apply the change on every item in the list. It looks consistent
 with what you get.

 What did you expect instead ?


I was expecting the single checklist item to go to [-].  On all other
items of a checklist C-u C-u C-c C-c causes the item to be changed to
[-].  That's the behavior described in section 5.6 for checkboxes.  

In 2.7 Plain Lists, it says C-c C-c toggles the state of a checkbox (if
any).  There is no mention of arguments.  

R Horn

Re: [O] Babel related bug in elpa version 20121231

[Robert Horn]

Bastien b...@altern.org writes:


 I also wish Emacs can read an ~/.emacs.org init file.

That is what the starterkit for emacs 24 is attempting to do.  It's got
a ~/init.el that is just
#+begin_src emacs-lisp
(setq starter-kit-dir
  (file-name-directory (or load-file-name (buffer-file-name

;; load up the starter kit
(org-babel-load-file (expand-file-name starter-kit.org
starter-kit-dir))
#+end_src

All of my problems seem to arise from the bad interactions between
starting with the built-in package version of org that is used by the
org-babel-load-file, and then transitioning part way through its
execution of the starter-kit.org to the elpa updated version of org.
The result is much like a mixed version install of org.  Strange things
go wrong.

I like having the nicely formatted and documented setup that I get with
an export to html of the org files that contain the startup scripts. My
intended mode of operation is to have a customized set of starterkit.org
files that can apply to everyone, with each user also having a
~/.emacs.d/user.org and a ~/.emacs.d/machine.org to provide further
user customizations, including per machine variations for users who need
different setups on different machines.

R Horn
rjh...@alum.mit.edu

Re: [O] Babel related bug in elpa version 20121231

[Robert Horn]

Eric Schulte schulte.e...@gmail.com writes:
 That sounds like it should work, although I would go with the more
 complete but possibly overkill

 ;; emacs-lisp
 (package-initialize)
 (require 'org)
 (org-reload)

 Let me know if either of the above is sufficient to solve your problem
 and ensure that only the latest ELPA version of Org-mode is used through
 the entire startup process.  If so I will add this to the starter kit.


Eric, 
That seems to have dealt with the problems that showed up in my initial
tests.  I put it into the init.el as the very first things run.  Thanks.

I think it's more than the git submission.  One of the things that was
failing was subsequent tangling, which was likely disrupted by the
inconsistent versions of org files.

Achim,
The problem is started (and then becomes permanent) when I edited one of
the org files.  This is what caused org processing to be attempted.  Of
course once in that state, it tries to tangle every time.

R Horn
rjh...@alum.mit.edu

Re: [O] Babel related bug in elpa version 20121231

[Robert Horn]

Achim Gratz strom...@nexgo.de writes:

 Robert Horn writes:
 I'm experimenting with starterkit on a new machine and have run into a
 bug in org-mode elpa version 20121231.

 Using two systems that hook into Emacs' startup sequence simultaneously
 is asking for trouble.  It may be solveable by carefully orchestrating
 which step gets done when, but in the long run this doesn't seem
 manageable to me.

I got things working by replacing the emacs lisp/org directory with a
link to my git controlled org/lisp directory.  I should eventually
replace this with a setup using the makefiles to install updated
versions of org.  Other experiments confirm that the combination of
starterkit's automagic updating with elpa leads to problems at least for
org-mode.  For account and protections convenience it is easier to use
the link rather than the makefiles until I've got the new system all
properly configured.

Starterkit does have code that looked correct and proper for
coordinating the init with elpa, and I think that for packages not
used by org-mode it will be OK.  But, the automagic startup executes the
lisp code using babel from org files.  This means that org and it's
dependencies are partially loaded before elpa is initialized.  This
means problems for org and any other dependent packages.  

I think the long term solution will have to be abandoning the automagic
startup.  If there were a compile and install operation in starterkit
to take the org files and use babel to convert them into elc, it would
be a little bit less magic for the novice user, but it would eliminate
this interaction between it and elpa.  I do expect novice users to use
the package mechanism, so they will run into this problem if they want a
more recent version of org-mode than is packaged with their emacs.

For now it's working for me.  I don't know what direction the maintainer
of starterkit will feel like taking.

R Horn
rjh...@alum.mit.edu

Re: [O] Babel related bug in elpa version 20121231

[Robert Horn]

Robert Horn rjh...@alum.mit.edu writes:

 I'm experimenting with starterkit on a new machine and have run into a
 bug in org-mode elpa version 20121231.

 With the stock distribution org-mode (7.8.11) in emacs 24.2 there is no
 problem.  With the elpa version 20121231 I get an error, see the
 attached output from emacs --debug-init.


And I can partially answer myself.  The issue is with starterkit, not
org-mode.

It looks like starter-kit uses org-ob.el prior to package-initialize.
This works properly if the initial distribution .elc files match the end
result after elpa package processing.  If not, there is a mess
equivalent to a version mismatch, although it does not get detected by
org-version.

That doesn't solve my problem, but it explains the attempts to use
undefined functions.  I guess I have to actually understand the
starterkit initialization and try to fix it.  

R Horn
rjh...@alum.mit.edu

[O] Babel related bug in elpa version 20121231

[Robert Horn]

I'm experimenting with starterkit on a new machine and have run into a
bug in org-mode elpa version 20121231.

With the stock distribution org-mode (7.8.11) in emacs 24.2 there is no
problem.  With the elpa version 20121231 I get an error, see the
attached output from emacs --debug-init.

It's not clear to me why the condition is failing in
org-babel-strip-protective-commas.  This works properly in 7.8.11. It
shouldn't be taking the path that leads to org-strip-protective-commas.

The environment is the unmodified git repository for the
emacs24-starter-kit, and this error is from the first #+begin_src
emacs-lisp in the personalized startup file.  

This work is on a new machine.  It doesn't have the org-mode git
repository readily available.  If there is an easy way to get
intermediate versions from elpa I can try those relatively easily to
isolate the change that triggers this error better.

For now the workaround is to revert the org-mode package, get the
startups the way I want them, and then re-activate the org-mode
package.

R Horn
rjh...@alum.mit.edu

Debugger entered--Lisp error: (void-function org-strip-protective-commas)
  org-strip-protective-commas(1 77)
  org-babel-strip-protective-commas((add-hook 'text-mode-hook\n
  '(lambda () (visual-line-mode))) emacs-lisp)
  org-babel-parse-src-block-match()
  org-babel-get-src-block-info(light)
  org-babel-tangle-collect-blocks(emacs-lisp)
  org-babel-tangle(nil /home/hornrj/.emacs.d/hornrj.el emacs-lisp)
  org-babel-tangle-file(/home/hornrj/.emacs.d/hornrj.org 
/home/hornrj/.emacs.d/hornrj.el emacs-lisp)
  org-babel-load-file(/home/hornrj/.emacs.d/hornrj.org)
  (cond ((file-exists-p encrypted-org) (org-babel-load-file encrypted-org)) 
((file-exists-p encrypted-el) (load encrypted-el)) ((file-exists-p literate) 
(org-babel-load-file literate)) ((file-exists-p plain) (load plain)))
  (let* ((path (expand-file-name base starter-kit-dir)) (literate (concat path 
.org)) (encrypted-org (concat path .org.gpg)) (plain (concat path .el)) 
(encrypted-el (concat path .el.gpg))) (cond ((file-exists-p encrypted-org) 
(org-babel-load-file encrypted-org)) ((file-exists-p encrypted-el) (load 
encrypted-el)) ((file-exists-p literate) (org-babel-load-file literate)) 
((file-exists-p plain) (load plain
  (catch (quote --cl-block-sk-load--) (let* ((path (expand-file-name base 
starter-kit-dir)) (literate (concat path .org)) (encrypted-org (concat path 
.org.gpg)) (plain (concat path .el)) (encrypted-el (concat path 
.el.gpg))) (cond ((file-exists-p encrypted-org) (org-babel-load-file 
encrypted-org)) ((file-exists-p encrypted-el) (load encrypted-el)) 
((file-exists-p literate) (org-babel-load-file literate)) ((file-exists-p 
plain) (load plain)
  (cl-block-wrapper (catch (quote --cl-block-sk-load--) (let* ((path 
(expand-file-name base starter-kit-dir)) (literate (concat path .org)) 
(encrypted-org (concat path .org.gpg)) (plain (concat path .el)) 
(encrypted-el (concat path .el.gpg))) (cond ((file-exists-p encrypted-org) 
(org-babel-load-file encrypted-org)) ((file-exists-p encrypted-el) (load 
encrypted-el)) ((file-exists-p literate) (org-babel-load-file literate)) 
((file-exists-p plain) (load plain))
  (block sk-load (let* ((path (expand-file-name base starter-kit-dir)) 
(literate (concat path .org)) (encrypted-org (concat path .org.gpg)) (plain 
(concat path .el)) (encrypted-el (concat path .el.gpg))) (cond 
((file-exists-p encrypted-org) (org-babel-load-file encrypted-org)) 
((file-exists-p encrypted-el) (load encrypted-el)) ((file-exists-p literate) 
(org-babel-load-file literate)) ((file-exists-p plain) (load plain)
  sk-load(hornrj)
  (let ((elisp-dir (expand-file-name src starter-kit-dir)) (user-dir 
(expand-file-name user-login-name starter-kit-dir))) (add-to-list (quote 
load-path) elisp-dir) (when (file-exists-p elisp-dir) (let ((default-directory 
elisp-dir)) (normal-top-level-add-subdirs-to-load-path))) (sk-load system-name) 
(sk-load user-login-name) (when (file-exists-p user-dir) (add-to-list (quote 
load-path) user-dir) (mapc (function sk-load) (remove-duplicates (mapcar 
(function remove-extension) (directory-files user-dir t 
.*.\\(org\\|el\\)\\(\\.gpg\\)?$)) :test (function string=)
  (progn (fset (quote remove-extension) (function* (lambda (name) (block 
remove-extension (string-match 
\\(.*?\\).\\(org\\(\\.el\\)?\\|el\\)\\(\\.gpg\\)?$ name) (match-string 1 
name) (let ((elisp-dir (expand-file-name src starter-kit-dir)) (user-dir 
(expand-file-name user-login-name starter-kit-dir))) (add-to-list (quote 
load-path) elisp-dir) (when (file-exists-p elisp-dir) (let ((default-directory 
elisp-dir)) (normal-top-level-add-subdirs-to-load-path))) (sk-load system-name) 
(sk-load user-login-name) (when (file-exists-p user-dir) (add-to-list (quote 
load-path) user-dir) (mapc (function sk-load) (remove-duplicates (mapcar 
(function remove-extension) (directory-files user-dir t 
.*.\\(org\\|el\\)\\(\\.gpg\\)?$)) :test 

[O] Agenda priority setting bad feature

[Robert Horn]

I think that the key mapping for , and C-c, in agenda is a mistake
and should be swapped.  In the normal org-mode, C-c , is mapped to
org-priority.  In agenda mode this gets changed to
org-agenda-show-priority. In agenda mode , is mapped to
org-agenda-priority, which behaves like org-priority.
This is very confusing.

We should swap the mapping or find some other mapping for
org-agenda-show-priority. That doesn't confuse the keystroke memory of
users or introduce an inconsistency between modes.  If agenda mode was
all that we had to deal with, this would not be an issue.  But it's more
important to keep things consistent within org-mode.  

Sorry for missing any earlier discussion of this.  I didn't notice a
proposal to introduce keystroke meaning inconsistency within org-mode.

This change appeared between 7.8.11 and 7.9.

R Horn

[O] Patch to change agenda key-mapping

[Robert Horn]

I forgot to attach a proposed patch.  This changes the keymapping for
C-c , to use org-agenda-priority.  It doesn't include a new keymapping
to org-agenda-show-priority.  I'm not sure what key mapping makes the
most sense.  It leaves the agenda menu and mouse functions for
org-agenda-show-priority unchanged.

I'm not concerned about the revised code or new functionality.  I just
want to avoid having to remember which sub-mode within org-mode I'm
using when I set a task priority.



agenda-patch
Description: Diff to revert C-c , mapping for priority setting in agenda

R Horn
rjh...@alum.mit.edu

Re: [O] Agenda priority setting bad feature

[Robert Horn]

FBastien b...@altern.org writes:

 Robert Horn rjh...@alum.mit.edu writes:

 I think that the key mapping for , and C-c, in agenda is a mistake
 and should be swapped.  

 The agenda is read-only, so short keystrokes are often preferred 
 over long one.  , being short for C-c , looks natural and intuitive,
 so I don't think the change is necessary.


The agenda is not read-only for this command.  The current , modifies
both the agenda and the source org file to change the priority.  In
org-mode, this modification is made by C-c ,.  If agenda were
read-only I wouldn't have made the suggestion.  What tripped me up is
that the key combination that I use to change priority in org-mode
didn't work in agenda-mode.  In earlier versions of org mode, up to
7.8.11 the C-c , did change the priority in agenda mode.

Since the priority is already displayed as part of the line in the
agenda, I don't see the priority of having another command that 
displays it in the minibuffer.

An equally good fix is to have both , and C-c , make the priority
modifcation.  (Basically change the key-map so that both , and C-c ,
map to org-agenda-priority.)

R Horn

Re: [O] orgmode + evernote, anyone using it? Use cases?

[Robert Horn]

Alan Schmitt alan.schm...@polytechnique.org writes:

 Eden Cardim e...@insoli.de writes:

 Alan == Alan Schmitt alan.schm...@polytechnique.org writes:
 Alan Do you have a reliable system to link to emails? I've been
 Alan working on this and I'm not too satisfied yet.

 Not sure what you mean by reliable. I use offlineimap to sync my mail
 to a local dovecot which I access by tunneling gnus to it. This means
 I can access emails anywhere, like on a plane.

 Sorry I wasn't clear. I have the same setup. My question is: how do you
 get a link from org to gnus that still works even if messages are moved
 around. I tried nnregistry but it stopped working after I upgraded to
 Emacs 24.2, so I'd be happy for other solutions.


I use a combination of notmuch and notes.  It's reliable in the
sense that you mean about surviving file shuffling, because both link
based on a MailID.  The hybrid mail structure is forced on me by the
requirements of my employer (they require the use of Lotus Notes) and
separation of my personal mail.  I don't recommend it if you have any
alternative.

My notmuch is set up with mail in various MailDir structures.  That's
all covered in notmuch.el.  I think it would be equally robust for all
the different structures that notmuch can use.

I could add a link type for Lotus Notes because it has a command
line mode that you can invoke specifying the Notes mail ID.  Drag and drop
provides that information.  The invocation of:

/cygdrive/c/Program\ Files\ \(x86\)/Lotus/Notes/notes
notes:///852568800070EEAE/38D46BF5E8F08834852564B500129B2C/F462D53F85901A684E24D4139A7CDA52

will bring up that mail ID.  Setup and use is awkward, but not hopeless.
I drag the mail into an Emacs window, then run a bit of lisp to convert
the windows link into an org-mode link format.

R Horn

Re: [O] Habit setup help needed

[Robert Horn]

Memnon Anon gegendosenflei...@googlemail.com writes:

 I think the consistency bar is only fully functional with timestamps 
 of the format 2012-09-13 Do .+7d/10d : You need a minimum/maximum range.


Thank you.  That was the clue I needed.  I hadn't made the connection
between schedule repeat intervals and deadlines in habits.  So I was expecting
task  deadlines to cover that.

I suggest adding the following to item 5. in the habit documentation:

  A weekly report that must be filed during the following work week
  could be described with SCHEDULED: 2012-09-24 Mon +1w/12d. 

Have I understood this correctly?  It works for the habits that I'm
testing, but I haven't figured out the code to be sure that this covers
the edge cases properly. 

Assuming that this is correct, perhaps the info section on dates and
times should note that the habit option extends the scheduled time
notation.  That will catch folks who go to that section directly.

Alternatively, a more radical change would be to change habits to use
scheduled and deadline in the same sense that they are used elsewhere:
scheduled means should start at this time, deadline means should
complete at this time.  That would affect all current users.  Is there
an extra capability that this notation adds?

R Horn
rjh...@alum.mit.edu

Re: [O] Habit setup help needed

[Robert Horn]

Bastien b...@altern.org writes:


  Habit:  HABIT [#A] Weekly GTD revi   *   !  
 :home:

attachment: habit-example.png
Is what it looks like (a day later).

R Horn
rjh...@alum.mit.edu

Re: [O] org-habit config tinypatch

[Robert Horn]

I found the issue, and it's a more subtle one.  I've set a bug to emacs
list in case they think it's a documentation or fixable bug.  What
happens is this:

- The custom value setting for org options do not take effect until *after* 
the relevant lisp code has been executed once.  This means:
- If you start emacs and immediately go into *scratch* and print 
org-habit-show-today-all you get an error because that variable has not yet 
been bound.
: Debugger entered--Lisp error: (void-variable org-habit-show-all-today)
:   (print org-habit-show-all-today)
:   eval((print org-habit-show-all-today) nil)
:   eval-last-sexp-1(t)
:   eval-last-sexp(t)
:   eval-print-last-sexp()
:   call-interactively(eval-print-last-sexp nil nil) 
- If you start emacs and immediately go into options-config for org-habit, 
the org-habit-show-today-all will indicate that it has been set outside of the 
customization system when the intended value is t.  When the intended value 
is nil there is no indicated problem.
- If you start emacs and put a buffer into org mode, the (print 
org-habit-show-all) will show the customized value, and the options-config 
will also show the customized value.

I think that this is either a documentation bug, where this behavior
needs explaining, or a bug in customize.  As a naive user of customize I
would expect that going to the org-habit group would automatically
trigger applying the org-habit customizations.  Opening an org-mode
buffer has this effect.

But, perhaps there is some flag somewhere well hidden in the
documentation for customization groups that needs to be set to indicate
this.

R Horn
rjh...@alum.mit.edu

[O] Habit setup help needed

[Robert Horn]

I'm trying to get some habits set up that have a regular time window
during which I should do them.  The habits are being created and
somewhat maintained, but the habit bars are not acting the way that I
expected.

In the org file I have:

*** HABIT [#A] Weekly GTD review [0/9] :home:
DEADLINE: 2012-09-21 Fri ++1w SCHEDULED: 2012-09-17 Mon ++1w
 :LOGBOOK:
 - State DONE   from HABIT  [2012-09-14 Fri 09:00]
...
 :END:
 :PROPERTIES:
 :STYLE: habit
 :LOGGING: DONE(!)
 :END:

In the agenda, I get the habit bar.  The habit bar text is copied below,
but colors don't copy. It's red until the asterisk.  The asterisk is the
completion that is logged for 14 September.  It's blue until the
exclaimation point (18 September), then it has a red background, and the
future is red.  This is captured on Tuesday, 18 september.

 Habit:  HABIT [#A] Weekly GTD revi   *   !  :home:

I thought that it should be blue from the asterisk until monday, because
that is the completed period.  Then I expected green until friday,
because that's the interval from scheduled start work until the
deadline.  Then I expected red for the time past the deadline.

What is the right changes to make to get that effect?  I'm trying to
capture that something should be done once per week, on a weekday.

R Horn
rjh...@alum.mit.edu

[O] org-habit config tinypatch

[Robert Horn]

This patch fixes my problem, but indicates that there is a startup
sequencing issue that may also affect other parts of org.  

First the patch

--- org-agenda.el~  2012-09-12 21:24:27.0 -0400
+++ org-agenda.el   2012-09-17 06:02:45.0 -0400
@@ -90,7 +90,7 @@
 (defvar org-mobile-force-id-on-agenda-items)  ; defined in org-mobile.el
 (defvar org-habit-show-habits); defined in org-habit.el
 (defvar org-habit-show-habits-only-for-today)
-(defvar org-habit-show-all-today nil)
+(defvar org-habit-show-all-today) ; defined in org-habit.el
 
 ;; Defined somewhere in this file, but used before definition.
 (defvar org-agenda-buffer-name *Org Agenda*)

Second, the symptom

Without this patch the emacs config shows the show-all-today as having
been changed outside the config process, and it is set to nil rather
than the setting in the .emacs file.  It shows this immediately upon
startup when the config option is started and nothing else has been done.

If I understand defvar properly, this means that the org-agenda is being
evaluated before the .emacs, which is not what I expected at all.  So
either I don't understand defvar properly or the order of evaluation at
startup is not what I thought.  Either way, there are possibly other
defvars that need fixing.

Now that org-habit is part of the base org-mode, perhaps the proper fix
is to remove those three defvars.  Someone who understands the startup
sequence should make that decision.

R Horn 
rjh...@alum.mit.edu

[O] org-habit config contd

[Robert Horn]

There is more to this bug.  I don't think there is a problem with my
patch, but it doesn't fix it on all systems.  It fixed things on my Mac,
but not on Linux or Windows.  

Blessed with a lack of understanding for exactly what is going on I find
that changing the line in .emacs for custom-set-variables from:

'(org-habit-show-all-today t) 

to 

'(org-habit-show-all-today t t)

Makes the error go away.  Curiouser and curiouser.  This is looking less
like an org bug and more like something going on with the built-in
customization logic.

R Horn
rjh...@alum.mit.edu

Re: [O] Google-weather.el and the Latest Git Version of Org-mode

[Robert Horn]

Charles Philip Chan cpc...@bell.net writes:

 Jude DaShiell jdash...@shellworld.net writes:

 Hi Jude:

 It might be near time to investigate wunderground.com and loose google
 for weather before igoogle disappears.  Other weather sites capable of
 text output may also be available, I haven't investigated that yet.


wunderground.com wants a developer ID and in some situations wants a
paid account.

For US locations, take a look at the NOAA/NWS services.
http://graphical.weather.gov/xml/rest.php is a similar service, freely
available to the public.  Parseing the NDFD response will take a while
to understand, but it's a simple schema and will be a tiny computational
burden.  That page has links to all the relevant documents.

I don't have time to go through all that, but a quick look indicates
that it has all the information that Google was providing.  There will
just be more work involved in organizing it into a tidy little line of
text. 

R Horn
rjh...@alum.mit.edu

Re: [O] Google-weather.el and the Latest Git Version of Org-mode

[Robert Horn]

Charles Philip Chan cpc...@bell.net writes:

 Jude DaShiell jdash...@shellworld.net writes:

 Hi Jude:

 It might be near time to investigate wunderground.com and loose google
 for weather before igoogle disappears.  Other weather sites capable of
 text output may also be available, I haven't investigated that yet.


Followup: 

For world-wide sites, there is http://api.yr.no/weatherapi/documentation

This does not specify limits to geographic coverage and detail, but the
models listed as source include the ECMWF EC.GEO.0.25 which is global.
Forecasts for Norway and surrounding areas use a more accurate local
model.

R Horn
rjh...@alum.mit.edu

Re: [O] Org-mode release 7.9

[Robert Horn]

On Wed, Aug 29, 2012 at 08:00:18PM +0200, Bastien wrote:
 Hi Achim,
 
 Achim Gratz strom...@nexgo.de writes:
 
  Achim Gratz writes:
  Can we see the full output, please?
 
  I got a mail from Robert (apparently not sent to the list) that the
  error was related to his use of some stuff in contrib/, resulting in a
  mixed installation.  
 
 How the use of stuff in contrib/ can prevent the ELPA package from
 loading correctly?  I'm interested in having more details, if you or
 Robert can give some -- I had a similar problem, as you know, and
I'm traveling and have limited access and tools.  I've figured out
this much:

I had an emacs 24.1 install.  This has elpa and org 7.8.11 in the root
lisp area.  This also includes the 7.8.11 contrib directory.

When I use to elpa to upgrade the package to 7.9, it upgrades the lisp
directory but does not include the contrib directory.

When I start emacs, it finds the 7.9 org-mode, and does not detect a mixed
install.  The distribution org is all 7.9.

When my .emacs has the (require 'org-checklist) it finds the contrib 
directory in the 7.8.11 lisp directories. (I think).  There is no reported
error.  

All sorts of things work fine, but the new context aware changes for
capture interact in some bad way with the org-checklist from 7.8.11.

I won't have the right tools to figure out exactly what is going wrong
until I return from travel.  For now, the fix was quite simple.  I
removed the (require 'org-checklist) from my .emacs and the problem
went away.  It's entirely possible that there are other aspects of my
config that are also needed.

R Horn
rjh...@alum.mit.edu

Re: [O] Org-mode release 7.9

[Robert Horn]

A bug, perhaps ELPA related.  Sorry to be so brief but I've got to run
soon to the station.  I'm going to be tied up for the next week, but if
it's not figured out by then, I'll have time to look in more detail.

I confirmed this on Linux, Mac, and Windows, all emacs 24.1.  All
respond the same.

I decided to try ELPA to upgrade in place for the first time, and used
it to upgrade to the latest org 7.9.  No apparent errors there.  (good
work BTW).

Tests:
 - proper org-version? yes 7.9, no problems reported
 - [f8] to trigger a capture I get the error:

org-capture-select-template: Symbol's function definition is void:
org-contextualize-keys

In my .emacs I've got

(define-key global-map [f8] 'org-capture)

Sorry I don't have time to track this down further.  I'm guessing either
a problem with ELPA packaging or a default value for the new context
stuff that is not ready for the 'org-capture to be the very first thing
done from the emacs startup buffer.  Meanwhile, I dropped back to 7.8.11
until I can figure it out.

R Horn
rjh...@alum.mit.edu

Re: [O] are super-hidden technical blocks required?

[Robert Horn]

Separating out the issue of how to hide and expose the content, why not
use s-expressions for the hidden content?  Org is built on a lisp engine
and these will fit nicely into automation.  It avoids a lot of parsing
and other headaches, and an s-expression can hold any of the discussed 
information.

It could be an a-list that is designed for the purpose, or it could be a
list structured like the custom configuration list used in emacs config.
I think of the latter when considering the potential to steal code for
using the contents, updating the contents, and providing a user
interface when that is needed.  It also provides a model for sharing the
list among independent groups of developers with overlapping interests.
It permits automatically generated comments, advice, and warnings for
those who look at it, much like you find when looking over the tail end
of a .emacs file.

The property construction could then be a simple 
:HIDDEN-ALIST-PROPERTIES: (( stuff ))

It would be very unreadable and unfriendly to the novice, but that is
already a characteristic of the data being discussed.

R Horn
rjh...@alum.mit.edu

Re: [O] [GSoC] org-merge-driver weekly update

[Robert Horn]

Carsten Dominik carsten.domi...@gmail.com writes:

 On 6.6.2012, at 15:50, Andrew Young wrote:
 As a general remark, if you implement things like aggressive resorting,
 I think it would be good to have such features optional, in some
 way configurable.  Turning off all bells would then do a simple stable
 outline tree inserting like you have in your prototype.  Increasing
 complexity can and should be implemented, but I would like them optional
 for users (opt-out is OK).


I agree.  I'm thinking about a problem that I routinely have.  I work on
multiple computers capturing notes into journals that are date-trees.  I
resynchronize these journals using git, and git is often confused about
what to do when it sees the same base tree with different additions from
the different computers.

In my usage there are never deletes, and I would expect that the order
of headlines in the original versions would be preserved as the order of
those headlines in the merged version.  I don't get out of order
headlines because the capture function manages the date tree for me.

If I had an improperly ordered input I would prefer to have the merger
fail and ask for manual help.  If it's out of order that means either
something went wrong with the capture function, or I manually did
something that I might want preserved.  For instance, I might archive
the 2010 notes into some other file, and replace them with a link to
that file.  I would want to preserve this.  (Actually the issue of how
to manage such archival is one that I haven't given much thought, since
disk space is cheap and it's easy to collapse the old stuff.)

Robert Horn

Re: [O] [GSoC] org-merge-driver weekly update

[Robert Horn]

Another area that would be nice to address is taking advantage of the
information in date-trees so assist with merging.  This is similar to
the logic around keeping headlines in order.  With date trees there is a
date and sometimes time tag to help.

In addition to the occurrence order, there is also an ordering constraint on 
date trees that can be used to determine the proper delta.  You can use the 
date and time information in the headlines to determine the proper sequencing.

For example, the delta/merger for two files of the form:
 File 1:
 * Year
 ** Year-Month
 *** Year-Month-Day
  Y-M-D-Time1 stuff1 ...
  Y-M-D-Time2 stuff2 ...
  Y-M-D-Time4 stuff4 ...
  Y-M-D-Time5 stuff5 ...
  Y-M-D-Time9 stuff9 ...
 File 2:
 * Year
 ** Year-Month
 *** Year-Month-Day
  Y-M-D-Time1 stuff1 ...
  Y-M-D-Time2 stuff2 ...
  Y-M-D-Time3 stuff3 ...
  Y-M-D-Time6 stuff6 ...
  Y-M-D-Time7 stuff7 ...

 Should be:
 * Year
 ** Year-Month
 *** Year-Month-Day
  Y-M-D-Time1 stuff1 ...
  Y-M-D-Time2 stuff2 ...
  Y-M-D-Time3 stuff3 ...
  Y-M-D-Time4 stuff4 ...
  Y-M-D-Time5 stuff5 ...
  Y-M-D-Time6 stuff6 ...
  Y-M-D-Time7 stuff7 ...
  Y-M-D-Time9 stuff9 ...

This time aware merge logic will apply similarly to all levels of the date tree.

Date trees are recognizable by the combination of headlines in this
format.  A date tree can occur anywhere in an org file, but it will
begin with a level one headline of the form * , etc.

R Horn
rjh...@alum.mit.edu

[O] Date-tree navigation question

[Robert Horn]

Is there a short simple key sequence that will take you to the last 
entry in a date-tree and open that headline?  Slightly better would be a 
way to go to the last, and open the last N headlines.  It could be 
generalized into go to end of current item and open last N items of 
whatever depth when applied to other outline forms.


I know how to do this with tabs and cursor movement to walk down the 
tree opening headlines as needed.  This requires more work and paying 
attention.


I have not found a simple way to do this.  Does one exist?

R Horn

Re: [O] dates before 1970

[Robert Horn]

 So I am not sure what 64 bit systems do now or in the future, but
 it seems that we need to live with a restriction for now.
 Maybe this should be documented somewhere.
 
 - Carsten

Most 64-bit systems use a 64-bit int.  All of the 64-bit Linux systems
that I've used use a signed 64-bit int.  Some systems use a 64-bit
unsigned int. Some use a double.  The only way to know for sure is to
look at their definition of time_t in time.h, as provided by the system.

http://en.wikipedia.org/wiki/Time_t is as good a starting point as any.

The precise words from the Open Group Base standard are:
time_t and clock_t shall be integer or real-floating types.
The usage of time_t in various functions is specified, but range and
type is not defined.

R Horn

[Orgmode] What is the proper way to set the time span for a diary-float appointment?

[Robert Horn]

I wanted to set up a regular meeting that would appear in the agenda
grid.  I discovered that the following works:

... Regular Meeting 13:00-14:00
%%(diary-float t 2 1)

This creates a first tuesday of each month meeting, from 1300h to 1400h.
This works because the default for the
org-agenda-search-headline-for-time is t.

Is there a better way to do this?  It seems odd to split the date from
the time.  I didn't find anything that combines the date rules of
diary-float with the ability to also specify a time interval.

If this is the best way, I'll write up a patch to put this into the info
file.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Habits bug?

[Robert Horn]

I tracked down the problem I was seeing.  It's unrelated to habits.  I
just connected it with habits because it affects them, as well as other
things.

The default behavior of the built-in agenda is to set the point in the
agenda to be today.  This is not the default for custom commands.  The
closest that custom commands have is the option to start the agenda with
today.  That is actually what I prefer, so I'm happy with that.  The
resulting org-agenda-custom-commands is

(setq org-agenda-custom-commands
  '((h Agenda and This Week tasks
 ((agenda  ((org-agenda-start-on-weekday nil)))
  (todo THISWEEK|STARTED)

What I was seeing was the non-display of today's calendar grid and
habits due to the point being on another day.  The combination of d
and r was to get the day set to today, which caused today's calendar
grid and habits to re-appear.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Habits bug?

[Robert Horn]

On 11/11/2010 07:07 AM, Matt Lundin wrote:
 Robert Horn rjh...@alum.mit.edu writes:
 
 I just noticed the following oddity.

 1.) I have a custom agenda that consists of:

 (setq org-agenda-custom-commands
   '((h Agenda and This Week tasks
   ((agenda )
(todo THISWEEK)

 2.) I have the default agenda period of 1 week at startup.

 The behavior I see is:

 a) When I do the C-c a h, I get the entire week, including the habits
 and habit bars at the end of the section for today (somewhere mid-week)

 b) If I type d to go into daily mode, the scheduled and extra todo's
 that are THISWEEK are shown.  But the habits and habit bars are not
 present.

 c) When I repeat C-c a h to regenerate, it stays in the daily mode (as
 it should) and the habits and habit bars re-appear.

 This is odd, and probably reflects a subtle bug somewhere in the
 regeneration logic for changing the agenda period.  It's not a critical
 issue, since the work around is so easy, but someone who understands
 that stretch of code might see it easily.
 
 I cannot reproduce this. I tried your custom command above (tweaked to
 use one of my TODO keywords --- STARTED). The habits consistently
 appeared when switching back and forth between day and week views. Would
 it be possible to provide a minimal file and config that reproduces the
 error?
 

I didn't have time yet to create minimal files, but I learned more:

1) I can create it with a simpler custom command:

(setq org-agenda-custom-commands
  '((h Agenda and This Week tasks
   ((agenda )

2) The daily schedule stuff is also missing.  So this is something in
the agenda processing that is not unique to habits.

3) It only happens the first time after startup that I switch from
weekly to daily mode.  If I change the custom commands after that, there
is no problem.  This makes it act like some sort of initialization
problem in daily/weekly agenda generation, not something unique to
habits.  (Having to type r once in the agenda after startup is not
much of a problem.)

4) It happens with version 7.01g, and with the release_7.3-39-g68b5ca3
from git.

I've attached my .emacs in case there is something odd in there that
could be causing this.

R Horn
;; Default window size
;;
(setq initial-frame-alist  '((top . 1)(left . 10)(width . 120)(height . 45)))
(setq default-frame-alist  '((width . 120)(height . 35)(menu-bar-lines . 1)))
;;
;; Always do fill
;;
(add-hook 'text-mode-hook
  '(lambda () (visual-line-mode)))
;;
;; bring in remember
;;
;(add-to-list 'load-path ~/elisp/remember-2.0)
;(autoload 'remember remember nil t)
;(autoload 'remember-region remember nil t)

;;; (define-key global-map [f9] 'remember-region)

;(setq load-path (cons ~/elisp/remember load-path))

;;
;; org-mode stuff
;;
(setq load-path (cons ~/org-git/org-mode/lisp load-path))
(setq load-path (cons ~/org-git/org-mode/contrib/lisp load-path))
(add-to-list 'auto-mode-alist '(\\.org\\' . org-mode))
(global-set-key \C-cl 'org-store-link)
(global-set-key \C-ca 'org-agenda)
(define-key global-map [f8] 'org-capture)  ; was org-remember
(add-hook 'org-mode-hook 'turn-on-font-lock)  ; org-mode buffers only

(require 'org-install)
(require 'org-checklist)

(setq org-directory ~/org/)
(setq org-default-notes-file ~/org/notes)
(setq org-log-done 'time)

(setq org-todo-keywords (quote (
(sequence TODO(t) NEXT(n) THISWEEK(h) 
STARTED | DONE(d!/!))
(sequence WAITING(w@/!) SOMEDAY(S) | 
CANCELLED(c@/!))
(sequence DELEGATED | DONE(d!/!))
)))
(setq org-tag-alist '( (agfa . ?a) (dicom . ?d) (home . ?h) (ihe . ?i) 
(computer . ?c)
   ))
;;
;; ditaa stuff
;; 
 (setq org-ditaa-jar-path 
/home/hornrj/org-git/org-mode/contrib/scripts/ditaa.jar)

 (add-hook 'org-babel-after-execute-hook 'org-display-inline-images)

 (setq org-babel-load-languages (quote ((emacs-lisp . t)
(dot . t)
(ditaa . t)
(R . t)
(python . t)
(ruby . t)
(gnuplot . t)
(clojure . t)
(sh . t

; Do not prompt to confirm evaluation
; This may be dangerous - make sure you understand the consequences
; of setting this -- see the docstring for details
(setq org-confirm-babel-evaluate nil)


;;
;; Try some interesting colors for tasks
;;
(setq org-todo-keyword-faces (quote (
 (TODO  :foreground red :weight bold)
 (NEXT :foreground steelblue :weight 
bold)
 (THISWEEK :foreground blue :weight 
bold)
 (DONE  :foreground forestgreen :weight 
bold

[Orgmode] Habits bug?

[Robert Horn]

I just noticed the following oddity.

1.) I have a custom agenda that consists of:

(setq org-agenda-custom-commands
  '((h Agenda and This Week tasks
 ((agenda )
  (todo THISWEEK)

2.) I have the default agenda period of 1 week at startup.

The behavior I see is:

a) When I do the C-c a h, I get the entire week, including the habits
and habit bars at the end of the section for today (somewhere mid-week)

b) If I type d to go into daily mode, the scheduled and extra todo's
that are THISWEEK are shown.  But the habits and habit bars are not
present.

c) When I repeat C-c a h to regenerate, it stays in the daily mode (as
it should) and the habits and habit bars re-appear.

This is odd, and probably reflects a subtle bug somewhere in the
regeneration logic for changing the agenda period.  It's not a critical
issue, since the work around is so easy, but someone who understands
that stretch of code might see it easily.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Adding tags, grouping tags

[Robert Horn]

On 10/25/2010 02:18 AM, Carsten Dominik wrote:
 Hi,
 
 I have the feeling that there are really two strands of
 discussion going on here.
 
 1. A two-level or even hierarchical way to *enter* *normal* tags,
i.e. tags that are specified in the headline of a node.
 
 2. A complex new structure that would somehow utilize properties to
crease a tag-like parallel structure that can be used in searches.
 
 Is this a correct view of what is being discussed?
 

I think so.

My impression is that the present normal tags are approaching their
limit.  A multi-level normal tag will probably be longer text, and one
core assumption of normal tags is that it is reasonable to display them
and simply append them to the end of the headline text.  With longer
tags and multiple tag contexts I expect this to soon cause problems that
are much more severe than just the problem of tag specification.

Since there exists the properties capability, a more complex structure
that is used in searches and display could be built upon that.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Adding tags, grouping tags

[Robert Horn]

On 10/16/10 4:09 PM, Carsten Dominik wrote:

 On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:

 On 10/16/2010 01:32 AM, Carsten Dominik wrote:

 On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:

 Karl Maihofer ignoramus at gmx.de writes:
 Besides that I have tags in other contexts, e.g. GTD-related tags etc.
 So it would be very useful to be able to group the tags as it is
 possible for agenda commands.

 I think that a way to define logical groups of tags (or even a
 hierarchy of tags
 -- say with a subtree of tag names?) would be a very useful addition.

 I can see that this could be useful - but the code is
 not in any way prepared to do this, so this would be pretty hard
 to implement.

 Is it worth exploring use of the properties drawer? The tags in org are
 a fairly simple and thus limited structure. The properties drawer can
 have a lot more structure with a more controlled environment.

 I don't think I understand what you mean here. How would that help?

 - Carsten

My first thought was just to deal with visual clutter and parsing
headaches. Encoding standards like IDv3 have a large list of tags and
tags with values that are encoded and hidden in MP3 files. The display
is controlled by application. This is very much like the drawer
behavior in org. So putting tags into drawers would deal with the
clutter associated with having a great many tags on one item.

The next level would be to have org aware of the tag structure. This
would mean having a vocabulary description that describes the tags.
The vocabulary can be described as:

Top level: Context, e.g., GTD
   Level 1: TagA
 Level 2: TagB, a kind of TagA
Level 3: TagC, a kind of TagB
   Level 1: TagD
   etc

Usually Tags are unique with in a context, but might collide between
contexts. So I might find the tag TASK used in different contexts.
Multiple tags can occur within a context, so something might have TagA
and TagD, and the presence of a lower level tag implies the higher level
tags. So TagC would imply TagB and TagA in the example above.

This is a simplification of full ontological structures that can be
expressed in a language like OWL, but it is one that people can grasp
and use easily. It meets most needs. The music and photographic
standards and their easy usage indicates this.

The vocabulary description could easily be done with some lisp
customization, the way it is done for task states, or it could be in an
org file. Both ways have their advantages.

For each tag you can have a list of pairs of context+tag to keep tags
unique. Appending these as text to each line introduces a lot of visual
clutter and parsing headaches. I would put these into drawers to reduce
the visual clutter and manage duplication. For the tag descriptions I
would have another location that has the full structure of tags, so that
a friendly display selection could be used that reflects the hierarchy.
A tag assignment similar to the IDO selection of levels within an org
hierarchy would make sense. Perhaps an org structure would make sense
for the vocabulary.

A simpler tag that means look in the tags drawer would keep the text
file readable and let the agenda processing deal with extracting and
displaying. Non agenda views of the org file would just have the look
in tags drawer tag. The viewing options would need to recognize this to
control how the drawer tags are displayed.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Adding tags, grouping tags

[Robert Horn]

On 10/16/2010 01:32 AM, Carsten Dominik wrote:
 
 On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
 
 Karl Maihofer ignoramus at gmx.de writes:
 Besides that I have tags in other contexts, e.g. GTD-related tags etc.
 So it would be very useful to be able to group the tags as it is
 possible for agenda commands.

 I think that a way to define logical groups of tags (or even a
 hierarchy of tags
 -- say with a subtree of tag names?)  would be a very useful addition.
 
 I can see that this could be useful - but the code is
 not in any way prepared to do this, so this would be pretty hard
 to implement.
 
Is it worth exploring use of the properties drawer?  The tags in org are
a fairly simple and thus limited structure.  The properties drawer can
have a lot more structure with a more controlled environment.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Update for habit documentation

[Robert Horn]

On 09/29/2010 12:07 PM, Carsten Dominik wrote:
 Hi Robert,
 
 would you like to formulate a patch to org.texi?
 

This is my proposed patch. I hope I've done this right.

*** org.texi2010-10-06 09:06:20.0 -0400
--- org.texi-original   2010-07-21 12:42:48.0 -0400
***
*** 3809,3818 
  @item
  The property @code{STYLE} is set to the value @code{habit}.
  @item
! The TODO has a scheduled date, usually with a @code{.+} style repeat
interval.
! A @code{++} style may be appropriate for habits with time constraints,
e.g.,
! must be done on weekends, or a @code{+} style for an unusual habit
that can
! have a backlog, e.g., weekly reports.
  @item
  The TODO may also have minimum and maximum ranges specified by using the
  syntax @samp{.+2d/3d}, which says that you want to do the task at
least every
--- 3809,3815 
  @item
  The property @code{STYLE} is set to the value @code{habit}.
  @item
! The TODO has a scheduled date, with a @code{.+} style repeat interval.
  @item
  The TODO may also have minimum and maximum ranges specified by using the
  syntax @samp{.+2d/3d}, which says that you want to do the task at
least every

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Update for habit documentation

[Robert Horn]

I've been using habits and found additional uses that are actually
implemented but not mentioned in the documentation.  What I've found
useful are:

1) Using a '++' repeat style for habits that have calendar constraints.
 I use this for some activities that must be done on Monday, or on
weekends.  This works, so there is no need to change the implementation.

2) Using a '+' repeat style is good for activities that can have a
backlog.  For example, preparing weekly reports is something that is
aided by the habit tracking information.  This also works.

This affects bullet 4, which presently implies that the repeat interval
must be a '.+' style. Would the following be clear:

4. The TODO has a scheduled date, usually with a '.+' style repeat
interval.  Other repeat styles may be used.  The '++' style can handle
habits with calendar constraints, e.g., must be done on a Monday; and
the '+' style can be useful for habits that can have a backlog.

R Horn

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Install warning for org-7 for forgetful users

[Robert Horn]

I ran into this, so I'll warn others.  It might belong in the notes for
org-7.01.

If you have a newer version of emacs that has org already integrated,
you get some, but not all, of the org-7.01 features functioning if you
have org-7.01 set as the auto-load directory.  I had been using org by
having the lines:

(setq load-path (cons ~/org-6.xxx/lisp load-path))
(require 'org-install)

in my .emacs.  I forgot that I had upgraded emacs and org was now
integrated into emacs. I just changed org-6.xxx to org-7.01g to try out
the new version.  Odd things resulted.  It actually worked well enough
to do some work, but then I found occasional stuff that did not work.  I
used the brute force fix of just moving all the org-* files into a
temporary directory, thus slowing down the startup but ensuring that I
could test the new version without having headaches if I wanted to revert.

There might be a better method than this.  It's probably worth
mentioning in the release notes.

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode