Re: [O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Bruce V. Chiarelli]

2016-10-31 8:23 GMT-07:00 Nicolas Goaziou :
> Hello,
>
> "Bruce V. Chiarelli"  writes:
>
>> I've noticed some unusual behavior with repeating entries when the
>> system-time-locale variable is set. Specifically:
>>
>> It is Sunday, today, October 30th. I did not mark this task, which is
>> a habit, yesterday.
>>
>> -- If I have (setq system-time-locale "hu_HU.utf8"), Hungarian, then
>> marking this task DONE
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-29 szo .+1d>
>>
>> vbecomesv
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-30 v .+1d>
>>
>> Which is not correct. I marked it DONE today, so it should repeat tomorrow.
>>
>> -- If I have (setq system-time-locale "es_MX.utf8"), Mexican Spanish,
>> then doing the same thing:
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-29 szo .+1d>
>>
>> vbecomesv
>>
>> * TODO Anki basic reviews   :habit:study:
>>   SCHEDULED: <2016-10-31 lun .+1d>
>>
>> Which *is* correct. I have tried this with an unset
>> system-time-locale, and with it set to fa_IR, es_MX, en_GB, and hu_HU.
>> So far, hu_HU is the only one that behaves incorrectly. Note that it
>> doesn't seem to matter which language the day-of-the-week abbreviation
>> is already in, since every time I tried this, I reverted the file back
>> to the Hungarian line. Changing the date to <2016-10-29 Sat .+1d>
>> before marking it also had no effect.
>>
>> Of course, I could just set the date locale to "C" or unset it, but
>> there's still a bug somewhere.
>
> I tend to think this is not a bug in Org mode, since it correctly work
> with other locales, and we do not control locales.

I thought so too, to be honest, but I got my hands dirty and I think
I've figured out where the actual problem lies.

I did the bisect earlier, and the breaking change was right when the
code to handle native language day names was added as part of Org 8.0.
I got a bit disorganized and lost the exact commit, but I can try to
find it if need be. Anyway, I started the lisp debugger to trace what
was happening and found the real problem. I hope someone can confirm.

org-todo calls org-auto-repeat-maybe, which sees the ".+" style
repeater. It calls org-timestamp-change to move the timestamp up to
today. Point is left at the closing bracket. So far, so good.

org-timestamp-change sets origin-cat to 'after and origin to (point).
It then changes the timestamp to today as advertized.

Now these lines get evaluated

