🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.bug
Article #100057

Not a bug report, but a proposal

#100057
From: Shinichirou Sugou
Date: Thu, 15 Feb 1990 05:07
104 lines
4646 bytes
Dear sirs:

I'm writing a medical application using EmacsLisp now, and has one problem.

Every function which reads user's input from minibuffer, such as
read-from-minibuffer, read-string, etc., moves the cursor to the end of
the minibuffer.

For example,

    (read-from-minibuffer "Your input: " "foo")

will move the cursor after "foo".

What I want to do is to move the cursor to the desired position (for example,
the beginning of the minibuffer, that is, the place just above "f").

Yes, there is a one solution.  That is, writing my own input routine using the
combination of (recursive-edit) and (select-window (minibuffer-window)), or
the combination of (read-char) and (select-window (minibuffer-window)) though
the latter is somewhat primitive.

The following function is the actually used one, which moves the cursor to the
beginning of the minibuffer.

(defun wine-read-from-minibuffer (prompt initial keymap)
  "Get input in the minibuffer, return it as string, or nil if user interrupt.
PROMPT and INITIAL are string.  The cursor positions at the beginning of INITIAL.
PROMPT is saved in variable wine-minibuf-prompt for reference by other function.
Hint about KEYMAP.  This function calls recursive-edit within the body.
Use exit-recursive-edit to finish this function normally.
Set the variable wine-minibuf-interrupt t before exit-recursive-edit for interruption."
  (wine-assert (and (stringp prompt)
                    (stringp initial)
                    (keymapp keymap))
               "invalid argument")
  (let* ((echo-keystrokes 0)            ; suppress echo keystroke
         (miniwin (minibuffer-window))
         (minibuf (window-buffer miniwin))
         (cur-win (selected-window))
         (wine-minibuf-prompt prompt)
         (wine-minibuf-interrupt nil)
         old-cnt old-pnt old-map)
    (select-window miniwin)
    ;; save minibuffer content etc
    (setq old-cnt (buffer-string)
          old-pnt (point)
          old-map (current-local-map))
    ;; init minibuffer
    (unwind-protect
        (progn
          (erase-buffer)
          (insert (concat prompt initial))
          (goto-char (1+ (length prompt)))
          (use-local-map keymap)
          (recursive-edit)
          (if wine-minibuf-interrupt
              nil
            (wine-minibuffer-content)))
      ;; revert minibuffer
      (erase-buffer)
      (insert old-cnt)
      (goto-char old-pnt)
      (use-local-map old-map)
      (select-window cur-win))))


But, there are two problems in the function above.

(1) The recursive sign, '[]', appears in the mode line.  It is not smart.  You
    may think that modifying mode-line-format makes the recursive sign
    disappear.  But it is incorrect.  Modifying mode-line-format erases the
    EVERY recursive sign(s), and that is undesirable.  What I want is to
    erase the one level recursive sign.

(2) This problem is more serious.  During using the function above, if some
    message, such as "Auto saving..." or "Garbage collecting...", appears in
    the echo area, the content of the echo area (minibuffer area) doesn't
    revert to the previous one automatically.  I must type some key to force
    to revert it. 

I think it is not so difficult to implement the feature of moving the cursor
to minibuffer-input functions.

Also, adding the new argument POSITION to the last as optional argument like this,

  (defun read-from-minibuffer (PROMPT-STRING &optional INITIAL KEYMAP READ POSITION)
  "If POSITION is nil, the cursor moves to the end of buffer"

will not break the compatibility.

Is it possible in version 19?

Thank you.

CAUTION: (1) Reply-command in the mail system may NOT generate my address
             correctly.  Please use the following address instead.

               shin%sgtp.apple.juice.or.jp@uunet.uu.net

         (2) I have no relation to Apple Computer Inc. :-)

---
S.Sugou
Technical Details
Message-ID: <9002150507.AA26323@sgtp.apple.juice.or.jp>
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!bu.edu!spdcc!snorkelwacker!think!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!sgtp.apple.juice.or.jp!shin

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fb2f1,3113a70001fe6f09,start
X-Google-Attributes: gidfb2f1,public
X-Google-ArrivalTime: 1990-02-14 21:07:34 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!bu.edu!spdcc!snorkelwacker!think!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!sgtp.apple.juice.or.jp!shin
From: shin@sgtp.apple.juice.or.jp (Shinichirou Sugou)
Newsgroups: gnu.emacs.bug
Subject: Not a bug report, but a proposal
Message-ID: <9002150507.AA26323@sgtp.apple.juice.or.jp>
Date: 15 Feb 90 05:07:34 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 104
Posted: Thu Feb 15 06:07:34 1990