[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62563: [FR] Expose `interactive' arg handling as an Elisp function
From: |
Stefan Kangas |
Subject: |
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.
- bug#62563: [FR] Expose `interactive' arg handling as an Elisp function,
Stefan Kangas <=