Tabs are ready?

Tabs are ready?

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

 I have worked long time ago on tabs for console. I did not finish it,
because I did not have a clear point how to design their internals, and
nobody answered me at that time to work together, in order to define them.
I wrote just the code to display/hide them. Here is the post:

http://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00067.html

Personally, I need tabs. When do you think they will be ready for use in
the main branch ?

Alin

[-- Attachment #2: Type: text/html, Size: 653 bytes --]

Re: Tabs are ready?

[Juri Linkov]

>  I have worked long time ago on tabs for console. I did not finish it,
> because I did not have a clear point how to design their internals, and
> nobody answered me at that time to work together, in order to define them.
> I wrote just the code to display/hide them. Here is the post:
>
> http://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00067.html
>
> Personally, I need tabs. When do you think they will be ready for use in
> the main branch ?

Wouldn't it be easier to implement tabs now with the help of Martin's side windows?

Re: Tabs are ready?

[martin rudalics]

 > Wouldn't it be easier to implement tabs now with the help of Martin's side windows?

It depends on what "tabs" stands for and how many "tabs" we want to show
on any frame: If we want per-window tabs, atomic windows should be used.
If we want per-frame tabs, side windows could be used.

martin

Re: Tabs are ready?

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

When I wrote them, I tried a few possibilities, but I remember I inserted
them in the struct of a frame.

In any case, a tab shoud be able to respond to events, and each event must
be defined by a lisp function.

This is the point where I stopped.

I finished only the creation/deletion/ basic functions for tabs, and I
inserted some simple events, like hide tab, or show tab, and did not
continue any more.

Whatever implementation will be , it must define the events as elisp
functions ; even after the creation of a tab, there must be an event that
calls a lisp function.

In this manner, we will be able to have a lots of functionalities
implemented as tabs. There can be defined lots of patterns for tabs.





2012/2/2 martin rudalics <rudalics@gmx.at>

> > Wouldn't it be easier to implement tabs now with the help of Martin's
> side windows?
>
> It depends on what "tabs" stands for and how many "tabs" we want to show
> on any frame: If we want per-window tabs, atomic windows should be used.
> If we want per-frame tabs, side windows could be used.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

Re: Tabs are ready?

[martin rudalics]

 > When I wrote them, I tried a few possibilities, but I remember I inserted
 > them in the struct of a frame.

There is a package that implements tabs on a per window basis in their
header lines.  So we should settle on a strategy for this.

martin

Re: Tabs are ready?

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

2012/2/2 martin rudalics <rudalics@gmx.at>

> > When I wrote them, I tried a few possibilities, but I remember I inserted
> > them in the struct of a frame.
>
> There is a package that implements tabs on a per window basis in their
> header lines.  So we should settle on a strategy for this.



What I did is not like this.

[-- Attachment #2: Type: text/html, Size: 657 bytes --]

Re: Tabs are ready?

[Juri Linkov]

> Whatever implementation will be , it must define the events as elisp
> functions ; even after the creation of a tab, there must be an event that
> calls a lisp function.

In http://bzr.sv.gnu.org/lh/emacs/x-tabs I added a new frame parameter
`tab_bar_lines' that holds a keymap with items bound to Lisp functions.

But now I tend to try side windows and atomic windows because
frame-level features (like a frame parameter or native GTK tabs)
are of no help for implementing per-window tabs.

Re: Tabs are ready?

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

> > Whatever implementation will be , it must define the events as elisp
> > functions ; even after the creation of a tab, there must be an event that
> > calls a lisp function.
>
> In http://bzr.sv.gnu.org/lh/emacs/x-tabs I added a new frame parameter
> `tab_bar_lines' that holds a keymap with items bound to Lisp functions.
>
>
I did the same.



> But now I tend to try side windows and atomic windows because
> frame-level features (like a frame parameter or native GTK tabs)
> are of no help for implementing per-window tabs.
>

That is also a possibility, but they must respond to events, too.

[-- Attachment #2: Type: text/html, Size: 1139 bytes --]

Re: Tabs are ready?

[Juri Linkov]

>> Wouldn't it be easier to implement tabs now with the help of Martin's side windows?
>
> It depends on what "tabs" stands for and how many "tabs" we want to show
> on any frame: If we want per-window tabs, atomic windows should be used.
> If we want per-frame tabs, side windows could be used.

I think we need both:

1. per-frame tabs are useful to switch window configurations
   (in other IDEs named "perspectives").

2. per-window tabs are useful e.g. to display a list of buffers
   visited in the window (`window-prev-buffers').  This is similar to
   other IDEs where per-window tabs can be used to select from a set
   of buffers like compilation, help, messages, etc.

Could you please provide examples of using side windows and atomic windows?

Re: Tabs are ready?

[martin rudalics]

 > Could you please provide examples of using side windows and atomic windows?

To make an atomic window use

(defun display-buffer-in-atom-window (buffer alist)
   "Display BUFFER in an atomic window.
This function displays BUFFER in a new window that will be
combined with an existing window to form an atomic window.  If
the existing window is already part of an atomic window, add the
new window to that atomic window.  Operations like `split-window'
or `delete-window', when applied to a constituent of an atomic
window, are applied atomically to the root of that atomic window.

ALIST is an association list of symbols and values.  The
following symbols can be used.

`window' specifies the existing window the new window shall be
   combined with.  Use `window-atom-root' to make the new window a
   sibling of an atomic window's root.  If an internal window is
   specified here, all children of that window become part of the
   atomic window too.  If no window is specified, the new window
   becomes a sibling of the selected window.

`side' denotes the side of the existing window where the new
   window shall be located.  Valid values are `below', `right',
   `above' and `left'.  The default is `below'.

The return value is the new window, nil when creating that window
failed."
   (let ((ignore-window-parameters t)
	(window-combination-limit t)
	(window (cdr (assq 'window alist)))
	(side (cdr (assq 'side alist)))
	new)
     (setq window (window-normalize-window window))
     ;; Split off new window
     (when (setq new (split-window window nil side))
       ;; Make sure we have a valid atomic window.
       (window-make-atom (window-parent window))
       ;; Display BUFFER in NEW.
       (display-buffer-record-window 'window new buffer)
       (window--display-buffer-2 buffer new display-buffer-mark-dedicated)
       (set-window-prev-buffers new nil)
       ;; Return NEW.
       new)))

To see the effect try

(display-buffer-in-atom-window (current-buffer) '((side . above)))

and afterwards do C-x 3 and then C-x 0.

I'm currently simplifying the side windows code so I would have to send
you the new functions.  But I don't have any good documentation ready
for them yet.

martin

Re: Tabs are ready?

[Juanma Barranquero]

On Fri, Feb 3, 2012 at 19:24, martin rudalics <rudalics@gmx.at> wrote:

> To make an atomic window use
>
> (defun display-buffer-in-atom-window (buffer alist)
>  "Display BUFFER in an atomic window.

Do you intend to commit that function?

    Juanma

Re: Tabs are ready?

[martin rudalics]

 >> (defun display-buffer-in-atom-window (buffer alist)
 >>  "Display BUFFER in an atomic window.
 >
 > Do you intend to commit that function?

Eventually.  Before I'd like to settle on a standard way to specify
window sizes in `display-buffer-alist'.

martin

Re: Tabs are ready?

[Alin Soare]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

>
>
> > http://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00067.html
> >
> > Personally, I need tabs. When do you think they will be ready for use in
> > the main branch ?
>
> Wouldn't it be easier to implement tabs now with the help of Martin's side
> windows?
>


Whatever solution will be agreed on as definitive, each tab MUST respond to
signals, like the widgets of gtk+. And each signal must be defined as an
elisp function.

Otherwise, we can live as well without them.

[-- Attachment #2: Type: text/html, Size: 889 bytes --]