Minibuffer wipeout: "Auto-saving... done"

Minibuffer wipeout: "Auto-saving... done"

[David Vanderschel]

I have a program which prepares a multi-line display
for interaction in the minibuffer.  It behaves as I
intend.  However, I have a problem in that the content
of the buffer is occasionally erased by the 'echo'
which results from auto-saving.  (My program remains
active and will react to input correctly even though
its display in the minibuffer has been wiped out.
Oddly, my enlarged height for the minibuffer remains
in effect.)  I was aware of the fact that I needed to
have echo-keystrokes set to 0 to avoid one possible
source of such preemptions of the minibuffer; but I
would like to have some advice about how to prevent
getting my minibuffer content erased by the string
"Auto-saving... done."

I tried executing do-auto-save just before invoking my
function.  All that did was to _assure_ that my
minibuffer content was wiped out - even when I put a
(sit-for 5) after the do-auto-save and before my
program selected the minibuffer window and wrote in
it.  (I find this symptom incomprehensible; so, if
someone could enlighten me, I would appreciate it.)  I
also tried a let binding on auto-save-interval to set
it to something large while my minibuffer window was
active.  No joy.  FWIW, the buffer current when the
function can be invoked is not itself even subject to
auto-saving - it doesn't even have an associated file.

A good solution would be a method for temporarily
suppressing all auto-saves while my interaction is in
progress, which should never be for more than a few
tens of seconds.

If it is not possible to avoid the wipeout, is there a
way to learn that it has happened so that I can repair
it?  I cannot periodically check the content of the
buffer because I am stuck waiting on input.  I was
using read-event, but that was giving me problems with
quit until I switched to read-key-sequence.  (I
mention the latter because there may be a way by which
read-event can learn about the auto-save (but I doubt
it).)  If there were an after-hook for auto-save, that
might help; but I find only a before-hook for
auto-save.

Any help appreciated,
  David V.

New symptom and code

[David Vanderschel]

I should have mentioned that I am using the minibuffer
primarily so that I can get a temporary multi-line
display.  Otherwise, I could have used message.  I am
not letting the user edit in the minibuffer.  I am
just showing him some data.  The single character he
types is treated by my program as a command, which
then modifies the display.

I just encountered another very weird symptom.  I had
two frames open.  I invoked the function as usual in a
frame with a single window - the only window in which
the function was bound to a key.  Its minibuffer grew
in the manner I had intended.  However, the string
which was supposed to go in the minibuffer wound up in
the minibuffer of the other frame.  This makes no
sense.  There is no concept of multiple minibuffers in
the my code.

Maybe I should just show my current iteration of the
code:

(defun Hube-config-dialogue (msg valid-chars)
"Show (possibly multi-line) MSG in minibuffer; read and return an input char.
Return 0 if input character is not among those in list VALID-CHARS."
  (interactive)
  (save-selected-window
    (select-window (minibuffer-window)) (erase-buffer) (insert msg)
    (let ((auto-save-interval 600) (echo-keystrokes 0) (enlargement 0))
      (while (not (pos-visible-in-window-p)) (enlarge-window 1) (incf
enlargement))
      (let* ((s (read-key-sequence nil)) (c (elt s 0)))
        (erase-buffer) (shrink-window enlargement) (if (member c valid-chars) c
0)))))

What do I need to understand to get this right?

Regards,
  David V.

Re: New symptom and code

[Kevin Rodgers]

David Vanderschel wrote:
 > I should have mentioned that I am using the minibuffer primarily so
 > that I can get a temporary multi-line display.  Otherwise, I could
 > have used message.  I am not letting the user edit in the minibuffer.
 > I am just showing him some data.  The single character he types is
 > treated by my program as a command, which then modifies the display.

I don't understand.  What's wrong with

(message "First line\nSecond line\nThird line")

-- 
Kevin Rodgers

Re: New symptom and code

[David Vanderschel]

"Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
news:40EAEC5D.8040603@yahoo.com...
> David Vanderschel wrote:
>  > I should have mentioned that I am using the minibuffer primarily so
>  > that I can get a temporary multi-line display.  Otherwise, I could
>  > have used message.  I am not letting the user edit in the minibuffer.
>  > I am just showing him some data.  The single character he types is
>  > treated by my program as a command, which then modifies the display.

