From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kyle Meyer <kyle@kyleam.com>
Subject: Re: Quit and Error in org-export--dispatch-action
Date: Fri, 06 Dec 2019 03:48:32 +0000
Message-ID: <874kyeglm7.fsf@kyleam.com>
References: <CAJsv8TFgMbjRGEb1D+bZkg9W0CWUR5KtFh7zdUdGm6FFrxPouA@mail.gmail.com>
 <87a787gj9h.fsf@kyleam.com>
 <CAJsv8TEn-YX6aND8a_FaZ1go_XoXUPC88EM7ZAhi6j7_QKoedw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:34661)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <kyle@kyleam.com>) id 1id4be-0004s9-2f
 for emacs-orgmode@gnu.org; Thu, 05 Dec 2019 22:48:39 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kyle@kyleam.com>) id 1id4bc-00008O-5U
 for emacs-orgmode@gnu.org; Thu, 05 Dec 2019 22:48:37 -0500
Received: from pb-smtp2.pobox.com ([64.147.108.71]:51985)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <kyle@kyleam.com>) id 1id4bb-0008Ur-Nk
 for emacs-orgmode@gnu.org; Thu, 05 Dec 2019 22:48:36 -0500
In-Reply-To: <CAJsv8TEn-YX6aND8a_FaZ1go_XoXUPC88EM7ZAhi6j7_QKoedw@mail.gmail.com>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
 <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: Takaaki Ishikawa <takaxp@ieee.org>
Cc: orgmode list <emacs-orgmode@gnu.org>

Takaaki Ishikawa <takaxp@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.