GNU bug report logs - #66285
suggestion: change definition of hycontrol--blank-buffer to something more meaningful

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66285 in the body.
You can then email your comments to 66285 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dan Drake <dan.drake <at> gmail.com>
To: bug-hyperbole <at> gnu.org
Subject: suggestion: change definition of hycontrol--blank-buffer to something
 more meaningful
Date: Sat, 30 Sep 2023 14:48:52 -0500

[Message part 1 (text/plain, inline)]

Hello,

A while back I posted this emacs.stackexchange question, about a mysterious
buffer named BLANK which always appeared when I started emacs:
https://emacs.stackexchange.com/q/78601/19526

Today I figured out the source: see my answer to that question.

It's still not clear how this BLANK buffer was getting created on startup,
since I have no idea how hycontrol-window-display-buffer was getting
called, but I'd like to suggest that the name of that blank buffer be
changed to something that makes its source and purpose more obvious. Perhaps

(defvar hycontrol--blank-buffer (get-buffer-create "
*hycontrol--blank-buffer*")

? Any user who does hycontrol-windows-grid and triggers that will see the
extra buffers with that name, and if such buffers just show up in the
buffer list, it'll be obvious that they can safely be killed.

I don't have any strong feelings about the name, just something more
helpful and meaningful -- and searchable! -- than "BLANK".

Regards,

Dan

-- 
Ceci n'est pas une .signature.

[Message part 2 (text/html, inline)]

Message #8 received at 66285 <at> debbugs.gnu.org (full text, mbox):

From: Dan Drake <dan.drake <at> gmail.com>
To: 66285 <at> debbugs.gnu.org
Subject: Re: bug#66285: suggestion: change definition of
 hycontrol--blank-buffer to something more meaningful
Date: Sun, 1 Oct 2023 06:55:05 -0500

[Message part 1 (text/plain, inline)]

Here's an alternative suggestion: juse use the scratch buffer.

Many users, I think, always have a scratch buffer open. If
hycontrol-window-display-buffer runs out of buffers to display, instead of
creating new, empty, useless buffers, it seems reasonable to default to
displaying the scratch buffer. And if there's no such buffer, then fall
back to the blank one.

So, in addition to a more useful name, I propose the following snippet for
hycontrol-window-display-buffer:

    (set-window-buffer window
      (or buf
  ;; Out of buffers to display, display scratch buffer if it exists...
                           (get-buffer "*scratch*")
                           ;; ...otherwise, a blank buffer:
  hycontrol--blank-buffer))))

It just adds the single condition to the "or" to get the scratch buffer,
and gracefully falls back to existing behavior if there's no scratch buffer.

On Sat, Sep 30, 2023 at 5:35 PM Dan Drake <dan.drake <at> gmail.com> wrote:

> Hello,
>
> A while back I posted this emacs.stackexchange question, about a
> mysterious buffer named BLANK which always appeared when I started emacs:
> https://emacs.stackexchange.com/q/78601/19526
>
> Today I figured out the source: see my answer to that question.
>
> It's still not clear how this BLANK buffer was getting created on startup,
> since I have no idea how hycontrol-window-display-buffer was getting
> called, but I'd like to suggest that the name of that blank buffer be
> changed to something that makes its source and purpose more obvious. Perhaps
>
> (defvar hycontrol--blank-buffer (get-buffer-create "
> *hycontrol--blank-buffer*")
>
> ? Any user who does hycontrol-windows-grid and triggers that will see the
> extra buffers with that name, and if such buffers just show up in the
> buffer list, it'll be obvious that they can safely be killed.
>
> I don't have any strong feelings about the name, just something more
> helpful and meaningful -- and searchable! -- than "BLANK".
>
> Regards,
>
> Dan
>
> --
> Ceci n'est pas une .signature.
> _______________________________________________
> Bug-hyperbole mailing list
> Bug-hyperbole <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-hyperbole
>


-- 
Ceci n'est pas une .signature.

[Message part 2 (text/html, inline)]

Message #11 received at 66285 <at> debbugs.gnu.org (full text, mbox):

From: Mats Lidell <matsl <at> gnu.org>
To: Dan Drake <dan.drake <at> gmail.com>
Cc: 66285 <at> debbugs.gnu.org
Subject: Re: bug#66285: suggestion: change definition of
 hycontrol--blank-buffer to something more meaningful
Date: Thu, 21 Mar 2024 23:55:15 +0100

> Dan Drake writes:
> Hello,
>
> A while back I posted this emacs.stackexchange question, about a mysterious buffer named BLANK which always appeared when I started emacs:
> https://emacs.stackexchange.com/q/78601/19526
>
> Today I figured out the source: see my answer to that question.
>
> It's still not clear how this BLANK buffer was getting created on startup, since I have no idea how hycontrol-window-display-buffer was getting called,
> but I'd like to suggest that the name of that blank buffer be changed to something that makes its source and purpose more obvious. Perhaps
>
> (defvar hycontrol--blank-buffer (get-buffer-create " *hycontrol--blank-buffer*")
>
> ? Any user who does hycontrol-windows-grid and triggers that will see the extra buffers with that name, and if such buffers just show up in the buffer
> list, it'll be obvious that they can safely be killed.
>
> I don't have any strong feelings about the name, just something more helpful and meaningful -- and searchable! -- than "BLANK".
>
> Regards,
>
> Dan
>
> -- 
> Ceci n'est pas une .signature.

Thanks for the suggestion. The variable `hycontrol-blank-buffer-name' has been
introduced with commit 31d4095. Is is customizable and defaults to " BLANK". It
will be part of the next release of Hyperbole and is available from elpa-devel
archive.

Yours
-- 
%% Mats

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.