On Thu, 09 Jan 2003 10:13:14 EST, the world broke into rejoicing as
Bruce Momjian <pgman@candle.pha.pa.us> said:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> > <snip>
> > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > and I exit the editor and return to psql. Suppose I decide I want to
> > > reedit, so I up arrow. I would expect to get \e, not the query I just
> > > edited, no?
> >
> > Wouldn't it depend on how this gets implemented?
> >
> > Maybe least negative impact approach (suggested already): If the "large
> > command that was edited" is put in the command history before the \e,
> > then both are available and there is no big change from "expected
> > behaviour".
> >
> > i.e. one up arrow get the previous \e, and a second up arrow would bring
> > up the command that was worked upon.
>
> Makese sense. However, it still has the shock factor of displaying a
> huge query, which is usually what is involved when using the editor. I
> don't feel strongly either way --- I am just pointing out the issue.
There's a surprise available in both directions.
If the previous command was "use external editor on query," then it
seems unreasonable to forcibly expand that out. If I edited the
query, it's more than likely that I'd like to edit it again.
But I'd like to have a way to expand the query so that I /can/ see it
in full form. It would be unfortunate for the /only/ way to get at
the query would be to \e it.
Perhaps the answer is to have some form of "\expand" directive that
replaces itself with the query's contents, or, better still, which
doesn't actually /execute/ the query, but rather pulls in the query
from outside and pushes it into the command line. The /next/ time you
hit enter, the query will get executed.
--
output = reverse("moc.enworbbc@" "enworbbc")
http://cbbrowne.com/info/linux.html
Eagles may soar, free and proud, but weasels never get sucked into jet
engines.
