* Killed Org files referred from the agenda?
@ 2012-04-12 15:20 François Pinard
2012-04-12 16:02 ` Nick Dokos
0 siblings, 1 reply; 7+ messages in thread
From: François Pinard @ 2012-04-12 15:20 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Killed Org files referred from the agenda?
2012-04-12 15:20 Killed Org files referred from the agenda? François Pinard
@ 2012-04-12 16:02 ` Nick Dokos
2012-04-12 16:37 ` François Pinard
0 siblings, 1 reply; 7+ messages in thread
From: Nick Dokos @ 2012-04-12 16:02 UTC (permalink / raw)
To: =?utf-8?Q?Fran=C3=A7ois?= Pinard; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Killed Org files referred from the agenda?
2012-04-12 16:02 ` Nick Dokos
@ 2012-04-12 16:37 ` François Pinard
2012-04-12 16:56 ` Bernt Hansen
2012-04-12 19:30 ` Nick Dokos
0 siblings, 2 replies; 7+ messages in thread
From: François Pinard @ 2012-04-12 16:37 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Killed Org files referred from the agenda?
2012-04-12 16:37 ` François Pinard
@ 2012-04-12 16:56 ` Bernt Hansen
2012-04-12 19:30 ` Nick Dokos
1 sibling, 0 replies; 7+ messages in thread
From: Bernt Hansen @ 2012-04-12 16:56 UTC (permalink / raw)
To: François Pinard; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Killed Org files referred from the agenda?
2012-04-12 16:37 ` François Pinard
2012-04-12 16:56 ` Bernt Hansen
@ 2012-04-12 19:30 ` Nick Dokos
2012-04-13 5:07 ` Bastien
1 sibling, 1 reply; 7+ messages in thread
From: Nick Dokos @ 2012-04-12 19:30 UTC (permalink / raw)
To: =?utf-8?Q?Fran=C3=A7ois?= Pinard; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Killed Org files referred from the agenda?
2012-04-12 19:30 ` Nick Dokos
@ 2012-04-13 5:07 ` Bastien
2012-04-13 10:21 ` Jambunathan K
0 siblings, 1 reply; 7+ messages in thread
From: Bastien @ 2012-04-13 5:07 UTC (permalink / raw)
To: nicholas.dokos; +Cc: "François" Pinard, emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Killed Org files referred from the agenda?
2012-04-13 5:07 ` Bastien
@ 2012-04-13 10:21 ` Jambunathan K
0 siblings, 0 replies; 7+ messages in thread
From: Jambunathan K @ 2012-04-13 10:21 UTC (permalink / raw)
To: Bastien; +Cc: \"François\" Pinard, nicholas.dokos, emacs-orgmode
,----[ 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.
`----
--
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-04-13 10:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-12 15:20 Killed Org files referred from the agenda? François Pinard
2012-04-12 16:02 ` Nick Dokos
2012-04-12 16:37 ` François Pinard
2012-04-12 16:56 ` Bernt Hansen
2012-04-12 19:30 ` Nick Dokos
2012-04-13 5:07 ` Bastien
2012-04-13 10:21 ` Jambunathan K
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).