> I don't understand.  What's wrong with

> (message "First line\nSecond line\nThird line")

Well, when I try that, what I see in the echo area is

  "First line^JSecond line^JThird line"

which is not acceptable.  Interestingly, what appears
in emacs' *Messages* buffer does have real newlines.

Is there some setting which affects whether or not
newline characters cause the echo area to grow?
message was actually my first choice, but I have not
been able to see how to make the echo area grow.

Regards,
  David V.

Re: New symptom and code

[David Kastrup]

"David Vanderschel" <DJV4@Austin.RR.com> writes:

> "Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
> news:40EAEC5D.8040603@yahoo.com...
> > David Vanderschel wrote:
> >  > I should have mentioned that I am using the minibuffer primarily so
> >  > that I can get a temporary multi-line display.  Otherwise, I could
> >  > have used message.  I am not letting the user edit in the minibuffer.
> >  > I am just showing him some data.  The single character he types is
> >  > treated by my program as a command, which then modifies the display.
> 
> > I don't understand.  What's wrong with
> 
> > (message "First line\nSecond line\nThird line")
> 
> Well, when I try that, what I see in the echo area is
> 
>   "First line^JSecond line^JThird line"
> 
> which is not acceptable.

You are confusing the output of the message command with its return
value.  Obviously, if you use M-x eval-expression RET, then the last
thing that gets displayed is the evaled expression.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New symptom and code

[Kevin Rodgers]

David Vanderschel wrote:
 > "Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
 > news:40EAEC5D.8040603@yahoo.com...
 >>I don't understand.  What's wrong with
 >>
 >>(message "First line\nSecond line\nThird line")
 >
 > Well, when I try that, what I see in the echo area is
 >
 >   "First line^JSecond line^JThird line"
 >
 > which is not acceptable.  Interestingly, what appears in emacs'
 > *Messages* buffer does have real newlines.

That's what happens for me in Emacs 19.34.  But in Emacs 21.3 it behaves
as desired.

-- 
Kevin Rodgers

Re: New symptom and code

[David Vanderschel]

"David Kastrup" <dak@gnu.org> wrote in message
news:x5oemsfw3n.fsf@lola.goethe.zz...
> "David Vanderschel" <DJV4@Austin.RR.com> writes:

> > Well, when I try that, what I see in the echo area is

> >   "First line^JSecond line^JThird line"

> > which is not acceptable.

> You are confusing the output of the message command with its return
> value.  Obviously, if you use M-x eval-expression RET, then the last
> thing that gets displayed is the evaled expression.

Nonsense.  I was not doing it with M-x eval-expression
in the first place.  I was writing the function call
in a buffer and executing it with eval-last-sexp.
What I see in the echo area is all that I care about,
and it is not coming out as I wish - no matter how
I manage to invoke message.


"Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
news:40EC1F05.6060008@yahoo.com...
> That's what happens for me in Emacs 19.34.  But in Emacs 21.3 it behaves
> as desired.

Ahhh!  So my 20.7.3 is probably obsolete in this
manner also.  However, I do not want to force users of
my program to upgrade their emacs, so this revelation
about improvement in 21.3 does not really help either.



Since what I am doing is logically a pop-up, I decided
the easiest solution would be to just create a new,
temporary frame for it.  Then I have complete control,
and I do not get surprised by the subtleties of
minibuffers or the echo area.

Though I have given up on both the echo area and the
minibuffer approaches, I would still like to
understand my strange symptoms with the minibuffer if
only on principle.  I was really hoping that someone
could point me to some clarifying documentation which
had escaped my attention.

Regards,
  David V.

New symptom and code

[David Vanderschel]

I should have mentioned that I am using the minibuffer
primarily so that I can get a temporary multi-line
display.  Otherwise, I could have used message.  I am
not letting the user edit in the minibuffer.  I am
just showing him some data.  The single character he
types is treated by my program as a command, which
then modifies the display.

