emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Simon Thum <simon.thum@gmx.de>
To: Bastien <bzg@altern.org>
Cc: daimrod <daimrod@gmail.com>, emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Bug? Agenda problems after update
Date: Sun, 03 Mar 2013 16:21:47 +0100	[thread overview]
Message-ID: <51336A8B.5050005@gmx.de> (raw)
In-Reply-To: <5133600A.5070702@gmx.de>


Ahh, crap. Sorry to have spread confusion. The issues persit - except 
for the last one (4). I probably defected to the emacs org which 
miraculousy had 2 secs agenda generation time, not 16.

I removed the built-in one to avoid future confusion, but cannot dig 
deeper now.

Cheers,

Simon

On 03/03/2013 03:36 PM, Simon Thum wrote:
> Hi Bastien,
>
> I tried to reproduce using -q and had another error occurring in
> customizing the agenda (hard to reproduce agenda problem with a blank
> list):
>
> apropos-parse-pattern: Wrong type argument: stringp
>
> occurs when using the search button. This is emacs org, from
>
> GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) due to -q.
>
> The below refers to git emacs, of course.
>
>
> On 03/03/2013 07:34 AM, Bastien wrote:
>> Hi Simon,
>>
>> thanks for reporting those problems.
>>
>> Simon Thum <simon.thum@gmx.de> writes:
>>
>>> Press key for agenda command (unrestricted):
>>> Update Org Contacts Database
>>> Bad sexp at line 350 in /home/simon/org/privat.org:
>>> (org-contacts-anniversaries "BIRTHDAY" "%y. Geburtstag %l") [7 times]
>>> Invalid face reference: nil [619 times]
>>>
>>> 1: Altough org-contacts is invoked, birthdays fail. I tried both sexp
>>> syntaxes (%%() and <%%()>).
>>
>> I'm cc'ing Grégory, maybe this is related to recent changes in
>> org-contact.el.  Grégory, can you have a look ?
>
> Don't look in the wrong end - I checked out an out org-contacts.el
> (127bffa9e9cfe525fad0d8c) but the issue persisted. Also see below.
>
>>
>>> 2: Hovering the mouse over the agenda produces these nil face
>>> warnings. I
>>> have no idea how to diagnose this, but it does not hurt much it
>>> seems. On
>>> every mouse motion event that hovers over agenda lines below today
>>> (except
>>> for the first line below today's date line, misteriously, and only if a
>>> certain line with a past-due deadline with [#C] priority cookie is
>>> visible), one such warning is produced.
>>
>> Mhh... I can't reproduce this.  Can you give a recipe?  What emacs
>> version is it with?
>
> I tried a lot of stuff and this is triggering it for me:
> (setq org-highest-priority ?B)
> (setq org-lowest-priority ?D)
> (setq org-default-priority ?D)
>
> However, this seems just a factor. Removing it works but is undesirable
> for me, and re-adding it in an otherwise minimal config is fine too. I'm
> dropping this for now, let's see how my windows box responds.
>
>>
>>> 3: The agenda dropped back to 10 sec and more. I used to have agenda
>>> generation times of 2-3 sec after I switched to SSDs. I hope this is the
>>> issue from the "org-agenda-write taking very long" thread currently
>>> going
>>> on.
>>
>> I don't think it is the same issue.  Here again, can you give a hint
>> on what your configuration and agenda file/command look like?
> Well, even the default agenda was pretty lousy. But guess what? I
> executed one of my not-so-daily review (block-) agendas, and whatever it
> did, it fixed the issue. Could that be? I'm at a loss to explain things,
> but the slowdown is gone now. Some cache/temp file issue?
>
> Is there some kind of "make clean" for the operational org-mode?
>
> What's even better, since that the org-contacts integration is working
> fine again! Maybe that was the culprit, or my whole setup is somehow
> botched.
>
>>
>>> 4: When jumping to a file from the agenda, it is completely visible,
>>> including ARCHIVE tags (which otherwise work as expected). Just opening
>>> them is fine; it only affects the case the agenda file was not loaded
>>> before. Thus it seems to be a bug.
>>
>> (setq org-agenda-inhibit-startup nil)
>>
>> The new default is supposed to make the agenda generation faster,
>> actually.  Tassilo reported it was not speeding up things and I need
>> to check this again.
>
> Apparently, it did not slowdown mine but fixed the issue. Thanks!
>
> So the nil face is the only issue left, and it depends a lot on config.
> I will see if I can find out more.
>
> Cheers,
>
> Simon
>
>
>

  reply	other threads:[~2013-03-03 15:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-02 16:52 Bug? Agenda problems after update Simon Thum
2013-03-03  6:34 ` Bastien
2013-03-03 14:36   ` Simon Thum
2013-03-03 15:21     ` Simon Thum [this message]
2013-03-03 16:50     ` Bastien
2013-03-03 17:28       ` Simon Thum
2013-03-03  7:07 ` Charles Philip Chan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51336A8B.5050005@gmx.de \
    --to=simon.thum@gmx.de \
    --cc=bzg@altern.org \
    --cc=daimrod@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).