<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Jul 18, 2008 at 12:48 PM, David Reitter <<a href="mailto:david.reitter@gmail.com">david.reitter@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
I think we have a problem with packages like SLIME that happily switch between buffers, even temporary ones.<br>
<br>
Nathaniel, do we take care to not permanently create tabs for buffers that are shown via `switch-to-buffer' with the `norecord' argument set?</blockquote><div class="Ih2E3d"><br>Currently, no, the tabs implementation doesn't check for this.  I'll look into it. <br>

<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
All you need is a policy for how the tab bar looks, given the buffer list and the current buffer. After a call to bury-buffer or whatever, the tab<br>
bar should just reflect the new structure of the buffers. APIs for buffers and for tabs should be independent.<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That is not consistent with how things work in Aquamacs.  I appreciate that the underlying Emacs has a slightly different philosophy.</blockquote></div><br>Apart from philosophy: tabs are designed to be window-dependent -- you can display the same buffer with a tab in two different windows, and close that tab in one window without affecting the other.  Tab display has to change in this case without affecting the buffer list.  Similarly, some buffers should not be killed when all their tabs are closed (e.g. *Messages*), so we can't look to a buffer list to determine which tabs should appear.<br>
<br>Given your particular usage and desires, you may want to try tabbar.el without the Aquamacs enhancements to tabs.  Alone, it doesn't follow the modern conventions for a tabbed interface, but it might suit your needs better.<br>
<br>--Nathaniel<br></div>