I just encountered another very weird symptom.  I had
two frames open.  I invoked the function as usual in a
frame with a single window - the only window in which
the function was bound to a key.  Its minibuffer grew
in the manner I had intended.  However, the string
which was supposed to go in the minibuffer wound up in
the minibuffer of the other frame.  This makes no
sense.  There is no concept of multiple minibuffers in
the my code.

Maybe I should just show my current iteration of the
code:

(defun Hube-config-dialogue (msg valid-chars)
"Show (possibly multi-line) MSG in minibuffer; read and return an input char.
Return 0 if input character is not among those in list VALID-CHARS."
  (interactive)
  (save-selected-window
    (select-window (minibuffer-window)) (erase-buffer) (insert msg)
    (let ((auto-save-interval 600) (echo-keystrokes 0) (enlargement 0))
      (while (not (pos-visible-in-window-p)) (enlarge-window 1) (incf
enlargement))
      (let* ((s (read-key-sequence nil)) (c (elt s 0)))
        (erase-buffer) (shrink-window enlargement) (if (member c valid-chars) c
0)))))

What do I need to understand to get this right?

Regards,
  David V.

Re: New symptom and code

[Kai Grossjohann]

"David Vanderschel" <DJV4@Austin.RR.com> writes:

> I should have mentioned that I am using the minibuffer
> primarily so that I can get a temporary multi-line
> display.  Otherwise, I could have used message.  I am
> not letting the user edit in the minibuffer.  I am
> just showing him some data.  The single character he
> types is treated by my program as a command, which
> then modifies the display.

You could show the stuff in a window.  Completion does it that way,
and it seems to work well.

Kai

Re: Minibuffer wipeout: "Auto-saving... done"

[Kevin Rodgers]

David Vanderschel wrote:
 > I have a program which prepares a multi-line display for interaction
 > in the minibuffer.  It behaves as I intend.  However, I have a problem
 > in that the content of the buffer is occasionally erased by the 'echo'
 > which results from auto-saving.  (My program remains active and will
 > react to input correctly even though its display in the minibuffer has
 > been wiped out.  Oddly, my enlarged height for the minibuffer remains
 > in effect.)  I was aware of the fact that I needed to have
 > echo-keystrokes set to 0 to avoid one possible source of such
 > preemptions of the minibuffer; but I would like to have some advice
 > about how to prevent getting my minibuffer content erased by the
 > string "Auto-saving... done."
 >
 > I tried executing do-auto-save just before invoking my function.  All
 > that did was to _assure_ that my minibuffer content was wiped out -
 > even when I put a (sit-for 5) after the do-auto-save and before my
 > program selected the minibuffer window and wrote in it.  (I find this
 > symptom incomprehensible; so, if someone could enlighten me, I would
 > appreciate it.)

Did you specify a non-nil NO-MESSAGE argument to do-auto-save?

 > I also tried a let binding on auto-save-interval to
 > set it to something large while my minibuffer window was active.  No
 > joy.  FWIW, the buffer current when the function can be invoked is not
 > itself even subject to auto-saving - it doesn't even have an
 > associated file.

Hmmm, I think binding auto-save-interval would have worked.  You might
also try binding auto-save-timeout to a large value.

 > A good solution would be a method for temporarily suppressing all
 > auto-saves while my interaction is in progress, which should never be
 > for more than a few tens of seconds.

-- 
Kevin Rodgers

Re: Minibuffer wipeout: "Auto-saving... done"

[David Vanderschel]

"Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
news:40EAEBBD.1050202@yahoo.com...
> Did you specify a non-nil NO-MESSAGE argument to
> do-auto-save?

No.  That may have helped; but my intent had been to
get the message out of the way _before_ my program got
hold of the minibuffer, so I was not really worried
about it.

I just tried to do an experiment with NO-MESSAGE, but
now I can no longer produce the symptom at all.  I am
wondering if my emacs had got itself into a wrong
state when I was having the troubles (like the one
where my string got stuck in the wrong minibuffer
while my program was correctly enlarging the intended
minibuffer associated with the frame in
which I invoked my command).

I find emacs to be so reliable that, when something goes
wrong, I tend to assume that it is my fault.  That may not
have been the case this time.

David V.