Agenda highlighting bug

Agenda highlighting bug

[Simon Thum]

Hi all,

I recently added an org file which is an import from our community 
service, the so-called "Müllabfuhr", which I put in "müllabfuhr.org".

The agenda fails to highlight these entries however. It's not terrible, 
actually it's JUST PERFECT because this is such a minor thing but it 
sucks to miss it.

Now that's obviously a bug. But I really like to attenuate some entries, 
just as approaching deadlines are set in bold. Is there any feature to 
achieve this (ideally based on tags, not presence of weird characters in 
the file name)?

Cheers,

Simon

Re: Agenda highlighting bug

[Bastien]

Hi Simon,

Simon Thum <simon.thum@gmx.de> writes:

> I recently added an org file which is an import from our community service,
> the so-called "Müllabfuhr", which I put in "müllabfuhr.org".
>
> The agenda fails to highlight these entries however. It's not terrible,
> actually it's JUST PERFECT because this is such a minor thing but it sucks
> to miss it.

Could you provide a minimal config and example to reproduce this bug?  
Special character should not prevent the inclusion of tasks in the
agenda, and I never noticed anything like this before...

Best,

-- 
 Bastien

Re: Agenda highlighting bug

[Simon Thum]

On 12/24/2012 09:48 AM, Bastien wrote:
> Hi Simon,
>
> Simon Thum<simon.thum@gmx.de>  writes:
>
>> I recently added an org file which is an import from our community service,
>> the so-called "Müllabfuhr", which I put in "müllabfuhr.org".
>>
>> The agenda fails to highlight these entries however. It's not terrible,
>> actually it's JUST PERFECT because this is such a minor thing but it sucks
>> to miss it.
>
> Could you provide a minimal config and example to reproduce this bug?
> Special character should not prevent the inclusion of tasks in the
> agenda, and I never noticed anything like this before...

I can't reproduce it currently, maybe it was just that most agenda 
entries are scheduled/dealined and the highlighting was actually normal.

The more difficult problem for me was that the agenda file in my case 
contains a list of files which is synchronised over systems. Wherever I 
add this file (win32 vs. linux) the other system fails to load the 
agenda then.

I dropped back to non-special surrogates but it feels like 90s. Can I 
set the agenda file's encoding or is there something else which comes to 
mind?

I'd also like to use this opportunity to ask about more graceful agenda 
handling of changed files. When someone (not emacs) touches agenda 
files, the agenda code fails horribly. That is even if the file is 
readonly or has the "#+READONLY" header (which seems menaingful only to 
org-mobile). It would be preferable to just reload in this case. ATM, I 
am queried about something related to reloading and the agenda cancels 
no matter what I say.

Cheers,

Simon

Re: Agenda highlighting bug

[Bastien]

Hi Simon,

Simon Thum <simon.thum@gmx.de> writes:

> I dropped back to non-special surrogates but it feels like 90s. Can I set
> the agenda file's encoding or is there something else which comes to mind?

Let's first try to reproduce the bug :)

-- 
 Bastien

In agenda, better handling of files changed behind Org's back (was: Agenda highlighting bug)

[Bastien]

Hi Simon,

(New thread for this topic.)

Simon Thum <simon.thum@gmx.de> writes:

> I'd also like to use this opportunity to ask about more graceful agenda
> handling of changed files. When someone (not emacs) touches agenda files,
> the agenda code fails horribly.   That is even if the file is readonly or has
> the "#+READONLY" header (which seems menaingful only to org-mobile). It
> would be preferable to just reload in this case. ATM, I am queried about
> something related to reloading and the agenda cancels no matter what I
> say.

I get the gist of what may happen here, but I'd need a reproducible 
recipe to know where to put the checks.  Sorry to put the burden on
your shoulders, but this would help a lot!

Thanks,

-- 
 Bastien

Re: In agenda, better handling of files changed behind Org's back

[Simon Thum]

