Re: I wish list-buffers used my current window when it listed my buffers

Re: I wish list-buffers used my current window when it listed my buffers

[Rustom Mody]

On Thursday, August 15, 2013 7:32:50 AM UTC+5:30, Jay Cotton wrote:
> I've always wished list-buffers used my current window when it listed my 
> buffers. I don't know why, but this rubbed me the wrong way immediately when 
> I learned the command, and I've never been able to shake it.

Does this work?

(add-to-list 'same-window-buffer-names "*Buffer List*")

Re: I wish list-buffers used my current window when it listed my buffers

[Eric Abrahamsen]

Rustom Mody <rustompmody@gmail.com> writes:

> On Thursday, August 15, 2013 7:32:50 AM UTC+5:30, Jay Cotton wrote:
>> I've always wished list-buffers used my current window when it listed my 
>> buffers. I don't know why, but this rubbed me the wrong way immediately when 
>> I learned the command, and I've never been able to shake it.
>
> Does this work?
>
> (add-to-list 'same-window-buffer-names "*Buffer List*")

Hey I was just thinking something similar about the *Help* buffer: I
often look up docs for functions and variables, and then end up TAB-bing
to the source file link and hitting return to see the definition.

I like that the *Help* buffer itself opens a new window, but once I've
got that new window I want the source file in question to re-use it,
rather than going back and clobbering the window I was in.

That's not quite the same thing as the OP's question, but it seems like
a close cousin. I eventually found `display-buffer-alist' (I'm on 24.3),
but the docstring for that is as confusing as any emacs docs I've ever
read. Has anyone accomplished what I'm after?

Thanks!
Eric

Re: I wish list-buffers used my current window when it listed my buffers

[Thorsten Jolitz]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Rustom Mody <rustompmody@gmail.com> writes:
>
>> On Thursday, August 15, 2013 7:32:50 AM UTC+5:30, Jay Cotton wrote:
>>> I've always wished list-buffers used my current window when it listed my 
>>> buffers. I don't know why, but this rubbed me the wrong way immediately when 
>>> I learned the command, and I've never been able to shake it.
>>
>> Does this work?
>>
>> (add-to-list 'same-window-buffer-names "*Buffer List*")
>
> Hey I was just thinking something similar about the *Help* buffer: I
> often look up docs for functions and variables, and then end up
> TAB-bing to the source file link and hitting return to see the
> definition.

same thing here

> I like that the *Help* buffer itself opens a new window, but once I've
> got that new window I want the source file in question to re-use it,
> rather than going back and clobbering the window I was in.

I like the fact that the help buffer opens in another window, but I
would like to be able to "remote-control" it from the source buffer
where I called C-h f or C-h v or so. 

With point remaining in the source buffer, I can scroll up and down the
help buffer, but I would like to have commands like

 1. help-kill-buffer-and-go-back-to-original-window-config

 2. help-go-to-source (i.e. first link in help buffer)

 3. help-back-to-original-window-config (without killing the help buffer ->
  winner-undo might do this job)

 4. help-restore-window-config (winner-redo or winner-undo might do the
 job. go back to the window-config that resulted after the help call,
 e.g. after visiting one or more source-files)

 5. help-select-links (with-ido or so, i.e. collect all the links -
 except to the source file - in the help buffer in an alist and use that
 collection for quick selection in the mini-buffer.

All this should be done remotely without a need to switch to the help
buffer. C-h f and C-h v are such frequent commands that avoiding the
switching of windows and maybe TAB-ing involved when using Emacs help
functionality would be a real improvement - IMO.

-- 
cheers,
Thorsten

Re: I wish list-buffers used my current window when it listed my buffers

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Rustom Mody <rustompmody@gmail.com> writes:
>
> > On Thursday, August 15, 2013 7:32:50 AM UTC+5:30, Jay Cotton wrote:
> >> I've always wished list-buffers used my current window when it
> >> listed my
> >> buffers. I don't know why, but this rubbed me the wrong way
> >> immediately when
> >> I learned the command, and I've never been able to shake it.
> >
> > Does this work?
> >
> > (add-to-list 'same-window-buffer-names "*Buffer List*")
>
> Hey I was just thinking something similar about the *Help* buffer: I
> often look up docs for functions and variables, and then end up TAB-bing
> to the source file link and hitting return to see the definition.
>
> I like that the *Help* buffer itself opens a new window, but once I've
> got that new window I want the source file in question to re-use it,
> rather than going back and clobbering the window I was in.
>
> That's not quite the same thing as the OP's question, but it seems like
> a close cousin. I eventually found `display-buffer-alist' (I'm on 24.3),
> but the docstring for that is as confusing as any emacs docs I've ever
> read.

`display-buffer-alist': yes, it's not easy, and the docstring is not a
tutorial.  Please read

  (info "(elisp) Display Action Functions")

where it is explained well.

> Has anyone accomplished what I'm after?

I'm afraid that the buffer switching function is hardcoded in the button
definition in help-mode.el:

--8<---------------cut here---------------start------------->8---
(define-button-type 'help-function-def
  :supertype 'help-xref
  'help-function (lambda (fun file)
		   (require 'find-func)
		   (when (eq file 'C-source)
		     (setq file
			   (help-C-file-name (indirect-function fun) 'fun)))
		   ;; Don't use find-function-noselect because it follows
		   ;; aliases (which fails for built-in functions).
		   (let ((location
			  (find-function-search-for-symbol fun nil file)))
		     (pop-to-buffer (car location)) ; <--------------------
		     (if (cdr location)
			 (goto-char (cdr location))
		       (message "Unable to find location in file"))))
  'help-echo (purecopy "mouse-2, RET: find function's definition"))
--8<---------------cut here---------------end--------------->8---

To change the behavior, you have to redefine the button, replacing
`pop-to-buffer' with your own function.

Personally, I use this:

--8<---------------cut here---------------start------------->8---
(with-eval-after-load 'help
  (define-button-type 'help-function-def
    :supertype 'help-xref
    'help-function (lambda (fun file)
		     (require 'find-func)
		     (when (eq file 'C-source)
		       (setq file
			     (help-C-file-name (indirect-function fun) 'fun)))
		     ;; Don't use find-function-noselect because it follows
		     ;; aliases (which fails for built-in functions).
		     (let ((location
			    (find-function-search-for-symbol fun nil file)))
		       (my-find-symbol-switch-to-buffer (car location))
		       (if (cdr location)
			   (goto-char (cdr location))
			 (message "Unable to find location in file"))))
    'help-echo (purecopy "mouse-2, RET: find function's definition")))
--8<---------------cut here---------------end--------------->8---

where `my-find-symbol-switch-to-buffer' does what I want (i use it also
for "find-func.el" stuff).


Michael.

Re: I wish list-buffers used my current window when it listed my buffers

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Rustom Mody <rustompmody@gmail.com> writes:
>>
>> > On Thursday, August 15, 2013 7:32:50 AM UTC+5:30, Jay Cotton wrote:
>> >> I've always wished list-buffers used my current window when it
>> >> listed my
>> >> buffers. I don't know why, but this rubbed me the wrong way
>> >> immediately when
>> >> I learned the command, and I've never been able to shake it.
>> >
>> > Does this work?
>> >
>> > (add-to-list 'same-window-buffer-names "*Buffer List*")
>>
>> Hey I was just thinking something similar about the *Help* buffer: I
>> often look up docs for functions and variables, and then end up TAB-bing
>> to the source file link and hitting return to see the definition.
>>
>> I like that the *Help* buffer itself opens a new window, but once I've
>> got that new window I want the source file in question to re-use it,
>> rather than going back and clobbering the window I was in.
>>
>> That's not quite the same thing as the OP's question, but it seems like
>> a close cousin. I eventually found `display-buffer-alist' (I'm on 24.3),
>> but the docstring for that is as confusing as any emacs docs I've ever
>> read.
>
> `display-buffer-alist': yes, it's not easy, and the docstring is not a
> tutorial.  Please read
>
>   (info "(elisp) Display Action Functions")
>
> where it is explained well.
>
>> Has anyone accomplished what I'm after?
>
> I'm afraid that the buffer switching function is hardcoded in the button
> definition in help-mode.el:
>
> (define-button-type 'help-function-def
>   :supertype 'help-xref
>   'help-function (lambda (fun file)
> 		   (require 'find-func)
> 		   (when (eq file 'C-source)
> 		     (setq file
> 			   (help-C-file-name (indirect-function fun) 'fun)))
> 		   ;; Don't use find-function-noselect because it follows
> 		   ;; aliases (which fails for built-in functions).
> 		   (let ((location
> 			  (find-function-search-for-symbol fun nil file)))
> 		     (pop-to-buffer (car location)) ; <--------------------
> 		     (if (cdr location)
> 			 (goto-char (cdr location))
> 		       (message "Unable to find location in file"))))
>   'help-echo (purecopy "mouse-2, RET: find function's definition"))
>
> To change the behavior, you have to redefine the button, replacing
> `pop-to-buffer' with your own function.
>
> Personally, I use this:
>
> (with-eval-after-load 'help
>   (define-button-type 'help-function-def
>     :supertype 'help-xref
>     'help-function (lambda (fun file)
> 		     (require 'find-func)
> 		     (when (eq file 'C-source)
> 		       (setq file
> 			     (help-C-file-name (indirect-function fun) 'fun)))
> 		     ;; Don't use find-function-noselect because it follows
> 		     ;; aliases (which fails for built-in functions).
> 		     (let ((location
> 			    (find-function-search-for-symbol fun nil file)))
> 		       (my-find-symbol-switch-to-buffer (car location))
> 		       (if (cdr location)
> 			   (goto-char (cdr location))
> 			 (message "Unable to find location in file"))))
>     'help-echo (purecopy "mouse-2, RET: find function's definition")))
>
> where `my-find-symbol-switch-to-buffer' does what I want (i use it also
> for "find-func.el" stuff).
>
>
> Michael.

Excellent, thanks very much both for the doc link and the code snippet!
I'll give this a whirl.

E

I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

I've always wished list-buffers used my current window when it listed my buffers. I don't know why, but this rubbed me the wrong way immediately when I learned the command, and I've never been able to shake it.

Years ago I figured out a way to get what I wanted[1], but now I jump from machine to machine and I'm always firing up emacs on distant machines and immediately missing my little hack when I C-x C-b. Continuing with C-x 0 seems like a lot of typing just to to begin navigating to the buffer I'm looking for.

Is there a simple way to get what I want when I'm running emacs away from my customizations? [2][3]

Thanks,
Jay

[1] I was inexperienced with emacs/elisp and I naively re-defun'd 'list-buffers to switch to the buffer instead of creating a new window and displaying it there.

[2] I vaguely recall that there is a special variable for a list of commands that shouldn't use new windows, but I also vaguely recall that I used it and it stopped working for 'list-buffers.

[3] I realize that, taken out of context, this is a laughably complicated question and probably the holy grail of countless migrant emacs users the world over. But here I'm just talking about how to get my buffers to list in the same window, when, for instance, I'm using somebody else's emacs process.

Re: I wish list-buffers used my current window when it listed my buffers

[Bob Proulx]

Jay Cotton wrote:
> I've always wished list-buffers used my current window when it
> listed my buffers. I don't know why, but this rubbed me the wrong
> way immediately when I learned the command, and I've never been able
> to shake it.

Instead of getting list-buffers into the current directory please try
using electric-buffer-list instead.  In my opinion it works much nicer
and really should be the default instead of list-buffers.

  (global-set-key "\C-x\C-b" 'electric-buffer-list) ; originally list-buffers

Bob

Re: I wish list-buffers used my current window when it listed my buffers

[Dan Espen]

Bob Proulx <bob@proulx.com> writes:

> Jay Cotton wrote:
>> I've always wished list-buffers used my current window when it
>> listed my buffers. I don't know why, but this rubbed me the wrong
>> way immediately when I learned the command, and I've never been able
>> to shake it.
>
> Instead of getting list-buffers into the current directory please try
> using electric-buffer-list instead.  In my opinion it works much nicer
> and really should be the default instead of list-buffers.
>
>   (global-set-key "\C-x\C-b" 'electric-buffer-list) ; originally list-buffers

Someone else agrees with you:

http://www.emacswiki.org/emacs/ElectricBufferList

I wonder if a bug report would have any effect.

-- 
Dan Espen

Re: I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

Is it just you and me, or do lots of others also think this behavior makes better sense? (From a windowing perspective, that is. I can't speak to the technical pros and cons of electric-buffer-list vs. the traditional list-buffers, I just like that the former opens in the same window.)

I list buffers *constantly* when I'm working in emacs. I've always got 3 or 4 windows open, and I'm somewhat OCD about keeping things where I want them, and the problem is that with such an arrangement, I can't always predict where list-buffers is going to pop up the buffer list. I haven't studied the problem carefully, and I assume it has something to do with the order in which I created the windows. But I don't always create the windows in the same order. Usually my arrangement just sort of evolves as I'm working, and in any event I can't always predict which window will be used to pop up the buffer.

This difficult-to-predict window behavior has always seemed un-emacs-y to me. And I've always wondered if I'm somehow "doing it wrong" since it causes me such grief when my .emacs file isn't available.

Jay

On Aug 15, 2013, at 8:45 AM, Dan Espen <despen@verizon.net> wrote:

> Bob Proulx <bob@proulx.com> writes:
> 
>> Jay Cotton wrote:
>>> I've always wished list-buffers used my current window when it
>>> listed my buffers. I don't know why, but this rubbed me the wrong
>>> way immediately when I learned the command, and I've never been able
>>> to shake it.
>> 
>> Instead of getting list-buffers into the current directory please try
>> using electric-buffer-list instead.  In my opinion it works much nicer
>> and really should be the default instead of list-buffers.
>> 
>>  (global-set-key "\C-x\C-b" 'electric-buffer-list) ; originally list-buffers
> 
> Someone else agrees with you:
> 
> http://www.emacswiki.org/emacs/ElectricBufferList
> 
> I wonder if a bug report would have any effect.
> 
> -- 
> Dan Espen

Re: I wish list-buffers used my current window when it listed my buffers

[Michael Heerdegen]

Jay Cotton <jay.cotton@gmail.com> writes:

> Is it just you and me, or do lots of others also think this behavior
> makes better sense? (From a windowing perspective, that is. I can't
> speak to the technical pros and cons of electric-buffer-list vs. the
> traditional list-buffers, I just like that the former opens in the
> same window.)
>
> I list buffers *constantly* when I'm working in emacs. I've always got
> 3 or 4 windows open, and I'm somewhat OCD about keeping things where I
> want them, and the problem is that with such an arrangement, I can't
> always predict where list-buffers is going to pop up the buffer
> list. I haven't studied the problem carefully, and I assume it has
> something to do with the order in which I created the windows. But I
> don't always create the windows in the same order. Usually my
> arrangement just sort of evolves as I'm working, and in any event I
> can't always predict which window will be used to pop up the buffer.
>
> This difficult-to-predict window behavior has always seemed un-emacs-y
> to me. And I've always wondered if I'm somehow "doing it wrong" since
> it causes me such grief when my .emacs file isn't available.

Configuring `display-buffer-alist is a good solution in the most cases.
For the other cases, you at least have winner.el to undo buffer popping
you didn't want (`winner-undo').

BTW, AFAIK Stefan plans to implement prefix keys that control the buffer
displaying behavior of the following command.  There would be a default
behavior, and you can use those prefixes to deviate from the default.

Michael.

Re: I wish list-buffers used my current window when it listed my buffers

[Michael Heerdegen]

Jay Cotton <jay.cotton@gmail.com> writes:

> Is it just you and me, or do lots of others also think this behavior
> makes better sense? (From a windowing perspective, that is. I can't
> speak to the technical pros and cons of electric-buffer-list vs. the
> traditional list-buffers, I just like that the former opens in the
> same window.)
>
> I list buffers *constantly* when I'm working in emacs. I've always got
> 3 or 4 windows open, and I'm somewhat OCD about keeping things where I
> want them, and the problem is that with such an arrangement, I can't
> always predict where list-buffers is going to pop up the buffer
> list. I haven't studied the problem carefully, and I assume it has
> something to do with the order in which I created the windows. But I
> don't always create the windows in the same order. Usually my
> arrangement just sort of evolves as I'm working, and in any event I
> can't always predict which window will be used to pop up the buffer.
>
> This difficult-to-predict window behavior has always seemed un-emacs-y
> to me. And I've always wondered if I'm somehow "doing it wrong" since
> it causes me such grief when my .emacs file isn't available.

Configuring `display-buffer-alist is a good solution in the most cases.
For the other cases, you at least have winner.el to undo buffer popping
you didn't want (`winner-undo').

BTW, AFAIK Stefan plans to implement prefix keys that control the buffer
displaying behavior of the following command.  There would be a default
behavior, and you can use those prefixes to deviate from the default.

Michael.

Re: I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

On Aug 16, 2013, at 9:33 AM, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Jay Cotton <jay.cotton@gmail.com> writes:
> 
>> Is it just you and me, or do lots of others also think this behavior
>> makes better sense? (From a windowing perspective, that is. I can't
>> speak to the technical pros and cons of electric-buffer-list vs. the
>> traditional list-buffers, I just like that the former opens in the
>> same window.)
>> 
>> I list buffers *constantly* when I'm working in emacs. I've always got
>> 3 or 4 windows open, and I'm somewhat OCD about keeping things where I
>> want them, and the problem is that with such an arrangement, I can't
>> always predict where list-buffers is going to pop up the buffer
>> list. I haven't studied the problem carefully, and I assume it has
>> something to do with the order in which I created the windows. But I
>> don't always create the windows in the same order. Usually my
>> arrangement just sort of evolves as I'm working, and in any event I
>> can't always predict which window will be used to pop up the buffer.
>> 
>> This difficult-to-predict window behavior has always seemed un-emacs-y
>> to me. And I've always wondered if I'm somehow "doing it wrong" since
>> it causes me such grief when my .emacs file isn't available.
> 
> Configuring `display-buffer-alist is a good solution in the most cases.
> For the other cases, you at least have winner.el to undo buffer popping
> you didn't want (`winner-undo').
> 
> BTW, AFAIK Stefan plans to implement prefix keys that control the buffer
> displaying behavior of the following command.  There would be a default
> behavior, and you can use those prefixes to deviate from the default.
> 
> Michael.

I didn't know about winner.el. Thanks, that sounds very useful.

Also, the window behavior prefix command sounds like a neat idea. It seems like it would have to be either:

a) different for different commands, in order to maintain existing differences in prefix args (ie., C-u C-x 'some-command might already mean something)

or 

b) obscure enough that it would risk being tedious to use

right? A difficult task indeed, I hope I can help somehow.

Thanks again,
Jay

Re: I wish list-buffers used my current window when it listed my buffers

[Michael Heerdegen]

Jay Cotton <jay.cotton@gmail.com> writes:

> Also, the window behavior prefix command sounds like a neat idea. It
> seems like it would have to be either:
>
> a) different for different commands, in order to maintain existing
> differences in prefix args (ie., C-u C-x 'some-command might already
> mean something)
>
> or 
>
> b) obscure enough that it would risk being tedious to use

An example:

C-x C-b acts according to your default.

C-x 4 C-x C-b would pop up a new window and use it.

C-x 5 C-x C-b would create a new frame and use it.

C-x 4 and C-x 5 are already a prefixes (in the sense of key bindings), but
not realized as commands.

You would still be able to use prefix args, like

C-x 5 C-u 1 C-x C-b

> right? A difficult task indeed, I hope I can help somehow.

These are future plans.

I tried to implement something like this for myself, but discarded it.
The concept is easy, but the details are not.  For example, if you use
C-x 5 before a command that at first reads in a string with completion,
do you want your completion list to appear in a new frame when hitting
TAB?  Probably not.  Commands that display multiple new buffers are
problematic.


Michael.

Re: I wish list-buffers used my current window when it listed my buffers

[Dan Espen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Jay Cotton <jay.cotton@gmail.com> writes:
>
>> Is it just you and me, or do lots of others also think this behavior
>> makes better sense? (From a windowing perspective, that is. I can't
>> speak to the technical pros and cons of electric-buffer-list vs. the
>> traditional list-buffers, I just like that the former opens in the
>> same window.)
>>
>> I list buffers *constantly* when I'm working in emacs. I've always got
>> 3 or 4 windows open, and I'm somewhat OCD about keeping things where I
>> want them, and the problem is that with such an arrangement, I can't
>> always predict where list-buffers is going to pop up the buffer
>> list. I haven't studied the problem carefully, and I assume it has
>> something to do with the order in which I created the windows. But I
>> don't always create the windows in the same order. Usually my
>> arrangement just sort of evolves as I'm working, and in any event I
>> can't always predict which window will be used to pop up the buffer.
>>
>> This difficult-to-predict window behavior has always seemed un-emacs-y
>> to me. And I've always wondered if I'm somehow "doing it wrong" since
>> it causes me such grief when my .emacs file isn't available.
>
> Configuring `display-buffer-alist is a good solution in the most cases.
> For the other cases, you at least have winner.el to undo buffer popping
> you didn't want (`winner-undo').
>
> BTW, AFAIK Stefan plans to implement prefix keys that control the buffer
> displaying behavior of the following command.  There would be a default
> behavior, and you can use those prefixes to deviate from the default.

I still think any tweaking of list-buffers is a waste of time.
Just replace it with the electric version.

-- 
Dan Espen

Re: I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

On Aug 16, 2013, at 10:03 AM, Dan Espen <despen@verizon.net> wrote:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
>> Jay Cotton <jay.cotton@gmail.com> writes:
>> 
>>> Is it just you and me, or do lots of others also think this behavior
>>> makes better sense? (From a windowing perspective, that is. I can't
>>> speak to the technical pros and cons of electric-buffer-list vs. the
>>> traditional list-buffers, I just like that the former opens in the
>>> same window.)
>>> 
>>> I list buffers *constantly* when I'm working in emacs. I've always got
>>> 3 or 4 windows open, and I'm somewhat OCD about keeping things where I
>>> want them, and the problem is that with such an arrangement, I can't
>>> always predict where list-buffers is going to pop up the buffer
>>> list. I haven't studied the problem carefully, and I assume it has
>>> something to do with the order in which I created the windows. But I
>>> don't always create the windows in the same order. Usually my
>>> arrangement just sort of evolves as I'm working, and in any event I
>>> can't always predict which window will be used to pop up the buffer.
>>> 
>>> This difficult-to-predict window behavior has always seemed un-emacs-y
>>> to me. And I've always wondered if I'm somehow "doing it wrong" since
>>> it causes me such grief when my .emacs file isn't available.
>> 
>> Configuring `display-buffer-alist is a good solution in the most cases.
>> For the other cases, you at least have winner.el to undo buffer popping
>> you didn't want (`winner-undo').
>> 
>> BTW, AFAIK Stefan plans to implement prefix keys that control the buffer
>> displaying behavior of the following command.  There would be a default
>> behavior, and you can use those prefixes to deviate from the default.
> 
> I still think any tweaking of list-buffers is a waste of time.
> Just replace it with the electric version.
> 
> -- 
> Dan Espen

I hate to pick nits with the guy who seems closest to my POV on this issue, but after using the electric version a little bit I did notice some weirdness.

For instance, it clobbers C-x and a bunch of other huge keybindings. I can't select text for the kill ring. I can't isearch for the buffer I'm looking for.

I love the fact that it opens in the same window, but I can imagine the dev group catching a lot of flak if they replaced the 'list-buffers default with something so different as this.

However, it is very easy for me to memorize, and I will take advantage of it when I'm on a foreign machine!

Thanks,
Jay

Re: I wish list-buffers used my current window when it listed my buffers

[Bob Proulx]

Jay Cotton wrote:
> Dan Espen wrote:
> > I still think any tweaking of list-buffers is a waste of time.
> > Just replace it with the electric version.
> 
> I hate to pick nits with the guy who seems closest to my POV on this
> issue, but after using the electric version a little bit I did
> notice some weirdness.
> 
> For instance, it clobbers C-x and a bunch of other huge
> keybindings. I can't select text for the kill ring. I can't isearch
> for the buffer I'm looking for.

Those are annoying deficiencies.  Not enough to turn me off to it.
But definitely annoying that the interface isn't consistent with other
parts of emacs.  Maybe it would be possible to fix those things.

I have other things about electric-buffer-mode that annoy me.  It has
nasty highlighting that I disable.  The latest version uses an ugly
character set that I don't like but haven't been able to disable.

> I love the fact that it opens in the same window, but I can imagine
> the dev group catching a lot of flak if they replaced the
> 'list-buffers default with something so different as this.

I only wish that they would get in trouble for breaking long standing
behavior!  Every time a I upgrade to a new release of emacs I spend a
lot of time fixing things back to the way they were before.  They
definitely don't seem to be holding back on changing major behaviors.

Bob

Re: I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

On Aug 16, 2013, at 6:51 PM, Bob Proulx <bob@proulx.com> wrote:

> Jay Cotton wrote:
>> Dan Espen wrote:
>>> I still think any tweaking of list-buffers is a waste of time.
>>> Just replace it with the electric version.
>> 
>> I hate to pick nits with the guy who seems closest to my POV on this
>> issue, but after using the electric version a little bit I did
>> notice some weirdness.
>> 
>> For instance, it clobbers C-x and a bunch of other huge
>> keybindings. I can't select text for the kill ring. I can't isearch
>> for the buffer I'm looking for.
> 
> Those are annoying deficiencies.  Not enough to turn me off to it.
> But definitely annoying that the interface isn't consistent with other
> parts of emacs.  Maybe it would be possible to fix those things.

Definitely possible, although I'm not sure how much we'd gain by fixing electric-buffer-list rather than just making list-buffers use the same window. (Which is trivial to implement (I know because I naively reimplemented the function before learning about affordances such as same-window-buffer-list, etc.) but extremely difficult to ship due to the certainty of broken workflows.

> 
> I have other things about electric-buffer-mode that annoy me.  It has
> nasty highlighting that I disable.  The latest version uses an ugly
> character set that I don't like but haven't been able to disable.
> 
>> I love the fact that it opens in the same window, but I can imagine
>> the dev group catching a lot of flak if they replaced the
>> 'list-buffers default with something so different as this.
> 
> I only wish that they would get in trouble for breaking long standing
> behavior!  Every time a I upgrade to a new release of emacs I spend a
> lot of time fixing things back to the way they were before.  They
> definitely don't seem to be holding back on changing major behaviors.
> 
> Bob

Ugrading 30+ year old software is tough stuff! :)

I'm relatively new to this list, but to be honest I find it refreshing to hear that you think the dev team isn't holding back too much on changing major behaviors. I mean, I feel your pain in the abstract, because it sucks to have a broken workflow. I hate it when new emacs breaks my .emacs.

But from my perspective, there's some old stuff in emacs that absolutely should be reconsidered given what we've learned over the years. And it's important for the team to be willing the break workflows when necessary for the greater good. And a lot of what breaks in my .emacs are *hacks* that I've been forced to employ for various embarrassing OCD programmer reasons. :) Like not wanting my windows messed up!

Anyway, I appreciate all your suggestions. Figuring it out as I go.

Thanks,
Jay

Re: I wish list-buffers used my current window when it listed my buffers

[Stefan Monnier]

> Ugrading 30+ year old software is tough stuff! :)

Thank you for your understanding.

Indeed, we do make backward incompatible changes all the time, and at
the same time we refrain from doing so.  It's a delicate balance, and
I think there's no way to get right even for a single individual, let
along for everyone.  We just try to minimize the overall annoyance of
inertia and change.


        Stefan

Re: I wish list-buffers used my current window when it listed my buffers

[Rustom Mody]

On Wednesday, August 21, 2013 4:37:35 AM UTC+5:30, Stefan Monnier wrote:
> > Ugrading 30+ year old software is tough stuff! :)
> 
> Thank you for your understanding.
> 
> Indeed, we do make backward incompatible changes all the time, and at
> the same time we refrain from doing so.  It's a delicate balance, and
> I think there's no way to get right even for a single individual, let
> along for everyone.  We just try to minimize the overall annoyance of
> inertia and change.

:-) I remember ducking the debris from the explosions around visual-line-mode :-)

Seriously I feel biting the bullet may all-round the best solution (which includes your health and sanity!)

Something like this:

- A comprehensive list of changes is drawn up without scrimping on 'incompatible' including terminology (window/frame vs pane/window etc)
- 24 is declared as stable and supported for the next 7 years, ie minor bugs will be fixed, major functionality will not be added
- to the extent possible, converter functionality is provided to make old elisp into new
- likewise for documentation

My own prejudices: 

I am a programmer, but more a teacher of programming.
Personally it does not matter too much to me whether I press C-x or C-w to 'cut' but it matters a great deal to my students/their employers etc, so that more and more I am finding emacs a hard-sell. Hopefully you will consider that there are a thousand-fold guys like me 'at the fringes' who would give  great deal to have emacs a little more mainstream/less weird

Re: I wish list-buffers used my current window when it listed my buffers

[Bob Proulx]

Rustom Mody wrote:
> :-) I remember ducking the debris from the explosions around
> visual-line-mode :-)

I hate visual line mode.  I find it very frustrating to use.  I always
turn it off.  I can see where some people might want it.  But at the
same time since I mostly deal with line and column oriented editing I
find it really terrible and frustrating.

> - A comprehensive list of changes is drawn up without scrimping on
> - 'incompatible' including terminology (window/frame vs pane/window
> - etc)

I don't actually care as much about how it is documented.  Names of
things and so forth.  I would be okay with various documented names.
It is hard to change something that is documented one way for 30 years
in many places to something incompatibly different.  I know that the
documentation was the original topic point and just saying I don't
actually feel as strongly about it.  It is the other topic drift that
I feel much more concerned about.

> - 24 is declared as stable and supported for the next 7 years, ie
> - minor bugs will be fixed, major functionality will not be added

And if someone were to suggest the same thing of emacs 23?  Or 22?  Or
21?  Would you feel the same thing then?  Because two years from now
when emacs 27 is out (intentional exaggeration) I am sure people will
say that emacs 24 is so old.  The newest 27 is the only thing to use.
Emacs 24 is new now and everyone claims it is awesome.  But I
guarentee you that in two years the new Emacs XY.Z will heralded as
awesome and Emacs 24 will be disparaged as being terrible.  It is all
a matter of perspective.

> Personally it does not matter too much to me whether I press C-x or
> C-w to 'cut' but it matters a great deal to my students/their
> employers etc, so that more and more I am finding emacs a
> hard-sell. Hopefully you will consider that there are a
> thousand-fold guys like me 'at the fringes' who would give great
> deal to have emacs a little more mainstream/less weird

But think about those of us to whom it matters in the other direction.
I have been pressing C-w to cut for many years.  And C-x for extended
commands just makes sense.  You are claiming that it is holding it
back because new users don't want to use it.  But previous users of it
will want that model of operation and destroying it for them is just
as bad in reverse.  The model of operation of the editor is a major
thing.  Changing the operating model is so big that it really is a
dividing line between one editor and another.  If Emacs changes into
Word then it won't be Emacs anymore but will be a different editor.

This is the classic problem.  "I love you.  You are perfect.  Now
change."  Grr...  Instead if you want an editor with a different
operating model then I am all for it!  I think you should create an
editor with this different operating model.  Go for it!  It could be
very popular and very mainstream.  That would be awesome!  You would
like it.  I am sure that a very large number of people would like it.
And best of all it wouldn't hurt people who want the Emacs operating
model.  Please don't destroy one tool in order to convert it into
another different tool.

You can't please everyone all of the time.  Especially not with the
same tools.  It is okay to have a choice of different tools.  Then
people can use the one that fits them the best.

Bob

Re: I wish list-buffers used my current window when it listed my buffers

[Rustom Mody]

On Thursday, August 22, 2013 4:25:32 AM UTC+5:30, Bob Proulx wrote:
> This is the classic problem.  "I love you.  You are perfect.  Now
> change."  Grr...  Instead if you want an editor with a different
> operating model then I am all for it!  I think you should create an
> editor with this different operating model.  Go for it!  It could be
> very popular and very mainstream.  That would be awesome!

Heh! Minefield here!   And its not even my war

> You would like it.  

I did say it makes little difference to me.
I also said it makes a difference to those I work with. Let me modify that slightly. If I say "Just use C-w instead of C-x" its no big deal but when those 'just's are multiplied a hundred-fold, I get written off as a weirdo.  So that's not your problem.... Ok...


> I am sure that a very large number of people would like it.
> And best of all it wouldn't hurt people who want the Emacs operating
> model.  Please don't destroy one tool in order to convert it into
> another different tool.

One man's 'destroy' is another's 'customize'.

Re: I wish list-buffers used my current window when it listed my buffers

[Michael Heerdegen]

Jay Cotton <jay.cotton@gmail.com> writes:

> I hate to pick nits with the guy who seems closest to my POV on this
> issue, but after using the electric version a little bit I did notice
> some weirdness.

Maybe you like M-x ibuffer.  It is like `list-buffers', but opens in the
same window, and offers a superset of functionality.

BTW, there was (or, were, multiple) discussions in emacs-dev/bug whether
to make ibuffer the binding of C-x C-b, but it was discarded.


Michael.

Re: I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

On Aug 16, 2013, at 7:08 PM, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Jay Cotton <jay.cotton@gmail.com> writes:
> 
>> I hate to pick nits with the guy who seems closest to my POV on this
>> issue, but after using the electric version a little bit I did notice
>> some weirdness.
> 
> Maybe you like M-x ibuffer.  It is like `list-buffers', but opens in the
> same window, and offers a superset of functionality.

This also is new to me! It sounds perfect, and easily memorizable for when I'm in a foreign emacs. 

> BTW, there was (or, were, multiple) discussions in emacs-dev/bug whether
> to make ibuffer the binding of C-x C-b, but it was discarded.

I'm new to this list, so I missed those discussions unfortunately. Oh well, it's probably something you guys have beaten to death! Sorry to bring it up again if that is the case.

Thanks,
Jay

Re: I wish list-buffers used my current window when it listed my buffers

[Jay Cotton]

On Aug 16, 2013, at 7:08 PM, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Jay Cotton <jay.cotton@gmail.com> writes:
> 
>> I hate to pick nits with the guy who seems closest to my POV on this
>> issue, but after using the electric version a little bit I did notice
>> some weirdness.
> 
> Maybe you like M-x ibuffer.  It is like `list-buffers', but opens in the
> same window, and offers a superset of functionality.

This also is new to me! It sounds perfect, and easily memorizable for when I'm in a foreign emacs. 

> BTW, there was (or, were, multiple) discussions in emacs-dev/bug whether
> to make ibuffer the binding of C-x C-b, but it was discarded.

I'm new to this list, so I missed those discussions unfortunately. Oh well, it's probably something you guys have beaten to death! Sorry to bring it up again if that is the case.

Thanks,
Jay

Re: I wish list-buffers used my current window when it listed my buffers

[Dan Espen]

Bob Proulx <bob@proulx.com> writes:

> Jay Cotton wrote:
>> Dan Espen wrote:
>> > I still think any tweaking of list-buffers is a waste of time.
>> > Just replace it with the electric version.
>> 
>> I hate to pick nits with the guy who seems closest to my POV on this
>> issue, but after using the electric version a little bit I did
>> notice some weirdness.
>> 
>> For instance, it clobbers C-x and a bunch of other huge
>> keybindings. I can't select text for the kill ring. I can't isearch
>> for the buffer I'm looking for.
>
> Those are annoying deficiencies.  Not enough to turn me off to it.
> But definitely annoying that the interface isn't consistent with other
> parts of emacs.  Maybe it would be possible to fix those things.
>
> I have other things about electric-buffer-mode that annoy me.  It has
> nasty highlighting that I disable.  The latest version uses an ugly
> character set that I don't like but haven't been able to disable.

Interesting.

Of course I don't use buffer-list so I was unaware of any issues.

I don't have any issues with the highlighting which I've customized to
suit myself or the fonts (which are identical to all my other fonts).

>> I love the fact that it opens in the same window, but I can imagine
>> the dev group catching a lot of flak if they replaced the
>> 'list-buffers default with something so different as this.
>
> I only wish that they would get in trouble for breaking long standing
> behavior!  Every time a I upgrade to a new release of emacs I spend a
> lot of time fixing things back to the way they were before.  They
> definitely don't seem to be holding back on changing major behaviors.

Maybe something in the customize system to choose would be a suitable
compromise.  Best would be to have one be a compatible super set of the
other so one could be dispensed with.

-- 
Dan Espen

Re: I wish list-buffers used my current window when it listed my buffers

[Samuel Wales]

I wish ALL commands in Emacs used my current window.

Period.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Denmark: free Karina Hansen NOW.