--- Begin Message ---
|
Subject: |
[FR] Expose `interactive' arg handling as an Elisp function |
|
Date: |
Fri, 31 Mar 2023 15:27:47 +0800 |
|
User-agent: |
mu4e 1.8.14; emacs 30.0.50 |
Hello,
I find myself sometimes needing to manually write code that do the same
job as the string-form `interactive' would do, like "read for an
existing file name" (the "f" form), etc. This happens because I want to
do the following conversion.
--8<---------------cut here---------------start------------->8---
(defun foo (fname)
(interactive "f")
(ignore fname))
(defun foo (fname bar)
(interactive
(list (simulate-interactive-f)
(get-bar)))
(ignore fname bar))
--8<---------------cut here---------------end--------------->8---
In short, this is useful when I need to add an interactive argument that
is not already covered by interactive codes, so I have to use the more
verbose interactive list form.
Currently, the code that handles interactive codes is written as part of
`call-interactively'. This is in src/callint.c,
DEFUN("call-interactively").
In fact, there is already _a way_ to do it (I consider it more like a
workaround). However, I think my proposal might be more concise than
the workaround for readers. And also more performant, since the
workaround unnecessarily creates a lambda and then extracts its
interactive form, only to make use of the result of its interactive
code.
--8<---------------cut here---------------start------------->8---
(call-interactively (lambda (f) (interactive "f") f))
--8<---------------cut here---------------end--------------->8---
If people are in favor of exposing the interactive codes, I imagine it
can be defined as `interactive-handle-code (code &optional prompt)', and
I would be able to do this:
--8<---------------cut here---------------start------------->8---
(interactive-handle-code ?f)
(interactive-handle-code ?M "Insert some random text: ")
;; etc
--8<---------------cut here---------------end--------------->8---
Alternatively, if we believe that my c-i + λ workaround is sufficiently
small, we could advise people in the same boat to follow suit? That
implies modifying the `interactive' docstring and (info "(elisp)
Interactive Codes").
--
Best,
RY
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#62563: [FR] Expose `interactive' arg handling as an Elisp function |
|
Date: |
Mon, 11 Sep 2023 16:54:50 -0700 |
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Fri, 31 Mar 2023 15:27:47 +0800
>> From: Ruijie Yu via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> I find myself sometimes needing to manually write code that do the same
>> job as the string-form `interactive' would do, like "read for an
>> existing file name" (the "f" form), etc. This happens because I want to
>> do the following conversion.
>>
>> --8<---------------cut here---------------start------------->8---
>> (defun foo (fname)
>> (interactive "f")
>> (ignore fname))
>>
>> (defun foo (fname bar)
>> (interactive
>> (list (simulate-interactive-f)
>> (get-bar)))
>> (ignore fname bar))
>> --8<---------------cut here---------------end--------------->8---
>>
>> In short, this is useful when I need to add an interactive argument that
>> is not already covered by interactive codes, so I have to use the more
>> verbose interactive list form.
>
> I don't think I understand the rationale, so please tell more. The
> interactive spec can be used like this:
>
> (interactive "bBuffer to rename: \nsRename buffer %s to: ")
>
> So basically, you can prompt for anything using the 's' descriptor and
> the following prompt string with %-constructs. In what use cases is
> this not enough, so much so that it would require exposing the guts of
> this to Lisp?
More information was requested, but none was given within 6 months, so
I'm closing this bug. If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.
--- End Message ---