Takaaki Ishikawa <tak...@ieee.org> 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.
