Gnus development mailing list
 help / color / mirror / Atom feed
From: "François Pinard" <pinard@iro.umontreal.ca>
Cc: "(ding)" <ding@gnus.org>
Subject: Re: Those `mailcrypt' "push OK" boxes
Date: 25 Apr 1999 21:46:02 -0400	[thread overview]
Message-ID: <oqpv4sduhx.fsf@titan.progiciels-bpi.ca> (raw)
In-Reply-To: Stainless Steel Rat's message of "25 Apr 1999 21:19:14 -0400"

Stainless Steel Rat <ratinox@peorth.gweep.net> écrit:

> | And then, you get an accepting interaction there?  Something that merely
> | flashes in the mini-buffer and disappears at the next random keystroke
> | could easily go un-noticed.

> I get an error message, just like any other error condition in Emacs, the
> way <insert deity> intended things to be.

Most error messages in Emacs do not require confirmation.  So, if I interpret
your answer, you are saying that you have no required confirmation that
you read the error message?  It might then disappear at the next random
keystroke.

> | Also, is the minibuffer guaranteed to extend for holding and displaying
> | the full diagnostic?  It is often multi-line.  Is there any required magic
> | for it?  (I use the resize-minibuffer mode, but it does not work perfectly
> | in all circumstances, at least from my experience.)

> Yeah, well, that is a flaw in FSF Emacs.  XEmacs minibuffer resizing
> appears to be much saner.

OK, well, I'm using Emacs most of the times, and XEmacs much less often.

> | I'm surely open to any solution, as long as it does work dependably! :-)
> Get used to pretty, gooey dialog boxes.

I think we are making circles, here.  I explained in a previous messages
a few reasons why I do not consider them to be good things.  I suggested
a replacement in which the mouse interaction and the special X-windows for
dialog were getting avoided.  If I remember correctly, you then did suggest
to just use the mini-buffer instead.  After further verification with you,
it seems using the mini-buffer does not really solve any of the problems.

The idea is not to push forward solutions just so they oppose each other,
this is not productive.  We should work towards ideas which improve things.
Let us mere <humans> try to do better than any <deity> out there! :-)

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard



  reply	other threads:[~1999-04-26  1:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-24  3:34 François Pinard
1999-04-24 15:36 ` Gareth Jones
1999-04-24 16:43   ` François Pinard
1999-04-25 14:08 ` Stainless Steel Rat
1999-04-25 16:27   ` François Pinard
1999-04-25 21:42     ` Stainless Steel Rat
1999-04-25 22:30       ` François Pinard
1999-04-26  1:19         ` Stainless Steel Rat
1999-04-26  1:46           ` François Pinard [this message]
1999-04-26  2:18             ` Stainless Steel Rat
1999-04-26  4:23               ` François Pinard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=oqpv4sduhx.fsf@titan.progiciels-bpi.ca \
    --to=pinard@iro.umontreal.ca \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).