(goto-char (cond
;; `day' category ends before `hour' if any, or at
;; the end of the day name.
((eq origin-cat 'day)
 (min (or (match-beginning 7) (- (match-end 5) 2)) origin))
((eq origin-cat 'hour) (min (match-end 7) origin))
((eq origin-cat 'minute) (min (1- (match-end 8)) origin))
((integerp origin-cat) (min (1- (match-end 0)) origin))
;; `year' and `month' have both fixed size: point
;; couldn't have moved into another part.
(t origin

The since origin-cat is 'after, matching nothing else, we get
(goto-char origin).

This seems to be where the problem lies. When "<2016-10-29 szo .+1>"
becomes "<2016-10-31 h .+1>" (today), origin is now two characters
ahead of where it should be, now on the next line in fact.

So it returns fine at first, but when org-auto-repeat maybe calls
org-timestamp-change a second time to move the date into the future,
it throws the error "Not at a timestamp" and does nothing else. I
wasn't seeing this error until I was in the debugger, since
org-auto-repeat-maybe puts an "Entry repeats: ..." message in the echo
area. Oddly enough, that message shows the correct date since
org-last-changed-timestamp gets updated properly.

-BC

> Anyway, could you try bisecting and tell us when the bug was born?
>
> Regards,
>
> --
> Nicolas Goaziou

[O] Fontification of collapsed sections with code blocks

[Maciek Starzyk]

Hi list,
Not sure if this is a bug or a feature:
Collapsed sections, which end with a source code block, have the same font
(from the ellipsis until the end of line) as the code block last line. The
face name is `org-block-end-line'.
This propagates also to parent sections.

Is there a setting that switches this behavior off ?
See the attached screenshot for an example.

Cheers,
-- 
Maciek

Re: [O] Fontification of collapsed sections with code blocks

[John Kitchin]

I feel like I recall some one recently saying adding an extra blank line
after the src blocks or at the end of the blocks might solve it.

John

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


On Mon, Oct 31, 2016 at 8:32 PM, Maciek Starzyk  wrote:

> Hi list,
> Not sure if this is a bug or a feature:
> Collapsed sections, which end with a source code block, have the same font
> (from the ellipsis until the end of line) as the code block last line. The
> face name is `org-block-end-line'.
> This propagates also to parent sections.
>
> Is there a setting that switches this behavior off ?
> See the attached screenshot for an example.
>
> Cheers,
> --
> Maciek
>

Re: [O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Nicolas Goaziou]

"Bruce V. Chiarelli"  writes:

> org-todo calls org-auto-repeat-maybe, which sees the ".+" style
> repeater. It calls org-timestamp-change to move the timestamp up to
> today. Point is left at the closing bracket. So far, so good.
>
> org-timestamp-change sets origin-cat to 'after and origin to (point).
> It then changes the timestamp to today as advertized.
>
> Now these lines get evaluated
>
> (goto-char (cond
> ;; `day' category ends before `hour' if any, or at
> ;; the end of the day name.
> ((eq origin-cat 'day)
>  (min (or (match-beginning 7) (- (match-end 5) 2)) origin))
> ((eq origin-cat 'hour) (min (match-end 7) origin))
> ((eq origin-cat 'minute) (min (1- (match-end 8)) origin))
> ((integerp origin-cat) (min (1- (match-end 0)) origin))
> ;; `year' and `month' have both fixed size: point
> ;; couldn't have moved into another part.
> (t origin
>
> The since origin-cat is 'after, matching nothing else, we get
> (goto-char origin).
>
> This seems to be where the problem lies. When "<2016-10-29 szo .+1>"
> becomes "<2016-10-31 h .+1>" (today), origin is now two characters
> ahead of where it should be, now on the next line in fact.

I see. Thank you for the analysis.

Does adding the following branch in the `cond' above, before the
catch-all one, solves the issue?

  ((eq origin-cat 'after) (match-end 0))


Regards,

Re: [O] Use headings in sitemap

[Thibault Marin]

> I think this is a genuine bug. Exclude regexp should be matched against
> relative file names, not absolute ones. I fixed it in wip-sitemap. You
> may want to rebase the branch if you want to experiment with the fix.

The latest update works for me (all my previously reported issues are
fixed).  I have also tested anti-chronologically sorting, which works
too.

Please let me know if you'd like me to run additional tests.

Thanks.

Re: [O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Bruce V. Chiarelli]

2016-10-31 17:04 GMT-07:00 Nicolas Goaziou :
> "Bruce V. Chiarelli"  writes:
>
>> org-todo calls org-auto-repeat-maybe, which sees the ".+" style
>> repeater. It calls org-timestamp-change to move the timestamp up to
>> today. Point is left at the closing bracket. So far, so good.
>>
>> org-timestamp-change sets origin-cat to 'after and origin to (point).
>> It then changes the timestamp to today as advertized.
>>
>> Now these lines get evaluated
>>
>> (goto-char (cond
>> ;; `day' category ends before `hour' if any, or at
>> ;; the end of the day name.
>> ((eq origin-cat 'day)
>>  (min (or (match-beginning 7) (- (match-end 5) 2)) origin))
>> ((eq origin-cat 'hour) (min (match-end 7) origin))
>> ((eq origin-cat 'minute) (min (1- (match-end 8)) origin))
>> ((integerp origin-cat) (min (1- (match-end 0)) origin))
>> ;; `year' and `month' have both fixed size: point
>> ;; couldn't have moved into another part.
>> (t origin
>>
>> The since origin-cat is 'after, matching nothing else, we get
>> (goto-char origin).
>>
>> This seems to be where the problem lies. When "<2016-10-29 szo .+1>"
>> becomes "<2016-10-31 h .+1>" (today), origin is now two characters
>> ahead of where it should be, now on the next line in fact.
>
> I see. Thank you for the analysis.
>
> Does adding the following branch in the `cond' above, before the
> catch-all one, solves the issue?
>
>   ((eq origin-cat 'after) (match-end 0))

It does! Wonderful.

-BC

Re: [O] Use headings in sitemap

[Nicolas Goaziou]

Hello,

Thibault Marin  writes:

> I don't have the `directory-name-p' function (I am still on emacs 24),
> so I made a simplistic one: (string= file (file-name-sans-extension
> file)), it seems to be sufficient for my test-case.  I don't know if not
> being on 25 will cause other issues.

Fixed.

> I also had to add a call to `expand-file-name' around the definition of
> the `root' variable (in `org-publish-sitemap') to account for the fact
> that my :base-directory is defined with "~/" instead of "/home/...".

Fixed, too.

> Another thing I had to modify was the :exclude pattern which was
> mis-formed earlier ("setup.org\\|website.org\\|rss.org" changed to
> "setup\\.org\\|website\\.org\\|rss\\.org").  The earlier version of the
> pattern results in an empty file list but was not a problem on the older
> version of the sitemap tools.

I'm not sure to understand. Why resulting in an empty file list is
a problem? Is there an error in the new "ox-publish.el"?

> (let ((date
>(org-element-interpret-data
> (org-publish-find-property entry :date

There is also `org-publish-find-date', which is sligthly different.

Thanks for the feedback.

Regards,

-- 
Nicolas Goaziou

Re: [O] “Match data clobbered by buffer modification hooks”

[Nicolas Goaziou]

Hello,

Saša Janiška  writes:

> Ahh, OK. But it is still not built-in version, but the one from org’s
> ELPA, right?

Correct. Anyway, it would be interesting to test the issue with real
master branch.

Regards,

-- 
Nicolas Goaziou

Re: [O] “Match data clobbered by buffer modification hooks”

[Saša Janiška]

Nicolas Goaziou  writes:

> Correct. Anyway, it would be interesting to test the issue with real
> master branch.

I might try it, but wonder if there are some relevant commits in master
branch?


Sincerely,
Gour

-- 
One who restrains his senses, keeping them under full control,
and fixes his consciousness upon Me, is known as a man of
steady intelligence.

Re: [O] “Match data clobbered by buffer modification hooks”

[Nicolas Goaziou]

Saša Janiška  writes:

> I might try it, but wonder if there are some relevant commits in master
> branch?

There are 1200+ commits in the master branch that are not in the stable
one. It could make a difference.

Regards,

Re: [O] Use headings in sitemap

[Thibault Marin]

> I'm not sure to understand. Why resulting in an empty file list is
> a problem? Is there an error in the new "ox-publish.el"?

Sorry for the confusion, I don't think anything is wrong with the new
ox-publish.el, but the selection of excluded files by regexp seems to
have changed (I personally have no problem with this change, I just
thought I'd mention it).

My directory structure has a "website/org/" component so the loose
regexp "website.org" used for exclusion matched any file path (it
appears that full paths are used to determine which files should be
excluded), so, for instance, "/path/to/website/org/index.org" was
excluded, which I do not want.

The same loose regexp did not exclude "index.org" in the previous
version of the sitemap functions. Maybe the exclude regexp was applied
to file names relative to root ("index.org" in my example)?

With a more restrictive regexp "website\\.org", everything behaves as
expected.

I hope it is clearer.

Thanks.

Re: [O] “Match data clobbered by buffer modification hooks”

[Saša Janiška]

Nicolas Goaziou  writes:

> This is not master. You are still on stable branch according to the
> string above.

Ahh, OK. But it is still not built-in version, but the one from org’s
ELPA, right?


Sincerely,
Gour

-- 
One who is not disturbed in mind even amidst the threefold
miseries or elated when there is happiness, and who is free
from attachment, fear and anger, is called a sage of steady mind.

Re: [O] org-meta-return

[Nicolas Goaziou]

Hello,

42 147  writes:

> I notice that org-meta-return now inserts a space between the new headline
> and the previous headline. This was not the functionality before (not sure
> which update changed it).

Not sure to understand "before" what. In any case, wouldn't you be
looking for `org-blank-before-new-entry'?

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

On 30 October 2016 at 23:57, Josiah Schwab  wrote:

> Hi Reuben,
>
> > It would be great if it were possible to install stable org-mode
> > versions from GNU ELPA or MELPA Stable. At present, one has to choose
> > between installing bleeding-edge versions simply, or stable versions
> > built by hand.
> >
> > (I am a bit surprised I can’t find anything about this in the mailing
> > list archives, so do forgive me if I’ve overlooked previous discussion.)
>
> The version on GNU ELPA (http://elpa.gnu.org/packages/org.html), which
> is labeled org-20161024, is org-git-version 8.3.6-7-g4d7d52-elpa.
>
> I believe that indicates that it is the latest version from the stable
> maint branch, not a version from the unstable master branch (which is at
> 8.3.6-1264-g21932c right now).
>

​That's great! However, is a cut of the release branch as good as an actual
release?

Thought experiment: if it is good enough, surely the web site should
point users to this installation method for the stable version? I can't
imagine there are many users who would prefer to compile from source rather
than just use package-install!
​ Also, the version should be the git tag (so that the version number is
clearly visible), rather than the current "MMDD" format, which looks
like a development snapshot.

​If the org-mode maintainers do *not* consider these release branch
snapshots to be as good as actual releases, then I would repeat my request
for stable releases to be available on GNU ELPA or MELPA Stable.

-- 
http://rrt.sc3d.org

Re: [O] Use headings in sitemap

[Nicolas Goaziou]

Thibault Marin  writes:

> Sorry for the confusion, I don't think anything is wrong with the new
> ox-publish.el, but the selection of excluded files by regexp seems to
> have changed (I personally have no problem with this change, I just
> thought I'd mention it).
>
> My directory structure has a "website/org/" component so the loose
> regexp "website.org" used for exclusion matched any file path (it
> appears that full paths are used to determine which files should be
> excluded), so, for instance, "/path/to/website/org/index.org" was
> excluded, which I do not want.

I think this is a genuine bug. Exclude regexp should be matched against
relative file names, not absolute ones. I fixed it in wip-sitemap. You
may want to rebase the branch if you want to experiment with the fix.

Thank you for the explanation.

Regards,

Re: [O] Tasks don't repeat correctly if system-time-locale is set to certain languages

[Nicolas Goaziou]

Hello,

"Bruce V. Chiarelli"  writes:

> I've noticed some unusual behavior with repeating entries when the
> system-time-locale variable is set. Specifically:
>
> It is Sunday, today, October 30th. I did not mark this task, which is
> a habit, yesterday.
>
> -- If I have (setq system-time-locale "hu_HU.utf8"), Hungarian, then
> marking this task DONE
>
> * TODO Anki basic reviews   :habit:study:
>   SCHEDULED: <2016-10-29 szo .+1d>
>
> vbecomesv
>
> * TODO Anki basic reviews   :habit:study:
>   SCHEDULED: <2016-10-30 v .+1d>
>
> Which is not correct. I marked it DONE today, so it should repeat tomorrow.
>
> -- If I have (setq system-time-locale "es_MX.utf8"), Mexican Spanish,
> then doing the same thing:
>
> * TODO Anki basic reviews   :habit:study:
>   SCHEDULED: <2016-10-29 szo .+1d>
>
> vbecomesv
>
> * TODO Anki basic reviews   :habit:study:
>   SCHEDULED: <2016-10-31 lun .+1d>
>
> Which *is* correct. I have tried this with an unset
> system-time-locale, and with it set to fa_IR, es_MX, en_GB, and hu_HU.
> So far, hu_HU is the only one that behaves incorrectly. Note that it
> doesn't seem to matter which language the day-of-the-week abbreviation
> is already in, since every time I tried this, I reverted the file back
> to the Hungarian line. Changing the date to <2016-10-29 Sat .+1d>
> before marking it also had no effect.
>
> Of course, I could just set the date locale to "C" or unset it, but
> there's still a bug somewhere.

I tend to think this is not a bug in Org mode, since it correctly work
with other locales, and we do not control locales.

Anyway, could you try bisecting and tell us when the bug was born?

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Nicolas Goaziou]

Hello,

Reuben Thomas  writes:

> ​That's great! However, is a cut of the release branch as good as an actual
> release?

It is better, since it contains more bugfixes than last release without
adding new features.

However, I think we should make more frequent bugfix releases. We may
even automate such releases, e.g., one week after the last unreleased
bugfix in the branch. I don't do releases however, so this may just be
a weird idea.

Bastien, is it even possible?

> Thought experiment: if it is good enough, surely the web site should
> point users to this installation method for the stable version?

Isn't it the case already? From the first page I see

  M-x list-packages RET (see Org ELPA)

  Daily snapshots: tar.gz or zip

> I can't imagine there are many users who would prefer to compile from
> source rather than just use package-install!

I don't think we force users to use development version (even though it
is appreciated, particularly close to a major release). OTOH, being able
to browse source code is very important so the "git clone" command and
the "cgit" link also belong to the first page.

> ​ Also, the version should be the git tag (so that the version number is
> clearly visible), rather than the current "MMDD" format, which looks
> like a development snapshot.

We need to tell the difference between a release and a cut from the
maint branch. 

Also, I'd rather have monotonic version tags, so 8.3.6.whatever is not
really an option. Maybe 8.3.YYYMMDD... and we drop manual bugfix
releases altogether.


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

On 31 October 2016 at 14:56, Nicolas Goaziou  wrote:

> Hello,
>
> Reuben Thomas  writes:
>
> > ​That's great! However, is a cut of the release branch as good as an
> actual
> > release?
>
> It is better, since it contains more bugfixes than last release without
> adding new features.
>

​That's good to know.​

> Thought experiment: if it is good enough, surely the web site should
> > point users to this installation method for the stable version?
>
> Isn't it the case already? From the first page I see
>
>   M-x list-packages RET (see Org ELPA)
>
>   Daily snapshots: tar.gz or zip
>

​The web page is quite clear. Under "Download and install" you can get
"Stable version" (only from source), or "Development version" (cgit or M_x
list-packages RET), or "Daily snapshots".​

In other words, it looks as though the Org ELPA version is a development
version. The linked page does nothing to counter this impression.

I suggest that the "M-x list-packages RET" part be moved up the page to
"Stable version"; it should say something like:

"Stable version: M-x list-packages RET (see Org ELPA; includes fixes since
last release), or tar.gz or zip (release notes).

Ideally there would be up-to-date release notes for the ELPA version, so
that users can see which bugs are fixed. This should be easy if there is a
partially-completed release notes file in preparation for the next release.

In other words, the ELPA method should be highlighted as the preferred
method of installation, and it should be made obvious that it's stable
(this is why I think it's important to change the version of the ELPA
package to contain the version number; by the way, considering it as a
semver version number, it already is monotonic).

Being able to install org-mode stable from ELPA is something I've wanted
for years without realising it is already available! I bet I'm not the only
one…

-- 
http://rrt.sc3d.org

Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Achim Gratz]

Nicolas Goaziou writes:
> However, I think we should make more frequent bugfix releases. We may
> even automate such releases, e.g., one week after the last unreleased
> bugfix in the branch. I don't do releases however, so this may just be
> a weird idea.

We already have that, it's the Org package on GNU ELPA.  There's a new
release each monday, fully automated.

> Also, I'd rather have monotonic version tags, so 8.3.6.whatever is not
> really an option. Maybe 8.3.YYYMMDD... and we drop manual bugfix
> releases altogether.

No, the reason for versioning Org on ELPA in that way is how package.el
interprets version numbers.  You'll get a version string you can
correlate to the Git repo from org-version.


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

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

Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> Nicolas Goaziou writes:
>> However, I think we should make more frequent bugfix releases. We may
>> even automate such releases, e.g., one week after the last unreleased
>> bugfix in the branch. I don't do releases however, so this may just be
>> a weird idea.
>
> We already have that, it's the Org package on GNU ELPA.  There's a new
> release each monday, fully automated.

This is not exactly what I'm suggesting, although the mechanism involved
is probably the same.

I'm suggesting to do a "real release", i.e., with a reassuring version
number (Org 8.3.7, Org 8.3.8). 

Also, the rule I suggest is different: "one week after last unreleased
bugfix" vs "next monday after first unreleased bugfix". One major issue
with the current rule is, e.g., when you introduce a toxic bugfix on
a gloomy Sunday.


Regards,

-- 
Nicolas Goaziou