How to set prompt value programmatically?

Hi, I am finding hard to use Nyxt commands via Common Lisp. I guess this is by design (what is the reason btw?).
I was thinking to make a macro/function with-prompt-value that emulates a user inserting a string in the prompt, so that I can use commands like open-file like this (with-prompt-value "/tmp/myfile.txt" (open-file)).

Am I going in the wrong way? Do you know if such a macro/function is already around?

You might look at the set-url prompt in which we prefill the URL, I can’t remember off the top of my head, but it should be possible!

The reason you can only see some commands in the prompt is because only commands for active modes are visible. If a mode is not active, it’s commands are not visible. Perhaps this could be a setting/configuration!

Mmm, thanks. I see that prompt takes an :input that I could use:

(define-command set-url (&key (prefill-current-url-p t))
  "Set the URL for the current buffer, completing with history."
 ...
    (prompt
     :prompt "Open URL"
     :input (if prefill-current-url-p
                (render-url (url (current-buffer))) "")
     ...))

I am not sure I explained myself well. I will try again.
I wanted to open a QR code I generated with Nyxt (see Extending Nyxt via Emacs: how to leverage Common Lisp wealth to get your links as QR codes - Where parallels cross).
I want to do this via the Slime REPL, ideally with (open-file "myQRcode").
But open-file does not take a path argument. So I was thinking to somehow mimic the user input to skip the interactive bit.
In ELisp you have interactive functions: they would look like (defun x (arg) (interactive (list (ask-for-input)) ...), where the function input arg is used unless the function is called as a commnad: is not possible to have something like that in Nyxt?
I mean that the function prompt is called only if I invoke the command from Nyxt, but I can pass an input when I am invoking the command from a Lisp REPL?

Totally, we do this in many commands, and it’s even easier than with Emacs.

Simply provide an &optional or &key argument, then if this argument is nil, you can prompt the user to set it.

nyxt/bookmark.lisp at 2.1.1 · atlas-engineer/nyxt · GitHub bookmark-current-url for example.

Does that help?

It is thanks. Just a last push though: this is how open-file is defined.
(define-command open-file (&key (default-directory *default-pathname-defaults*)) ...
If I call it with (open-file :default-directory "/home/andrea/workspace/nyxt/source/file-manager.lisp"), I get Slime’s REPL to hang and an open prompt in Nyxt.
I would like Nyxt to just open the file if I provide the argument.
Do you suggest I redefine open-file to take another optional argument that if present skips to call prompt?

Edit: the reason I wanted that is that I would like to open the QR code when I invoke the command “make a QR code for current URL”, and it should not prompt me for the file because Nyxt knows where to find the QR code.

open-file may not be what you want to use.

What do you want to do with this file? Is it an output file, an input file?

It is an output file. Imagine you are on a page and want to open it with your phone. With my extension you can make a QR code image that gets stored on the file system. I would like that once you invoke the command “make QR code”, that QR code appears on your screen.
The command open-file does that, but only works interactively. Is there a better function?
And again, if I use that interactively from Nyxt, would not be easier to use that also from a REPL? You see, now I need to know two functions to open files :stuck_out_tongue:

Indeed, open-file is intended for interactive use. This may change in the future.

For now use the regular CL macro with-open-file. Let me know if you need help with it.

1 Like

Ah okay! I get I should leverage Common Lisp for displaying a file instead of relying on Nyxt. I totally not think about that because I was so focused on using Nyxt built-in operations.
It would be ideal for me if all commands could be used both interactively and through Common Lisp. That is why I was mentioning the (interactive) feature of Emacs Lisp.

A bit late, but here are the links to the relevant GitHub issues: