patch: handle killing the last buffer a little better

[Jesse Luehrs]

>From ab6618459e75aa8c940c0cedeb5c1ba5a43b028a Mon Sep 17 00:00:00 2001
From: Jesse Luehrs <doy@...>
Date: Fri, 25 Sep 2009 02:26:45 -0500
Subject: [PATCH] handle killing the last buffer a little better

replace it with an empty buffer if we aren't allowed to kill it
---
 modules/buffer.js |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/modules/buffer.js b/modules/buffer.js
index 633670a..efa9c08 100644
--- a/modules/buffer.js
+++ b/modules/buffer.js
@@ -605,8 +605,9 @@ function kill_buffer (buffer, force) {
             delete_window(buffer.window);
             return;
         }
-        else
-            throw interactive_error("Can't kill last buffer.");
+        else {
+            create_buffer(buffer.window, buffer_creator(content_buffer), OPEN_NEW_BUFFER_BACKGROUND);
+        }
     }
     buffers.kill_buffer(buffer);
 }
--
1.6.4.4

_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror

[Jeremy Maitin-Shepard-2]

Jesse Luehrs <doy@...> writes:

>> From ab6618459e75aa8c940c0cedeb5c1ba5a43b028a Mon Sep 17 00:00:00 2001
> From: Jesse Luehrs <doy@...>
> Date: Fri, 25 Sep 2009 02:26:45 -0500
> Subject: [PATCH] handle killing the last buffer a little better

> replace it with an empty buffer if we aren't allowed to kill it

This doesn't seem that useful since the only thing you would do with the
new buffer is use it to browse to a different URL, which you could have
done with the existing buffer anyway.

If this is really desirable behavior, though, you could create a user
variable that enables this behavior when set, but leaves the existing
behavior when unset, as I would want the existing behavior to still be
available.

> ---
>  modules/buffer.js |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)

> diff --git a/modules/buffer.js b/modules/buffer.js
> index 633670a..efa9c08 100644
> --- a/modules/buffer.js
> +++ b/modules/buffer.js
> @@ -605,8 +605,9 @@ function kill_buffer (buffer, force) {
>              delete_window(buffer.window);
>              return;
>          }
> -        else
> -            throw interactive_error("Can't kill last buffer.");
> +        else {
> + create_buffer(buffer.window, buffer_creator(content_buffer),
> OPEN_NEW_BUFFER_BACKGROUND);
> +        }
>      }
>      buffers.kill_buffer(buffer);
>  }
> --
> 1.6.4.4

--
Jeremy Maitin-Shepard
_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror

[Deniz Dogan-3]

2009/9/25 Jeremy Maitin-Shepard <jeremy@...>:

> Jesse Luehrs <doy@...> writes:
>
>>> From ab6618459e75aa8c940c0cedeb5c1ba5a43b028a Mon Sep 17 00:00:00 2001
>> From: Jesse Luehrs <doy@...>
>> Date: Fri, 25 Sep 2009 02:26:45 -0500
>> Subject: [PATCH] handle killing the last buffer a little better
>
>> replace it with an empty buffer if we aren't allowed to kill it
>
> This doesn't seem that useful since the only thing you would do with the
> new buffer is use it to browse to a different URL, which you could have
> done with the existing buffer anyway.

Not entirely true though, since the state of the killed buffer would
be wiped (for whatever reason one might have to do so).

--
Deniz Dogan
_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror

[Silvio Levy-3]

> This doesn't seem that useful

It's useful if you're surfing the web at work and need to kill a
buffer quickly...

Silvio


_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror

[Jesse Luehrs]

On Fri, Sep 25, 2009 at 06:48:19AM -0700, Jeremy Maitin-Shepard wrote:

> Jesse Luehrs <doy@...> writes:
>
> >> From ab6618459e75aa8c940c0cedeb5c1ba5a43b028a Mon Sep 17 00:00:00 2001
> > From: Jesse Luehrs <doy@...>
> > Date: Fri, 25 Sep 2009 02:26:45 -0500
> > Subject: [PATCH] handle killing the last buffer a little better
>
> > replace it with an empty buffer if we aren't allowed to kill it
>
> This doesn't seem that useful since the only thing you would do with the
> new buffer is use it to browse to a different URL, which you could have
> done with the existing buffer anyway.

It's more for consistency - if I tell it to kill a buffer, then I want
that buffer to be killed, and whether or not the window closes from
killing the last buffer is orthogonal to that. This is also how
vimperator handles the situation.

> If this is really desirable behavior, though, you could create a user
> variable that enables this behavior when set, but leaves the existing
> behavior when unset, as I would want the existing behavior to still be
> available.

I can make it an option, if you think that would be better.

-doy
_______________________________________________
Conkeror mailing list
Conkeror@...
https://www.mozdev.org/mailman/listinfo/conkeror