On Thu, 2003-01-09 at 10:42, Peter Mount wrote:
> On 9 Jan 2003, Rod Taylor wrote:
>
> > On Thu, 2003-01-09 at 10:12, 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".
> >
> > We could always create a new command that edits a query buffer rather
> > than file
> >
> > \e FILENAME
> >
> > \E QUERY BUFFER
> >
> >
> > So, history of:
> > \E SELECT .......
> >
> > Selecting this would fire off an editor based on the query to the right
> > of the command, much as \e FILENAME opens an editor based on the file to
> > the right of the command.
>
> That's a possible one, but the only problem I can see is if the user uses
> \e on it's own (ie not read in a file).
>
> Do we then place just \e or \E QUERY BUFFER into the history?
I'd tend to switch it to store \E QUERY BUFFER in the history, and
possibly remove the ability to use \e by itself -- or make \E FILENAME
and \e QUERY BUFFER.
Since the use of \e isn't likely to be used in a programmatic
(automated) way, but only by users who could quickly figure it out.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc