* Input from buffer instead of minibuffer @ 2012-09-30 20:46 Michael Haensel 2012-10-01 1:10 ` Barry Margolin ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Michael Haensel @ 2012-09-30 20:46 UTC (permalink / raw To: help-gnu-emacs Hello everyone - I'm writing a quiz program in Emacs Lisp. The program creates a new frame and buffer for the quiz questions. The quiz then runs something like this: (insert "Please identify: [quiz item]") (setq response (read-from-minibuffer "Please identify: [quiz item]")) ... do stuff based on response This displays the question in the buffer and the minibuffer. The response is read in from the minibuffer. This isn't deal-breakingly bad, but a better design would read the response from the buffer and skip the minibuffer entirely. Is there an easy way to read a response from the buffer instead of the minibuffer? If it matters, a "response" is a string of 1-8 alphabetic characters terminated by a newline/return key. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Input from buffer instead of minibuffer 2012-09-30 20:46 Input from buffer instead of minibuffer Michael Haensel @ 2012-10-01 1:10 ` Barry Margolin 2012-10-03 15:45 ` Stephen Berman 2012-10-04 13:21 ` Stefan Monnier 2012-10-04 13:56 ` Pascal J. Bourguignon 2 siblings, 1 reply; 5+ messages in thread From: Barry Margolin @ 2012-10-01 1:10 UTC (permalink / raw To: help-gnu-emacs In article <58f60ac7-2407-411c-92ba-13a4550f682a@googlegroups.com>, Michael Haensel <mhaensel73@gmail.com> wrote: > Hello everyone - > > I'm writing a quiz program in Emacs Lisp. The program creates a new frame and > buffer for the quiz questions. The quiz then runs something like this: > > (insert "Please identify: [quiz item]") > (setq response > (read-from-minibuffer "Please identify: [quiz item]")) > ... do stuff based on response > > This displays the question in the buffer and the minibuffer. The response is > read in from the minibuffer. This isn't deal-breakingly bad, but a better > design would read the response from the buffer and skip the minibuffer > entirely. > > Is there an easy way to read a response from the buffer instead of the > minibuffer? If it matters, a "response" is a string of 1-8 alphabetic > characters terminated by a newline/return key. Nothing built-in, but it should be pretty straightforward to write a command that looks in the buffer to find the response, and bind the Return key to this command. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Input from buffer instead of minibuffer 2012-10-01 1:10 ` Barry Margolin @ 2012-10-03 15:45 ` Stephen Berman 0 siblings, 0 replies; 5+ messages in thread From: Stephen Berman @ 2012-10-03 15:45 UTC (permalink / raw To: help-gnu-emacs On Sun, 30 Sep 2012 21:10:43 -0400 Barry Margolin <barmar@alum.mit.edu> wrote: > In article <58f60ac7-2407-411c-92ba-13a4550f682a@googlegroups.com>, > Michael Haensel <mhaensel73@gmail.com> wrote: > >> Hello everyone - >> >> I'm writing a quiz program in Emacs Lisp. The program creates a new frame and >> buffer for the quiz questions. The quiz then runs something like this: >> >> (insert "Please identify: [quiz item]") >> (setq response >> (read-from-minibuffer "Please identify: [quiz item]")) >> ... do stuff based on response >> >> This displays the question in the buffer and the minibuffer. The response is >> read in from the minibuffer. This isn't deal-breakingly bad, but a better >> design would read the response from the buffer and skip the minibuffer >> entirely. >> >> Is there an easy way to read a response from the buffer instead of the >> minibuffer? If it matters, a "response" is a string of 1-8 alphabetic >> characters terminated by a newline/return key. > > Nothing built-in, but it should be pretty straightforward to write a > command that looks in the buffer to find the response, and bind the > Return key to this command. How about widgets? See (info "widget") for examples and details. Steve Berman ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Input from buffer instead of minibuffer 2012-09-30 20:46 Input from buffer instead of minibuffer Michael Haensel 2012-10-01 1:10 ` Barry Margolin @ 2012-10-04 13:21 ` Stefan Monnier 2012-10-04 13:56 ` Pascal J. Bourguignon 2 siblings, 0 replies; 5+ messages in thread From: Stefan Monnier @ 2012-10-04 13:21 UTC (permalink / raw To: help-gnu-emacs > Is there an easy way to read a response from the buffer instead of the > minibuffer? If it matters, a "response" is a string of 1-8 alphabetic > characters terminated by a newline/return key. You might want to do it in the same way as M-x doctor. Stefan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Input from buffer instead of minibuffer 2012-09-30 20:46 Input from buffer instead of minibuffer Michael Haensel 2012-10-01 1:10 ` Barry Margolin 2012-10-04 13:21 ` Stefan Monnier @ 2012-10-04 13:56 ` Pascal J. Bourguignon 2 siblings, 0 replies; 5+ messages in thread From: Pascal J. Bourguignon @ 2012-10-04 13:56 UTC (permalink / raw To: help-gnu-emacs Michael Haensel <mhaensel73@gmail.com> writes: > Hello everyone - > > I'm writing a quiz program in Emacs Lisp. The program creates a new frame and buffer for the quiz questions. The quiz then runs something like this: > > (insert "Please identify: [quiz item]") > (setq response > (read-from-minibuffer "Please identify: [quiz item]")) > ... do stuff based on response > > This displays the question in the buffer and the minibuffer. The > response is read in from the minibuffer. This isn't deal-breakingly > bad, but a better design would read the response from the buffer and > skip the minibuffer entirely. > > Is there an easy way to read a response from the buffer instead of the > minibuffer? If it matters, a "response" is a string of 1-8 alphabetic > characters terminated by a newline/return key. First, read can read lisp objects from a buffer, at the point (and advancing it). But it won't be convenient for user input. Next, there's read-char which just reads a character from the user, kind of low-level. You can use it to make a blocking input function. ---------------------------------------------------------------------------------- (require 'cl) (defun newline-char-p (ch) (= ch ?\n) (= ch ?\r)) (defun char-erase-char-p (ch) (or (= ch ?\x7f) (= ch ?\b))) (defun word-erase-char-p (ch) (= ch ?\x17)) (defun kill-line-char-p (ch) (= ch ?\x15)) (defun reprint-line-char-p (ch) (= ch ?\x12)) (defun interrupt-char-p (ch) (= ch ?\x03)) (defun whitespace-char-p (ch) (or (= ch 32) (= ch 9))) (defun* read-line () "Reads a line from the user with read-char, echoing it in the current buffer. RETURN: the line read from the user." (let ((buffer '()) (start-pt (point))) (loop (let ((ch (read-char))) (cond ((newline-char-p ch) (insert "\n") (return-from read-line (coerce (reverse buffer) 'string))) ((and (char-erase-char-p ch) buffer) (pop buffer) (delete-backward-char 1)) ((and (word-erase-char-p ch) buffer) (loop named erase-whitespaces while (and buffer (whitespace-char-p (first buffer))) do (pop buffer) (delete-backward-char 1)) (loop named erase-word while (and buffer (not (whitespace-char-p (first buffer)))) do (pop buffer) (delete-backward-char 1))) ((and (kill-line-char-p ch) buffer) (setf buffer '()) (delete-region start-pt (point))) ((reprint-line-char-p ch) (delete-region start-pt (point)) (insert (coerce (reverse buffer) 'string))) ((interrupt-char-p ch) (return-from read-line nil)) (t (push ch buffer) (insert (format "%c" ch)))))))) (progn (insert "\nEnter something: ") (read-line)) ---------------------------------------------------------------------------------- But as you can see, you take control over emacs usual event loop this way, which may be what you want or not. So the last option, is to just let the user edit the buffer as he wants, and bind a special function on a key, such as RET, that will analyze the buffer when the user press that, to infer some input. ------------------------------------------------------------------------ (defvar *input-start-point* (make-marker)) (defvar *input-callback* (lambda (string) (insert "\ngot: %S\n" string))) (defvar *input-old-newline* nil) (defun start-input () (set-marker *input-start-point* (point)) (setf *input-old-newline* (key-binding (kbd "RET")))) (defun newline-and-return-input () (interactive) (let ((end-pt (point))) (if (<= *input-start-point* end-pt) (let ((input (buffer-substring *input-start-point* end-pt))) (set-marker *input-start-point* nil) (local-set-key (kbd "RET") *input-old-newline*) (funcall *input-callback* input)) (funcall *input-old-newline*)))) (progn (insert "\nEnter something: ") (start-input) (local-set-key (kbd "RET") 'newline-and-return-input)) ------------------------------------------------------------------------ The advantage here is that emacs still runs, so you can use whatever editing command, switch to another buffer, come back, etc. You can edit anything about the prompt point, but if you type RET after it, the callback is called with the "input" text. Notice you can insert newlines with C-q RET, so the "input" text can be multiline too. The inconvenient of course is that it's asynchronous, and you need to go thru the callback to do something with the "input" text. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-04 13:56 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-30 20:46 Input from buffer instead of minibuffer Michael Haensel 2012-10-01 1:10 ` Barry Margolin 2012-10-03 15:45 ` Stephen Berman 2012-10-04 13:21 ` Stefan Monnier 2012-10-04 13:56 ` Pascal J. Bourguignon
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.