On 12/29/2012 11:29 AM, Bastien wrote:
> Hi Simon,
>
> (New thread for this topic.)
>
> Simon Thum<simon.thum@gmx.de>  writes:
>
>> I'd also like to use this opportunity to ask about more graceful agenda
>> handling of changed files. When someone (not emacs) touches agenda files,
>> the agenda code fails horribly.   That is even if the file is readonly or has
>> the "#+READONLY" header (which seems menaingful only to org-mobile). It
>> would be preferable to just reload in this case. ATM, I am queried about
>> something related to reloading and the agenda cancels no matter what I
>> say.
>
> I get the gist of what may happen here, but I'd need a reproducible
> recipe to know where to put the checks.  Sorry to put the burden on
> your shoulders, but this would help a lot!

It's not a burden at all. This recipe breaks for me:

1 ) invoke agenda

2) > touch some_agenda_file.org

3) invoke agenda again

I am asked: some_agenda_file.org changed on disk; really edit the 
buffer? (y, n, r or C-h)

No matter what I answer, the agenda does not show up. Using r, I can get 
the agenda in a repeat call.

My argument is that read-only buffers are not supposed to change on 
emacs' side, so it would always be OK to re-read them.

Cheers,

Simon

Re: In agenda, better handling of files changed behind Org's back

[Bastien]

Hi Simon,

Simon Thum <simon.thum@gmx.de> writes:

> It's not a burden at all. This recipe breaks for me:
>
> 1 ) invoke agenda
>
> 2) > touch some_agenda_file.org
>
> 3) invoke agenda again
>
> I am asked: some_agenda_file.org changed on disk; really edit the buffer?
> (y, n, r or C-h)
>
> No matter what I answer, the agenda does not show up. Using r, I can get
> the agenda in a repeat call.
>
> My argument is that read-only buffers are not supposed to change on emacs'
> side, so it would always be OK to re-read them.

I understand and I agree.  

There is no simple fix, though.  I'll put this on my "watch list".

Best,

-- 
 Bastien

Re: In agenda, better handling of files changed behind Org's back

[Simon Thum]

On 12/29/2012 02:29 PM, Bastien wrote:
> Hi Simon,
>
> Simon Thum<simon.thum@gmx.de>  writes:
>
>> It's not a burden at all. This recipe breaks for me:
>>
>> 1 ) invoke agenda
>>
>> 2)>  touch some_agenda_file.org
>>
>> 3) invoke agenda again
>>
>> I am asked: some_agenda_file.org changed on disk; really edit the buffer?
>> (y, n, r or C-h)
>>
>> No matter what I answer, the agenda does not show up. Using r, I can get
>> the agenda in a repeat call.
>>
>> My argument is that read-only buffers are not supposed to change on emacs'
>> side, so it would always be OK to re-read them.
>
> I understand and I agree.
>
> There is no simple fix, though.  I'll put this on my "watch list".

Thanks for that. I assumed it would be easier.

I'm using a fair amount of generated org files, and what especially 
sucks with this behaviour is that _each changed file_ requires one 
agenda building attempt. So before re-reading 3 org files it is easier 
to restart emacs.

Cheers,

Simon

Re: In agenda, better handling of files changed behind Org's back

[Achim Gratz]

Am 29.12.2012 14:29, schrieb Bastien:
>> My argument is that read-only buffers are not supposed to change on emacs'
>> side, so it would always be OK to re-read them.

If that is true (I don't really know), then auto-revert-mode should keep 
them in sync with the file on disk.

> There is no simple fix, though.  I'll put this on my "watch list".

I think that, aside from the above suggestion, it may be worth pondering 
if Org should really "visit" those files that it just needs to look at 
for building the agenda.  If it would not visit them (Emacs must visit a 
file that the user opened in edit mode obviously), the problem should 
not appear.


-- 
Achim.

(on the road :-)

Re: In agenda, better handling of files changed behind Org's back

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@Nexgo.DE> writes:

> I think that, aside from the above suggestion, it may be worth pondering if
> Org should really "visit" those files that it just needs to look at for
> building the agenda.  If it would not visit them (Emacs must visit a file
> that the user opened in edit mode obviously), the problem should not
> appear.

The problem is that Org does not only need to "look" at the files,
it also adds text properties for example, which is considered editing
by Emacs, even the modification only affects the buffer, not the file.

We could try to use `with-buffer-modified-unmodified' a bit more, but
I'm not convinved.

-- 
 Bastien