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

[Kyle Meyer]

Takaaki Ishikawa <address@hidden> writes:

> Dear Kyle and all,
>
> Using user-error is another way, but it does not work for me
> because user-error stops the org-export-dispatch.
> I would like to keep the session to do an action after
> the completing org-export-dispatch something like this:
>
>   (defun my-org-export-dispatch (f ARG)
>     (interactive "P")
>     (if (< (frame-width) 160)
>         (apply f ARG)
>       (split-window-right)
>       (apply f ARG)
>       (delete-window)))
>   (advice-add 'org-export-dispatch :around #'my-org-export-dispatch)
>
> So I still prefer to replace the error function with a simple message 
> function.

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.

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.