Killed Org files referred from the agenda?

Killed Org files referred from the agenda?

[François Pinard]

Hi, Org people!

Now that many Org files are part of my agenda list, it became more
likely that I inadvertently kill one of them.  Then, commands like "t"
or "RET" in the agenda fail.

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  goto-char(nil)
  (let* ((marker ...) (buffer ...) (pos ...)) (org-pop-to-buffer-same-window buffer) (and delete-other-windows (delete-other-windows)) (widen) (goto-char pos) (when (eq major-mode ...) (org-show-context ...) (save-excursion ...) (when ... ...)))
  (if (and org-return-follows-link (not ...) (org-in-regexp org-bracket-link-regexp)) (org-open-link-from-string (match-string 0)) (let* (... ... ...) (org-pop-to-buffer-same-window buffer) (and delete-other-windows ...) (widen) (goto-char pos) (when ... ... ... ...)))
  org-agenda-switch-to()
  call-interactively(org-agenda-switch-to nil nil)
--8<---------------cut here---------------end--------------->8---

I have to first revisit the Org file by some other mean first, for such
commands to succeed.  Could Org do the revisiting as needed, instead of
raising an error?

François

Re: Killed Org files referred from the agenda?

[Nick Dokos]

François Pinard <pinard@iro.umontreal.ca> wrote:

> Hi, Org people!
> 
> Now that many Org files are part of my agenda list, it became more
> likely that I inadvertently kill one of them.  Then, commands like "t"
> or "RET" in the agenda fail.
> 
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>   goto-char(nil)
>   (let* ((marker ...) (buffer ...) (pos ...)) (org-pop-to-buffer-same-windo=
> w buffer) (and delete-other-windows (delete-other-windows)) (widen) (goto-c=
> har pos) (when (eq major-mode ...) (org-show-context ...) (save-excursion .=
> ..) (when ... ...)))
>   (if (and org-return-follows-link (not ...) (org-in-regexp org-bracket-lin=
> k-regexp)) (org-open-link-from-string (match-string 0)) (let* (... ... ...)=
>  (org-pop-to-buffer-same-window buffer) (and delete-other-windows ...) (wid=
> en) (goto-char pos) (when ... ... ... ...)))
>   org-agenda-switch-to()
>   call-interactively(org-agenda-switch-to nil nil)
> 
> I have to first revisit the Org file by some other mean first, for such
> commands to succeed.  Could Org do the revisiting as needed, instead of
> raising an error?
> 

Just do "g" in the agenda and retry the "t".

Nick

Re: Killed Org files referred from the agenda?

[François Pinard]

Nick Dokos <nicholas.dokos@hp.com> writes:

> François Pinard <pinard@iro.umontreal.ca> wrote:

>> Now that many Org files are part of my agenda list, it became more
>> likely that I inadvertently kill one of them.  Then, commands like
>> "t" or "RET" in the agenda fail.  I have to first revisit the Org
>> file by some other mean first, for such commands to succeed.  Could
>> Org do the revisiting as needed, instead of raising an error?
>> 

> Just do "g" in the agenda and retry the "t".

Thanks for hint, Nick, I'll surely use it.

Yet, I do not think it is appropriate for Org to raise an Emacs Lisp
error.  It really looks like a bug.

François

Re: Killed Org files referred from the agenda?

[Bernt Hansen]

pinard@iro.umontreal.ca (François Pinard) writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> François Pinard <pinard@iro.umontreal.ca> wrote:
>
>>> Now that many Org files are part of my agenda list, it became more
>>> likely that I inadvertently kill one of them.  Then, commands like
>>> "t" or "RET" in the agenda fail.  I have to first revisit the Org
>>> file by some other mean first, for such commands to succeed.  Could
>>> Org do the revisiting as needed, instead of raising an error?
>>> 
>
>> Just do "g" in the agenda and retry the "t".
>
> Thanks for hint, Nick, I'll surely use it.
>
> Yet, I do not think it is appropriate for Org to raise an Emacs Lisp
> error.  It really looks like a bug.
>
> François

Rebuilding the agenda buffer (with 'g') is potentially expensive -- I
don't want a multi-second delay in my block view whenever Emacs thinks
that is appropriate.

I'd rather have full manual control over when things are rebuilt.  I
think your error is generated because your agenda is out of date so the
markers on the agenda view are old and possibly pointing at the wrong
stuff.  Keeping this up to date automagically will make org-mode much
slower and less usable (for me)

So here's one vote against.

Regards,
Bernt

Re: Killed Org files referred from the agenda?

[Nick Dokos]

François Pinard <pinard@iro.umontreal.ca> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > François Pinard <pinard@iro.umontreal.ca> wrote:
> 
> >> Now that many Org files are part of my agenda list, it became more
> >> likely that I inadvertently kill one of them.  Then, commands like
> >> "t" or "RET" in the agenda fail.  I have to first revisit the Org
> >> file by some other mean first, for such commands to succeed.  Could
> >> Org do the revisiting as needed, instead of raising an error?
> >> 
> 
> > Just do "g" in the agenda and retry the "t".
> 
> Thanks for hint, Nick, I'll surely use it.
> 
> Yet, I do not think it is appropriate for Org to raise an Emacs Lisp
> error.  It really looks like a bug.
> 

But it is an error: you've gotten rid of a buffer that it expected to
find.  Admittedly however, the error should be caught and a reasonable
error message printed out (something like ``Try pressing "g" in the
agenda and then retry the command '' :-) ) This would alleviate Bernt's
performance concerns as well: if you make the mistake (kill a buffer
that's needed), you suffer the consequences (slow rebuilding of the
agenda) - it does not affect anybody else.

Maybe org-with-remote-undo can check if the buffer argument is nil and
complain if it is.

Nick

Re: Killed Org files referred from the agenda?

[Bastien]

As an exercise, we can have a function checking for markers
in the current agenda and double-checking for the existence
of the associated buffer.  The user could run this function
regularily in an agenda buffer if he wants.

Anyone?

-- 
 Bastien

Re: Killed Org files referred from the agenda?

[Jambunathan K]

,----[ C-h f emacs-lock-mode RET ]
| emacs-lock-mode is an interactive autoloaded Lisp function in
| `emacs-lock.el'.
| 
| (emacs-lock-mode &optional ARG)
| 
| Toggle Emacs Lock mode in the current buffer.
| If called with a plain prefix argument, ask for the locking mode
| to be used.  With any other prefix ARG, turn mode on if ARG is
| positive, off otherwise.  If called from Lisp, enable the mode if
| ARG is omitted or nil.
| 
| Initially, if the user does not pass an explicit locking mode, it
| defaults to `emacs-lock-default-locking-mode' (which see);
| afterwards, the locking mode most recently set on the buffer is
| used instead.
| 
| When called from Elisp code, ARG can be any locking mode:
| 
|  exit   -- Emacs cannot exit while the buffer is locked
|  kill   -- the buffer cannot be killed, but Emacs can exit as usual
|  all    -- the buffer is locked against both actions
| 
| Other values are interpreted as usual.
| 
| [back]
`----

Emacs-24.1 has the following NEWS entry.

,----
| ** New emacs-lock.el package.
| (The previous version has been moved to obsolete/old-emacs-lock.el.)
| Now, there is a proper minor mode `emacs-lock-mode'.
| Protection against exiting Emacs and killing the buffer can be set
| separately.  The mechanism for automatically turning off protection
| for buffers with dead inferior processes has been generalized.
`----

--