nate@mipos3.intel.com (Nate Hess) (06/14/88)
In article <31024@yale-celray.yale.UUCP> Ram-Ashwin@cs.yale.edu (Ashwin Ram) writes: >I tried to bind a key to the following function: > > (defun insert-minibuffer-contents () > (interactive) > (insert-buffer (window-buffer (minibuffer-window)))) > >in the hope that hitting the key would cause the current contents of the >minibuffer to be inserted in the current buffer. No luck. I get nothing if I >hit the key. If I execute (insert-minibuffer-contents) in, say, the *scratch* >buffer, I get "Mark set". Any suggestions? EL code to get the current >minibuffer contents as a string, or any other way of getting hold of the >minibuffer message, would be fine too. I got the same results executing the above code from the scratch buffer, so I wrote the following: (defun foobar () (interactive) (set-buffer (window-buffer (minibuffer-window))) (buffer-string)) which, when defun'ed and run from inside the scratch buffer, seems to work pretty much like you wanted it to. Note, however, that there is no way, to my knowledge, to grab the message in the minibuffer area, ie., Quit, Auto-saving...done, etc. What the foobar function above *does* allow you to grab is the contents of the minibuffer if it's already active. For example, if you've typed 'M-x foo' when you execute foobar, you'll get "foo". If you've typed 'C-x C-f', you'll get "<default directory>/". The "M-x " and the "Find File: " will *not* be included as part of the minibuffer contents. This seems to follow, though, from the fact that if you do 'M-x foo' and then a 'C-a', you'll go to just before the "foo", and not all the way back to before the "M-x". So, the messages don't really seem to be part of the minibuffer. Hope this helps, --woodstock -- "How did you get your mind to tilt like your hat?" ...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!nate <domainish> : nate@mipos3.intel.com ATT : (408) 765-4309
jr@bbn.com (John Robinson) (06/14/88)
In article <2379@mipos3.intel.com>, nate@mipos3 (Nate Hess) writes: >Note, however, that there is no way, to my knowledge, to grab the >message in the minibuffer area, ie., Quit, Auto-saving...done, etc. >What the foobar function above *does* allow you to grab is the contents >of the minibuffer if it's already active. For example, if you've typed >'M-x foo' when you execute foobar, you'll get "foo". If you've typed >'C-x C-f', you'll get "<default directory>/". The "M-x " and the >"Find File: " will *not* be included as part of the minibuffer contents. >This seems to follow, though, from the fact that if you do 'M-x foo' and >then a 'C-a', you'll go to just before the "foo", and not all the way >back to before the "M-x". So, the messages don't really seem to be part >of the minibuffer. The minibuffer prompt and message strings (error output) are tucked away in C variables that aren't accesible to E-Lisp. They could be with source changes. But I don't see why this is eneded. -- /jr jr@bbn.com or bbn!jr
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (06/15/88)
In article <25724@bbn.COM>, jr@bbn (John Robinson) writes: > The minibuffer prompt and message strings (error output) are tucked > away in C variables that aren't accesible to E-Lisp. They could be > with source changes. But I don't see why this is eneded. In order to be able to save a minibuffer message (e.g., a help message or an error message) in some way. It would be nice if you could hit a key and have the message be inserted in the current buffer, or assigned to a variable, or whatever. E.g., you do something, you get an error message in the minibuffer, you want to look at the error message AND edit the offending source at the same time. The error message vanishes as soon as you try to the latter. It seems like this should be pretty easy to implement and would provide useful functionality. Hence the suggestion. -- Ashwin.
wjc@ho5cad (Bill Carpenter) (06/15/88)
In article <25724@bbn.COM>, jr@bbn (John Robinson) writes: >The minibuffer prompt and message strings (error output) are tucked >away in C variables that aren't accesible to E-Lisp. They could be >with source changes. But I don't see why this is eneded. One reason it is needed is that sooner or later, no matter how wide your screen happens to be, you'll get an important message that's too wide to read. By the time you can get yourself to the minibuffer to make it multi-line, the message has been squashed (normally a convenience). If you could get the message into a normal buffer, you could do whatever you wanted with it, including read it.> (BTW, if somebody happens to know how to solve this particular problem without resorting to "snatch-the-minibuffer", I'd sure like to hear about it. Once looked for it in the manual, but without success.) -- Bill Carpenter att!ho5cad!wjc or attmail!bill
rbj@ICST-CMR.ARPA (Root Boy Jim) (06/16/88)
? From: John Robinson <jr@bbn.com> ? The minibuffer prompt and message strings (error output) are tucked ? away in C variables that aren't accesible to E-Lisp. They could be ? with source changes. But I don't see why this is eneded. I don't really care about the minibuffer prompt, but I would like to be able to see the last so-many messages if they fly by too fast. Perhaps we need a message ring. ? /jr ? jr@bbn.com or bbn!jr (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
karl@haddock.ISC.COM (Karl Heuer) (06/18/88)
In article <31464@yale-celray.yale.UUCP> Ram-Ashwin@cs.yale.edu (Ashwin Ram) writes: >In article <25724@bbn.COM>, jr@bbn (John Robinson) writes: >>[The minibuffer output is not visible to E-Lisp. Why is this needed?] > >In order to be able to save a minibuffer message (e.g., a help message or an >error message) in some way. [E.g.] you want to look at the error message AND >edit the offending source at the same time. Also because the error message is sometimes too long for the minibuffer, and it gets truncated. "Wrong number of arguments: (lambda blah blah blah", and I can't see how many arguments were actually passed. For this, there should be either (a) some way to retrieve the most recent minibuffer output, or (b) an option for the minibuffer to automatically grow if a message doesn't fit. (Perhaps minibuffer-max-lines, with a value of 1 being the current behavior?) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint