all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Thorsten Jolitz <tjolitz@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Suppress user-prompting when calling commands in programs
Date: Sat, 14 Jun 2014 10:22:36 +0200	[thread overview]
Message-ID: <87ioo3vr1v.fsf@gmail.com> (raw)
In-Reply-To: 87mwdfvrqd.fsf@gmail.com

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I tried convincing upstream before and never made it! And I actually
>>> understand the authors of code like that and even copied that technique
>>> sometimes, because it might be harder to write the interactive spec for
>>> both interactive and programmatical use than to write the function
>>> itself, and then there is no need for a wrapper command or interactive
>>> (lambda ...) expression when it comes to define a key for that command.
>>
>> I don't know what complications you're referring to.
>>
>> In 99% of the cases you can just turn
>>
>>     (defun foo (&optional arg)
>>       (interactive "P")
>>       (let ((bar (org-icompleting-read ...)))))
>>
>> into
>>
>>     (defun foo (bar &optional arg)
>>       (interactive
>>        (list (org-icompleting-read ...) current-prefix-arg))
>>
>> I'm not saying it's always perfect, but there's clearly some difference
>> between my experience and yours, so if you give some examples, it would help.

[Ups, that one was send to early accidentally ...]

Maybe I just find the Emacs Lisp Manual too dense and lacking examples
and templates for using lists in the interactive spec?

This is more or less or there is:

 ,-------------------------------------------------------------------
 | * It may be a Lisp expression that is not a string; then it should
 |   be a form that is evaluated to get a list of arguments to pass
 |   to the command. Usually this form will call various functions to
 |   read input from the user, most often through the minibuffer (see
 |   Minibuffers) or directly from the keyboard (see Reading Input).
 |  
 |   Providing point or the mark as an argument value is also common,
 |   but if you do this and read input (whether using the minibuffer
 |   or not), be sure to get the integer values of point or the mark
 |   after reading. The current buffer may be receiving subprocess
 |   output; if subprocess output arrives while the command is
 |   waiting for input, it could relocate point and the mark.
 |  
 |   Here's an example of what not to do:
 |  
 |             (interactive
 |              (list (region-beginning) (region-end)
 |                    (read-string "Foo: " nil 'my-history)))
 |   
 |   Here's how to avoid the problem, by examining point and the mark
 |   after reading the keyboard input:
 |  
 |             (interactive
 |              (let ((string (read-string "Foo: " nil 'my-history)))
 |                (list (region-beginning) (region-end) string)))
 `-------------------------------------------------------------------

But what about a case like this, a command with several optional args,
that are not always necessary. How to give the user the option to decide
for which args he wants to give input (and use the defaults for the
others)? Where to put the (prefix) 'arg argument in this case? How does
Emacs know which of the optional arguments should be the
prefix-argument? Do I need a "P" or "p" then somewhere in the spec when
I add 'arg' to the arguments list? 

I came up with something like this, but most likely inspired by other
elisp libraries, not by the manual. Is it a good solution? Hard to tell,
since there are no templates or best practice examples given for more
complex interactive specs in the manual. 

 #+begin_src emacs-lisp 
 ;; Start a REPL
 (defun iorg-scrape-repl (&optional port host how local)
   "Run inferior Picolisp and setup process for GUI-scripting."
   (interactive
    (cond
     ((equal current-prefix-arg nil) nil)
     ((equal current-prefix-arg '(4))
      (list
       (read-number "Port: ")))
     ((equal current-prefix-arg '(16))
      (list
       (read-number "Port: ")
       (read-string "Host: ")))
     ((equal current-prefix-arg '(32))
      (list
       (read-number "Port: ")
       (read-string "Host: ")
       (read-string "How: ")))
     (t
      (list
       (read-number "Port: ")
       (read-string "Host: ")
       (read-string "How: ")
       (read-string "Local: ")))))
   (let* ((hst (or host "localhost"))
          (prt (or port 5000)) [...]
 #+end_src

-- 
cheers,
Thorsten




  reply	other threads:[~2014-06-14  8:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13 13:51 Suppress user-prompting when calling commands in programs Thorsten Jolitz
2014-06-13 14:03 ` Eli Zaretskii
2014-06-13 14:25   ` Stefan Monnier
2014-06-13 15:09     ` Thorsten Jolitz
2014-06-13 15:29     ` Drew Adams
2014-06-13 15:49       ` Thorsten Jolitz
2014-06-13 14:20 ` Nicolas Richard
2014-06-13 15:18   ` Thorsten Jolitz
2014-06-13 16:04     ` Drew Adams
2014-06-13 18:14       ` Thorsten Jolitz
2014-06-14  3:33       ` Eric Abrahamsen
2014-06-14  3:36         ` Drew Adams
2014-06-14  3:47           ` Eric Abrahamsen
     [not found]   ` <mailman.3579.1402672740.1147.help-gnu-emacs@gnu.org>
2014-06-13 18:55     ` Stefan Monnier
2014-06-14  8:07       ` Thorsten Jolitz
2014-06-14  8:22         ` Thorsten Jolitz [this message]
2014-06-15  1:58           ` Stefan Monnier
2014-06-14 15:52         ` Drew Adams
2014-06-14 16:27           ` Thorsten Jolitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ioo3vr1v.fsf@gmail.com \
    --to=tjolitz@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.