Re: Quit and Error in org-export--dispatch-action

[Takaaki Ishikawa]

Dear Kyle and all,

Thank you for your kind feedback.

> Thanks for providing more context.  So if I'm understanding correctly,
> the point here is that for your use case/setup you'd like to call
> delete-window even when you select 'q' within the org-export-dispatch
> call. Signaling a user-error doesn't make this much more difficult: you
> can wrap the `(apply f ...)' call within a condition-case.

Yes. But I found out `C-g' also exits `org-export-dispatch’ and
it is difficult for me to catch `C-g' signal in the original advice function.

So I’ve tried again and produced the following code to support calling any 
additional functions before and after `org-export-dispatch’ even if user types 
`q` or `C-g`.
In this case, using user-error is OK for me :)

#+begin_src emacs-lisp
(with-eval-after-load "ox"
  (defvar my-org-export-before-hook nil)
  (add-hook 'my-org-export-before-hook #'split-window-horizontally)

  (defvar my-org-export-after-hook nil)
  (add-hook 'my-org-export-after-hook #'delete-window)

  (defun my-org-export--post-processing ()
    (when (eq this-command 'org-export-dispatch)
      (run-hooks 'my-org-export-after-hook))
    (remove-hook 'post-command-hook #'my-org-export--post-processing))

  (defun my-org-export-dispatch (f ARG)
    (cond (org-export-dispatch-use-expert-ui
           (apply f ARG))
          ((> (frame-width) 160)
           (when my-org-export-after-hook
             (add-hook 'post-command-hook #'my-org-export--post-processing))
           (run-hooks 'my-org-export-before-hook)
           (apply f ARG))
          (t
           (apply f ARG))))
  (advice-add 'org-export-dispatch :around #'my-org-export-dispatch))
#+end_src

I created a patch for this issue. Please find an attached patch.
It is a really tiny patch. But I have already signed the copyright
assignment with FSF.


> I see two related advantages of sticking to signaling an error here:
> 
> * It stays close to what the current code does.  Continuing to signal
>   an error but replacing `error' with `user-error' reduces the risk of
>   bugs or unintended changes in behavior while avoiding showing a
>   backtrace when the caller aborts and debug-on-error is true (the
>   initial issue reported in this thread).
> 
> * 'q' is described as aborting, so I think it's confusing to make 'q'
>   instead execute a no-op function and continue with the remaining code
>   in the outer functions, which at the moment boils down to code in
>   org-export-dispatch.  For example, with your suggested change,
>   issuing 'q' will result in `ignore' being saved as the last export
>   action, and it's hard to imagine that's an action the user would
>   expect or want to repeat when calling org-export-dispatch with a
>   prefix argument.

I partially agree with you because the dispatcher shows it
as “[q] Exit”. This is actually different from “[q] Aborting”.
Typing `q` is completely intended by user to exit the procedure.
If something is happened accidentally in the procedure,
then, IMO, we should say it as “aborting” and update the code appropriately.

Anyway, replacing with `user-error` is OK.

Best,
Takaaki

0001-ox.el-Replace-error-with-user-error-to-exit-org-expo.patch
Description: Binary data