Bug?: org-agenda-set-property sets property on wrong element

Bug?: org-agenda-set-property sets property on wrong element

[Max Mikhanosha]

Can someone confirm this, before I try to fix this?

1. Generate agenda
2. Go to some entry A by pressing RET
3. Switch back to agenda, and make sure its the only window (or that
   A's buffer is not in any other window)
4. In Agenda navigate to entry B (in the same buffer as A), and C-c
   C-x p (org-agenda-set-property), use any property name or value

Result: property is set in entry A not in entry B. This is with
org-mode from git, and emacs 23.

The problem seems to be that the code like this (with-current-buffer
buffer (goto-char pos (call-interactively 'some-command)) the point
inside of 'some-command will not be at `pos', but where the user last
moved it, _unless_ the buffer's window is selected window, then
(goto-char) sticks through (call-interactively) boundary.

Could be that there are other pieces of code like this in lurking in
there.

Regards,
  Max

Re: Bug?: org-agenda-set-property sets property on wrong element

[Max Mikhanosha]

At Thu, 28 Jun 2012 06:16:06 -0400,
Max Mikhanosha wrote:
> 
> The problem seems to be that the code like this (with-current-buffer
> buffer (goto-char pos (call-interactively 'some-command)) the point
> inside of 'some-command will not be at `pos', but where the user last
> moved it, _unless_ the buffer's window is selected window, then
> (goto-char) sticks through (call-interactively) boundary.

Above was wrong, it seems the culprit is anything that uses a
completing read from minibuffer, while inside of (with-current-buffer)
for a buffer that is not visible on any window; after reading from
minibuffer the point is reset back to where user last moved it. I was
able to fix parent message's test case by putting save-excursion around
(org-icompleting-read), but I'm wondering if its my specific setup, or
if anyone else can reproduce this.