On Mon, Jun 12, 2006 at 08:14:01PM -0400, Tom Lane wrote:
> I had interpreted the readline documentation to mean that readline would
> discard a partially typed line upon catching SIGINT. Experimentation
> shows that this is not so, at least not with the version of readline I
> use here. It does
Martijn van Oosterhout writes:
> But the effect would change still, even with readline enabled. If
> readline is compiled in and you press control-C, our handler is still
> called. Currently, we siglongjmp out of readline() and start again. If
> you only set a flag like proposed, we won't break ou
On Sun, Jun 11, 2006 at 03:23:50PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > If you're asking me, yes. I use it a lot and would miss it if it were
> > gone. Is there another shortcut for "abort current command and don't
> > store in history but don't clear it from the screen"?
>
Martijn van Oosterhout writes:
> If you're asking me, yes. I use it a lot and would miss it if it were
> gone. Is there another shortcut for "abort current command and don't
> store in history but don't clear it from the screen"?
Why are you expecting editing niceties (or history for that matter)
Martijn van Oosterhout wrote:
> On Sun, Jun 11, 2006 at 02:57:38PM -0400, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > As it states in the comment, you can't remove the longjump because
> > > it's the only way to break out of the read() call when using BSD signal
> > > semantics (unles
On Sun, Jun 11, 2006 at 02:57:38PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > As it states in the comment, you can't remove the longjump because
> > it's the only way to break out of the read() call when using BSD signal
> > semantics (unless you're proposing non-blocking read+sel
Martijn van Oosterhout writes:
> As it states in the comment, you can't remove the longjump because
> it's the only way to break out of the read() call when using BSD signal
> semantics (unless you're proposing non-blocking read+select()). So the
> patch sets up the sigjump just before the read()
On Sun, Jun 11, 2006 at 02:08:12PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
> >> I think we should try very hard to get rid of the longjmp in the signal
> >> handler altogether.
>
> > I submitted a patch for this ages ag
Martijn van Oosterhout writes:
> On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
>> I think we should try very hard to get rid of the longjmp in the signal
>> handler altogether.
> I submitted a patch for this ages ago and AFAIK it's still in the
> queue. Have you any issues with the wa
On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
> I think we should try very hard to get rid of the longjmp in the signal
> handler altogether. I notice it doesn't work anyway in the Windows
> port, so this would improve portability as well as safety. The signal
> handler should just se
10 matches
Mail list logo
