Some minor suggestions to Tab Bar

Some minor suggestions to Tab Bar

[Gabriel]

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

Tab Bar is awesome and the recently added features to work with tab
groups made it even better. I know it's still a working in progress, but
I would like to suggest some minor improvements:

1. Add an initial input for the 'completing-read' of
'tab-bar-change-tab-group', so when we type 'C-x t G' to set/unset the
group name, the minibuffer contents is filled with the current group
value. A possible downside is that pressing TAB may not show the
Completions list, in case the current value does not match any item of
the completion list provided.

2. Add new faces for group tabs. The idea is to differentiate these 2
cases:
  2.1. Tabs from the current group X tabs from other groups
  2.2. Regular tabs X collapsed group tabs

This is the default appearance:


[-- Attachment #2: tab-bar-default-faces.png --]
[-- Type: image/png, Size: 23286 bytes --]

[-- Attachment #3: Type: text/plain, Size: 299 bytes --]


It's not possible to know which tabs belongs to the current group or
which tabs represent another group, since all inactive tabs use the same
face 'tab-bar-tab-inactive'. I did a slight modification to
'tab-bar-tab-name-format-default' and 'tab-bar-tab-group-format-default'
to add two new faces:


[-- Attachment #4: tab-bar-new-faces.png --]
[-- Type: image/png, Size: 24398 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1850 bytes --]


In the example above (please desconsider the styles I used), we can see
that:
  * [1], [2] and [8] are tabs that do not belong to any group (ungrouped)
  * [3] is a collapsed group tab of a group named "group1", where tab
    [4] belongs to the same group and is hidden
  * [5] and [7] are tabs that belongs to the current group (same group)
  * [6] is the current active tab

3. Add a new user option to set a default group for new tabs
('tab-line-new-tab-default-group'). When nil, the behavior is the same
of today where new tabs are ungrouped. If a string, new tabs are
assigned automatically to that group. If a function, it's called to
return the group name for the new tab. The "initial tab" is also
affected, so after setting this new user option and enabling
'tab-bar-mode', the first tab and subsequent new tabs will be assigned
to the default group.

4. Today, the group name is not copied when 'tab-bar-duplicate-tab' is
called, so the user needs to type 'C-x t n' to duplicate the tab and
'C-x t G' to set the same group name of the tab it was duplicated
from. It would be nice if 'tab-bar-duplicate-tab' could also duplicate
the group name.

5. When I first played around with tab bar groups, I created several
tabs and assigned groups to them in a non sequential order, e.g.:

 [1 group1 AAA] [2 group1 BBB] [3 CCC] [4 group1 DDD] [5 group2 EEE]

Then I noticed a "strange" behavior and thought this feature was not
working properly. After adjusting the group order so all tabs of the
same group are next to each other (e.g., setting group1 to tab 3 or
removing group1 from tab 4), it worked as expected. I don't know "if" or
"how" this specific case of non sequential group tabs should be handled,
but that's something we could clarify in the documentation.

If someone find these ideas useful, I can send patches.

Regards,
Gabriel

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> Tab Bar is awesome and the recently added features to work with tab
> groups made it even better. I know it's still a working in progress, but
> I would like to suggest some minor improvements:

Thanks for suggestions.

The current implementation is not yet finished.  It will take
a few days to polish and push remaining patches.

But you are welcome to try it out now and to make suggestions
for improvements.

> 1. Add an initial input for the 'completing-read' of
> 'tab-bar-change-tab-group', so when we type 'C-x t G' to set/unset the
> group name, the minibuffer contents is filled with the current group
> value. A possible downside is that pressing TAB may not show the
> Completions list, in case the current value does not match any item of
> the completion list provided.

Prefilling the initial contents of the minibuffer is deprecated.
This is what the documentation says about it:

     The argument INITIAL is mostly deprecated; we recommend using a
     non-‘nil’ value only in conjunction with specifying a cons cell for
     HISTORY.  For default input, use DEFAULT instead.

> 2. Add new faces for group tabs. The idea is to differentiate these 2
> cases:
>   2.1. Tabs from the current group X tabs from other groups
>   2.2. Regular tabs X collapsed group tabs

Your suggestions 3, 4, 5 are currently already under construction,
but for the suggestion 2 of adding new faces your help is needed
to design a set of new faces.  This your list could be used as a base
where new faces could be created:

> * [1], [2] and [8] are tabs that do not belong to any group (ungrouped)
> * [3] is a collapsed group tab of a group named "group1", where tab
>   [4] belongs to the same group and is hidden
> * [5] and [7] are tabs that belongs to the current group (same group)
> * [6] is the current active tab

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> 2. Add new faces for group tabs. The idea is to differentiate these 2
> cases:
>   2.1. Tabs from the current group X tabs from other groups
>   2.2. Regular tabs X collapsed group tabs
>
> It's not possible to know which tabs belongs to the current group or
> which tabs represent another group, since all inactive tabs use the same
> face 'tab-bar-tab-inactive'. I did a slight modification to
> 'tab-bar-tab-name-format-default' and 'tab-bar-tab-group-format-default'
> to add two new faces:
>
> In the example above (please desconsider the styles I used), we can see
> that:
>   * [1], [2] and [8] are tabs that do not belong to any group (ungrouped)
>   * [3] is a collapsed group tab of a group named "group1", where tab
>     [4] belongs to the same group and is hidden
>   * [5] and [7] are tabs that belongs to the current group (same group)
>   * [6] is the current active tab

While adding a new face for groups and using it instead of tab-bar-tab-inactive
is easy to do, the real problem is what to do with inactive ungrouped tabs.
To highlight them differently with some dimmed out face, we need first
to detect whether any group is already in use.  Because when groups
are not used, then displaying ungrouped tabs differently makes no sense.
Do you have an idea how to handle such case?

> 3. Add a new user option to set a default group for new tabs
> ('tab-line-new-tab-default-group'). When nil, the behavior is the same
> of today where new tabs are ungrouped. If a string, new tabs are
> assigned automatically to that group. If a function, it's called to
> return the group name for the new tab. The "initial tab" is also
> affected, so after setting this new user option and enabling
> 'tab-bar-mode', the first tab and subsequent new tabs will be assigned
> to the default group.

This is now pushed as the option 'tab-bar-new-tab-group'.

> 4. Today, the group name is not copied when 'tab-bar-duplicate-tab' is
> called, so the user needs to type 'C-x t n' to duplicate the tab and
> 'C-x t G' to set the same group name of the tab it was duplicated
> from. It would be nice if 'tab-bar-duplicate-tab' could also duplicate
> the group name.

A new let-binding '(tab-bar-new-tab-group t)' was added to 'tab-bar-duplicate-tab'.

> 5. When I first played around with tab bar groups, I created several
> tabs and assigned groups to them in a non sequential order, e.g.:
>
>  [1 group1 AAA] [2 group1 BBB] [3 CCC] [4 group1 DDD] [5 group2 EEE]
>
> Then I noticed a "strange" behavior and thought this feature was not
> working properly. After adjusting the group order so all tabs of the
> same group are next to each other (e.g., setting group1 to tab 3 or
> removing group1 from tab 4), it worked as expected. I don't know "if" or
> "how" this specific case of non sequential group tabs should be handled,

Currently the user needs to arrange tabs manually to make all group tabs
adjacent.  It's possible to do this automatically.  For example, in
Chromium-based web browsers adding the current tab to the group
changes the position of the tab to be closer to other tabs of the same group.
While it makes some sense, moving the tab without user's consent
is not a good thing to do.  Maybe this behavior of automatically moving
the tab closer to tabs of the same group could be optional?

> but that's something we could clarify in the documentation.

Please suggest where and how this could be explained in the documentation?

> If someone find these ideas useful, I can send patches.

Thanks, your patches and more ideas are highly appreciated.

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> 2. Add new faces for group tabs. The idea is to differentiate these 2
> cases:
>   2.1. Tabs from the current group X tabs from other groups
>   2.2. Regular tabs X collapsed group tabs
>
> It's not possible to know which tabs belongs to the current group or
> which tabs represent another group, since all inactive tabs use the same
> face 'tab-bar-tab-inactive'. I did a slight modification to
> 'tab-bar-tab-name-format-default' and 'tab-bar-tab-group-format-default'
> to add two new faces:
>
> In the example above (please desconsider the styles I used), we can see
> that:
>   * [1], [2] and [8] are tabs that do not belong to any group (ungrouped)
>   * [3] is a collapsed group tab of a group named "group1", where tab
>     [4] belongs to the same group and is hidden
>   * [5] and [7] are tabs that belongs to the current group (same group)
>   * [6] is the current active tab

As a first stab at tab faces, now there are 3 new faces:

- tab-bar-tab-group-current
- tab-bar-tab-group-inactive
- tab-bar-tab-ungrouped

and two new options:

- tab-bar-tab-face-function
- tab-bar-tab-group-face-function

The latter can be used for color-coding, e.g. by assigning a distinctive
color to each group of tabs.

I'm striving to make only minimal changes in the core library
and to provide enough knobs for easy customization.

Please try this to see if there is still anything missing.

Re: Some minor suggestions to Tab Bar

[Ergus]

Hi Juri:

Just a question. I have seen the new groups in tabs-bar, but I sadly
don't understand what a group means and how to use this feature as a
final user.

I evaluated:

(setq tab-bar-format
       '(tab-bar-format-history
	tab-bar-format-tabs-group
	tab-bar-separator
	tab-bar-format-add-tab))

And just a + appears in the tab-bar. So maybe you could explain some
basic steps about how to use the groups?

Best,
Ergus.


On Wed, Mar 17, 2021 at 07:46:30PM +0200, Juri Linkov wrote:
>> 2. Add new faces for group tabs. The idea is to differentiate these 2
>> cases:
>>   2.1. Tabs from the current group X tabs from other groups
>>   2.2. Regular tabs X collapsed group tabs
>>
>> It's not possible to know which tabs belongs to the current group or
>> which tabs represent another group, since all inactive tabs use the same
>> face 'tab-bar-tab-inactive'. I did a slight modification to
>> 'tab-bar-tab-name-format-default' and 'tab-bar-tab-group-format-default'
>> to add two new faces:
>>
>> In the example above (please desconsider the styles I used), we can see
>> that:
>>   * [1], [2] and [8] are tabs that do not belong to any group (ungrouped)
>>   * [3] is a collapsed group tab of a group named "group1", where tab
>>     [4] belongs to the same group and is hidden
>>   * [5] and [7] are tabs that belongs to the current group (same group)
>>   * [6] is the current active tab
>
>As a first stab at tab faces, now there are 3 new faces:
>
>- tab-bar-tab-group-current
>- tab-bar-tab-group-inactive
>- tab-bar-tab-ungrouped
>
>and two new options:
>
>- tab-bar-tab-face-function
>- tab-bar-tab-group-face-function
>
>The latter can be used for color-coding, e.g. by assigning a distinctive
>color to each group of tabs.
>
>I'm striving to make only minimal changes in the core library
>and to provide enough knobs for easy customization.
>
>Please try this to see if there is still anything missing.
>

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> Just a question. I have seen the new groups in tabs-bar, but I sadly
> don't understand what a group means and how to use this feature as a
> final user.
>
> I evaluated:
>
> (setq tab-bar-format
>       '(tab-bar-format-history
> 	tab-bar-format-tabs-group
> 	tab-bar-separator
> 	tab-bar-format-add-tab))
>
> And just a + appears in the tab-bar. So maybe you could explain some
> basic steps about how to use the groups?

Indeed, and later this should be described in the manual once
the implementation stabilizes.

To use groups, the first step is to customize 'tab-bar-format' like you did
(with a small typo, it should be plural 'tab-bar-format-tabs-groups'):

  (setq tab-bar-format
        '(tab-bar-format-history
          tab-bar-format-tabs-groups
          tab-bar-separator
          tab-bar-format-add-tab))

Then you can either define a custom function tab-bar-tab-group-function
that automatically assigns a group name to a tab depending on the buffers
displayed in the tab.  Or much simpler is to manually set a group to
the current tab by using 'C-x t G' on every existing tab in the tab bar.

Also I recommend to customize 'tab-bar-new-tab-group' to t,
so creating a new tab will inherit its group from the previous tab
(maybe its value should be t by default?):

  (setq-default tab-bar-new-tab-group t)

When the tab bar is displayed, the main purpose of tab groups is to
hide tabs from other groups, thus giving more screen space to tabs
of the currently used group.

To some extent, tab groups could be useful even when the tab bar is
not displayed.  The command tab-close-group can be used to close
all tabs of the specified group.

Re: Some minor suggestions to Tab Bar

[Gabriel]

Juri Linkov <juri@linkov.net> writes:
>
> As a first stab at tab faces, now there are 3 new faces:
>
> - tab-bar-tab-group-current
> - tab-bar-tab-group-inactive
> - tab-bar-tab-ungrouped
>
> and two new options:
>
> - tab-bar-tab-face-function
> - tab-bar-tab-group-face-function
>
> The latter can be used for color-coding, e.g. by assigning a distinctive
> color to each group of tabs.
>
> I'm striving to make only minimal changes in the core library
> and to provide enough knobs for easy customization.
>
> Please try this to see if there is still anything missing.

I tested the recent additions to tab-bar.el and everything looks great!
Works flawless and there are enough knobs for customization. I am not
sure what are good default values for the user options and faces, but
it's flexible enough to allow a long range of customizations.

I will continue to test it and let you know if I find any problem or
have any suggestion.

Re: Some minor suggestions to Tab Bar

[Zhiwei Chen]

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

`tab-bar-switch-to-next-tab` and `tab-bar-switch-to-prev-tab` should have a repeat-map property.

--
Zhiwei Chen


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

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> `tab-bar-switch-to-next-tab` and `tab-bar-switch-to-prev-tab` should have a
> repeat-map property.

Please try these settings.  If they work well, then later they
could be added to tab-bar.el:

#+begin_src emacs-lisp
(defvar tab-bar-switch-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "o" 'tab-next)
    (define-key map "O" 'tab-previous)
    map)
  "Keymap to repeat tab switch key sequences `C-x t o o O'.
Used in `repeat-mode'.")
(put 'tab-next 'repeat-map 'tab-bar-switch-repeat-map)
(put 'tab-previous 'repeat-map 'tab-bar-switch-repeat-map)

(defvar tab-bar-move-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "m" 'tab-move)
    (define-key map "M" (lambda ()
                          (interactive)
                          (tab-move -1)))
    map)
  "Keymap to repeat tab move key sequences `C-x t m m'.
Used in `repeat-mode'.")
(put 'tab-move 'repeat-map 'tab-bar-move-repeat-map)

(defvar tab-bar-undo-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "u" 'tab-undo)
    map)
  "Keymap to repeat tab undo key sequences `C-x t u u'.
Used in `repeat-mode'.")
(put 'tab-undo 'repeat-map 'tab-bar-undo-repeat-map)
#+end_src

Re: Some minor suggestions to Tab Bar

[Zhiwei Chen]

> On Mar 23, 2021, at 2:47 AM, Juri Linkov <juri@linkov.net> wrote:
> 
>> `tab-bar-switch-to-next-tab` and `tab-bar-switch-to-prev-tab` should have a
>> repeat-map property.
> 
> #+begin_src emacs-lisp
> (defvar tab-bar-move-repeat-map
>  (let ((map (make-sparse-keymap)))
>    (define-key map "m" 'tab-move)
>    (define-key map "M" (lambda ()
>                          (interactive)
>                          (tab-move -1)))
>    map)
>  "Keymap to repeat tab move key sequences `C-x t m m'.
> Used in `repeat-mode'.")
> (put 'tab-move 'repeat-map 'tab-bar-move-repeat-map)
> #+end_src

One nitpicking is that `C-x t m M m’ is not allowed since `(tab-move -1)` hasn’t a `repeat-map’ property.
Maybe name it tab-move-prev and set the property?
--
Zhiwei Chen

Repeat lambda (was: Some minor suggestions to Tab Bar)

[Juri Linkov]

>> (defvar tab-bar-move-repeat-map
>>  (let ((map (make-sparse-keymap)))
>>    (define-key map "m" 'tab-move)
>>    (define-key map "M" (lambda ()
>>                          (interactive)
>>                          (tab-move -1)))
>>    map)
>>  "Keymap to repeat tab move key sequences `C-x t m m'.
>> Used in `repeat-mode'.")
>> (put 'tab-move 'repeat-map 'tab-bar-move-repeat-map)
>
> One nitpicking is that `C-x t m M m’ is not allowed
> since `(tab-move -1)` hasn’t a `repeat-map’ property.
> Maybe name it tab-move-prev and set the property?

This can't be a general solution since there are other keymaps
where repeating lambda is required.

For example, other-window-repeat-map currently has no keybinding
that could switch to navigating windows in the opposite direction.
There were proposals to bind it to "O", but since there is no such
command as "previous-window" to cycle windows backwards,
using a lambda is required, but currently this doesn't work:

  (define-key other-window-repeat-map "O"
    (lambda ()
      (interactive)
      (other-window -1)))

Stefan already asked about this, but I had no idea
how it could be improved.  Now I tried to set
the KEEP-PRED arg of set-transient-map to t, and
it seems both lambdas above can be used with this change:

diff --git a/lisp/repeat.el b/lisp/repeat.el
index 84a613da0c..4be4f766ef 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -398,7 +398,7 @@ repeat-post-hook
             (when repeat-exit-key
               (define-key map repeat-exit-key 'ignore))
-            (set-transient-map map)))))))
+            (set-transient-map map t)))))))

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> 5. When I first played around with tab bar groups, I created several
> tabs and assigned groups to them in a non sequential order, e.g.:
>
>  [1 group1 AAA] [2 group1 BBB] [3 CCC] [4 group1 DDD] [5 group2 EEE]
>
> Then I noticed a "strange" behavior and thought this feature was not
> working properly. After adjusting the group order so all tabs of the
> same group are next to each other (e.g., setting group1 to tab 3 or
> removing group1 from tab 4), it worked as expected. I don't know "if" or
> "how" this specific case of non sequential group tabs should be handled,
> but that's something we could clarify in the documentation.

To keep all tabs of the same group next to each other,
now there is a new option tab-bar-tab-post-change-group-functions
that can be customized to tab-bar-move-tab-to-group that will move
the tab after changing its group closer to other tabs of the same group.

Re: Some minor suggestions to Tab Bar

[Gabriel]

>
> To keep all tabs of the same group next to each other,
> now there is a new option tab-bar-tab-post-change-group-functions
> that can be customized to tab-bar-move-tab-to-group that will move
> the tab after changing its group closer to other tabs of the same
> group.

This is really great! Thank you!

I did some tests and works fine. I have found one edge case,
though. Imagine these tabs, consisting of [hint group name]:

[1 g1 A] [2 g1 B] [3 g1 C] [4 g2 D] [5 g2 E] [6 g2 F]

If we go to tab 2 and unset the group or set a new group (e.g.: "g3"),
the tab will not be moved, which will split the group "g1":

[1 g1 A] [2 g3 B] [3 g1 C] [4 g2 D] [5 g2 E] [6 g2 F]

I suspect that 'tab-bar-move-tab-to-group' fails to find another tab of
the same group to move to a closer position, so it leaves the current
tab where it is, without checking if this creates a misalignment.

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

> I did some tests and works fine. I have found one edge case,
> though. Imagine these tabs, consisting of [hint group name]:
>
> [1 g1 A] [2 g1 B] [3 g1 C] [4 g2 D] [5 g2 E] [6 g2 F]
>
> If we go to tab 2 and unset the group or set a new group (e.g.: "g3"),
> the tab will not be moved, which will split the group "g1":
>
> [1 g1 A] [2 g3 B] [3 g1 C] [4 g2 D] [5 g2 E] [6 g2 F]
>
> I suspect that 'tab-bar-move-tab-to-group' fails to find another tab of
> the same group to move to a closer position, so it leaves the current
> tab where it is, without checking if this creates a misalignment.

I have no idea where to move such dangling tab :)

Re: Some minor suggestions to Tab Bar

[Gabriel]

Juri Linkov <juri@linkov.net> writes:
>
> I have no idea where to move such dangling tab :)

Is it too intrusive to move the tab to the right of the current group ?

Example:
    [1 g1 A] [2 g1 B] [3 g1 C] [4 g1 D]         [5 g2 E] [6 g2 F]
                |
                | FROM HERE
                |
                ----------------------------
                                           |
                                           | TO HERE
                                           |
    [1 g1 A]          [3 g1 C] [4 g1 D] [2 X B] [5 g2 E] [6 g2 F]

Re: Repeat lambda (was: Some minor suggestions to Tab Bar)

[Zhiwei Chen]

> On Mar 24, 2021, at 2:30 AM, Juri Linkov <juri@linkov.net> wrote:
> 
>>> (defvar tab-bar-move-repeat-map
>>> (let ((map (make-sparse-keymap)))
>>>   (define-key map "m" 'tab-move)
>>>   (define-key map "M" (lambda ()
>>>                         (interactive)
>>>                         (tab-move -1)))
>>>   map)
>>> "Keymap to repeat tab move key sequences `C-x t m m'.
>>> Used in `repeat-mode'.")
>>> (put 'tab-move 'repeat-map 'tab-bar-move-repeat-map)
>> 
>> One nitpicking is that `C-x t m M m’ is not allowed
>> since `(tab-move -1)` hasn’t a `repeat-map’ property.
>> Maybe name it tab-move-prev and set the property?
> 
> This can't be a general solution since there are other keymaps
> where repeating lambda is required.
> 
> For example, other-window-repeat-map currently has no keybinding
> that could switch to navigating windows in the opposite direction.
> There were proposals to bind it to "O", but since there is no such
> command as "previous-window" to cycle windows backwards,
> using a lambda is required, but currently this doesn't work:
> 
>  (define-key other-window-repeat-map "O"
>    (lambda ()
>      (interactive)
>      (other-window -1)))
> 
> Stefan already asked about this, but I had no idea
> how it could be improved.  Now I tried to set
> the KEEP-PRED arg of set-transient-map to t, and
> it seems both lambdas above can be used with this change:
> 
> diff --git a/lisp/repeat.el b/lisp/repeat.el
> index 84a613da0c..4be4f766ef 100644
> --- a/lisp/repeat.el
> +++ b/lisp/repeat.el
> @@ -398,7 +398,7 @@ repeat-post-hook
>             (when repeat-exit-key
>               (define-key map repeat-exit-key 'ignore))
> -            (set-transient-map map)))))))
> +            (set-transient-map map t)))))))

So there is no help message “[Repeat with o, O, ...]” displayed when use 'C-x o O’. 

Maybe we can wrap all commands in `repeat-map’ and show the help message first, then invoke the bound function?

--
Zhiwei Chen

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

>> I have no idea where to move such dangling tab :)
>
> Is it too intrusive to move the tab to the right of the current group ?
>
> Example:
>     [1 g1 A] [2 g1 B] [3 g1 C] [4 g1 D]         [5 g2 E] [6 g2 F]
>                 |
>                 | FROM HERE
>                 |
>                 ----------------------------
>                                            |
>                                            | TO HERE
>                                            |
>     [1 g1 A]          [3 g1 C] [4 g1 D] [2 X B] [5 g2 E] [6 g2 F]

I don't know.  In your original example the new group name was "g3":

[1 g1 A] [2 g3 B] [3 g1 C] [4 g2 D] [5 g2 E] [6 g2 F]

that implied it should be moved after "g2" to the end:

[1 g1 A]          [3 g1 C] [4 g2 D] [5 g2 E] [6 g2 F] [2 g3 B]

Or maybe let the user decide where to move by using explicit 'C-x t M'.

Re: Repeat lambda

[Juri Linkov]

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

>> diff --git a/lisp/repeat.el b/lisp/repeat.el
>> index 84a613da0c..4be4f766ef 100644
>> --- a/lisp/repeat.el
>> +++ b/lisp/repeat.el
>> @@ -398,7 +398,7 @@ repeat-post-hook
>>             (when repeat-exit-key
>>               (define-key map repeat-exit-key 'ignore))
>> -            (set-transient-map map)))))))
>> +            (set-transient-map map t)))))))
>
> So there is no help message “[Repeat with o, O, ...]” displayed when use 'C-x o O’.

Also I noticed another problem with using `t' for KEEP-PRED in set-transient-map:
it doesn't handle `repeat-exit-key' after every command.  So `t' can't be used.

> Maybe we can wrap all commands in `repeat-map’ and show the help
> message first, then invoke the bound function?

The problem is that currently we get `repeat-map' only from command symbol:

  (get this-command 'repeat-map)

But maybe we could allow the command to set its next repeat-map explicitly:

  (define-key map "O" (lambda ()
                        (interactive)
                        (setq repeat-map 'other-window-repeat-map)
                        (other-window -1)))

with such patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: repeat-map.patch --]
[-- Type: text/x-diff, Size: 1130 bytes --]

diff --git a/lisp/repeat.el b/lisp/repeat.el
index a2b04b81b0..5ae2ec2967 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -342,6 +342,8 @@ repeat-exit-key
   :group 'convenience
   :version "28.1")
 
+;;;###autoload (defvar repeat-map nil)
+
 ;;;###autoload
 (define-minor-mode repeat-mode
   "Toggle Repeat mode.
@@ -364,8 +366,9 @@ repeat-mode
 (defun repeat-post-hook ()
   "Function run after commands to set transient keymap for repeatable keys."
   (when repeat-mode
-    (let ((repeat-map (and (symbolp this-command)
-                           (get this-command 'repeat-map))))
+    (let ((repeat-map (or (and (symbolp this-command)
+                               (get this-command 'repeat-map))
+                          repeat-map)))
       (when repeat-map
         (when (boundp repeat-map)
           (setq repeat-map (symbol-value repeat-map)))
@@ -398,7 +401,8 @@ repeat-post-hook
             (when repeat-exit-key
               (define-key map repeat-exit-key 'ignore))
 
-            (set-transient-map map)))))))
+            (set-transient-map map))))))
+  (setq repeat-map nil))
 
 (provide 'repeat)
 

Re: Repeat lambda

[Juri Linkov]

> But maybe we could allow the command to set its next repeat-map explicitly:
>
>   (define-key map "O" (lambda ()
>                         (interactive)
>                         (setq repeat-map 'other-window-repeat-map)
>                         (other-window -1)))
>
> with such patch:

This is pushed now in 15de559d98.

Additionally, there is a new option 'repeat-keep-prefix' to keep the
prefix arg of the previous command.  For example, this can help to
reverse direction with e.g. 'C-x o M-- o o'.  Also it can help to set
a new step e.g. 'C-x { C-5 { { {' or 'C-5 C-x { { {' will set the
window resizing step to 5.

Re: Some minor suggestions to Tab Bar

[Juri Linkov]

>> On Mar 23, 2021, at 2:47 AM, Juri Linkov <juri@linkov.net> wrote:
>> 
>>> `tab-bar-switch-to-next-tab` and `tab-bar-switch-to-prev-tab` should have a
>>> repeat-map property.
>> 
>> #+begin_src emacs-lisp
>> (defvar tab-bar-move-repeat-map
>>  (let ((map (make-sparse-keymap)))
>>    (define-key map "m" 'tab-move)
>>    (define-key map "M" (lambda ()
>>                          (interactive)
>>                          (tab-move -1)))
>>    map)
>>  "Keymap to repeat tab move key sequences `C-x t m m'.
>> Used in `repeat-mode'.")
>> (put 'tab-move 'repeat-map 'tab-bar-move-repeat-map)
>> #+end_src
>
> One nitpicking is that `C-x t m M m’ is not allowed since `(tab-move -1)` hasn’t a `repeat-map’ property.
> Maybe name it tab-move-prev and set the property?

These repeat maps are pushed as well in c049c8da58.

Re: Some minor suggestions to Tab Bar

[Zhiwei Chen]

>>> #+begin_src emacs-lisp
>>> (defvar tab-bar-move-repeat-map
>>> (let ((map (make-sparse-keymap)))
>>>   (define-key map "m" 'tab-move)
>>>   (define-key map "M" (lambda ()
>>>                         (interactive)
>>>                         (tab-move -1)))
>>>   map)
>>> "Keymap to repeat tab move key sequences `C-x t m m'.
>>> Used in `repeat-mode'.")
>>> (put 'tab-move 'repeat-map 'tab-bar-move-repeat-map)
>>> #+end_src
>> 
>> One nitpicking is that `C-x t m M m’ is not allowed since `(tab-move -1)` hasn’t a `repeat-map’ property.
>> Maybe name it tab-move-prev and set the property?
> 
> These repeat maps are pushed as well in c049c8da58.


Thanks!

--
Zhiwei Chen

Re: Repeat lambda

[Ergus]

Hi Juri:

Now playing with the repeat mode I have a small issue.

I see that You bind `C-x u` as a repeat command, but in my case I have
undo-only. The repeat transient map still uses the normal undo BUT maybe
there is a "simple" method (in the user config of course) to make u u u
use the undo-only and (as a plus) make r r r to do undo-redo?

I suppose that this only needs some define-key like below?

Best, and thanks in advance,
Ergus

On Tue, Apr 06, 2021 at 12:03:44AM +0300, Juri Linkov wrote:
>> But maybe we could allow the command to set its next repeat-map explicitly:
>>
>>   (define-key map "O" (lambda ()
>>                         (interactive)
>>                         (setq repeat-map 'other-window-repeat-map)
>>                         (other-window -1)))
>>
>> with such patch:
>
>This is pushed now in 15de559d98.
>
>Additionally, there is a new option 'repeat-keep-prefix' to keep the
>prefix arg of the previous command.  For example, this can help to
>reverse direction with e.g. 'C-x o M-- o o'.  Also it can help to set
>a new step e.g. 'C-x { C-5 { { {' or 'C-5 C-x { { {' will set the
>window resizing step to 5.
>

Re: Repeat lambda

[Zhiwei Chen]

According to other-window-repeat-map:

(defvar other-window-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "o" 'other-window)
    (define-key map "O" (lambda ()
                          (interactive)
                          (setq repeat-map 'other-window-repeat-map)
                          (other-window -1)))
    map)
  "Keymap to repeat other-window key sequences.  Used in `repeat-mode'.")
(put 'other-window 'repeat-map 'other-window-repeat-map)

It can be done in a lambda that set `repeat-map’.

> On Apr 12, 2021, at 7:40 AM, Ergus <spacibba@aol.com> wrote:
> 
> Hi Juri:
> 
> Now playing with the repeat mode I have a small issue.
> 
> I see that You bind `C-x u` as a repeat command, but in my case I have
> undo-only. The repeat transient map still uses the normal undo BUT maybe
> there is a "simple" method (in the user config of course) to make u u u
> use the undo-only and (as a plus) make r r r to do undo-redo?
> 
> I suppose that this only needs some define-key like below?
> 
> Best, and thanks in advance,
> Ergus
> 
> On Tue, Apr 06, 2021 at 12:03:44AM +0300, Juri Linkov wrote:
>>> But maybe we could allow the command to set its next repeat-map explicitly:
>>> 
>>>  (define-key map "O" (lambda ()
>>>                        (interactive)
>>>                        (setq repeat-map 'other-window-repeat-map)
>>>                        (other-window -1)))
>>> 
>>> with such patch:
>> 
>> This is pushed now in 15de559d98.
>> 
>> Additionally, there is a new option 'repeat-keep-prefix' to keep the
>> prefix arg of the previous command.  For example, this can help to
>> reverse direction with e.g. 'C-x o M-- o o'.  Also it can help to set
>> a new step e.g. 'C-x { C-5 { { {' or 'C-5 C-x { { {' will set the
>> window resizing step to 5.
>> 

Re: Repeat lambda

[Juri Linkov]

> I see that You bind `C-x u` as a repeat command, but in my case I have
> undo-only. The repeat transient map still uses the normal undo BUT maybe
> there is a "simple" method (in the user config of course) to make u u u
> use the undo-only and (as a plus) make r r r to do undo-redo?
>
> I suppose that this only needs some define-key like below?

Maybe something like this:

#+begin_src emacs-lisp
(defvar undo-redo-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "u" 'undo-only)
    (define-key map "r" 'undo-redo)
    map)
  "Keymap to repeat undo-redo key sequences.  Used in `repeat-mode'.")
(put 'undo-only 'repeat-map 'undo-redo-repeat-map)
(put 'undo-redo 'repeat-map 'undo-redo-repeat-map)
#+end_src

Re: Repeat lambda

[Juri Linkov]

>> I see that You bind `C-x u` as a repeat command, but in my case I have
>> undo-only. The repeat transient map still uses the normal undo BUT maybe
>> there is a "simple" method (in the user config of course) to make u u u
>> use the undo-only and (as a plus) make r r r to do undo-redo?
>>
>> I suppose that this only needs some define-key like below?

Since there is no key to initiate an undo-redo sequence,
re the comment in bindings.el:

  ;; Richard said that we should not use C-x <uppercase letter> and I have
  ;; no idea whereas to bind it.  Any suggestion welcome.  -stef
  ;; (define-key ctl-x-map "U" 'undo-only)

Maybe 'C-x u u' could start such key sequence with the command 'undo',
then 'r' could switch to a different keymap
where 'r' is bound to 'undo-redo' and 'u' to 'undo-only'.
Perhaps such heuristics makes sense that once the user typed 'r',
the next 'u' should do 'undo-only'?

#+begin_src emacs-lisp
(defvar undo-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "u" 'undo)
    (define-key map "r" 'undo-redo)
    map)
  "Keymap to repeat undo key sequences `C-x u u'.  Used in `repeat-mode'.")
(put 'undo 'repeat-map 'undo-repeat-map)

(defvar undo-redo-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "r" 'undo-redo)
    (define-key map "u" 'undo-only)
    map)
  "Keymap to repeat undo-redo key sequences.  Used in `repeat-mode'.")
(put 'undo-redo 'repeat-map 'undo-redo-repeat-map)
(put 'undo-only 'repeat-map 'undo-redo-repeat-map)
#+end_src

Re: Repeat lambda

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1879 bytes --]

Juri Linkov <juri@linkov.net> writes:


You can do all this with a few lines of hydra,
a undo/redo hydra that gets launched with C-x u, and then  -- u and U
trigger the two heads in the hydra.
>>> I see that You bind `C-x u` as a repeat command, but in my case I have
>>> undo-only. The repeat transient map still uses the normal undo BUT maybe
>>> there is a "simple" method (in the user config of course) to make u u u
>>> use the undo-only and (as a plus) make r r r to do undo-redo?
>>>
>>> I suppose that this only needs some define-key like below?
>
> Since there is no key to initiate an undo-redo sequence,
> re the comment in bindings.el:
>
>   ;; Richard said that we should not use C-x <uppercase letter> and I have
>   ;; no idea whereas to bind it.  Any suggestion welcome.  -stef
>   ;; (define-key ctl-x-map "U" 'undo-only)
>
> Maybe 'C-x u u' could start such key sequence with the command 'undo',
> then 'r' could switch to a different keymap
> where 'r' is bound to 'undo-redo' and 'u' to 'undo-only'.
> Perhaps such heuristics makes sense that once the user typed 'r',
> the next 'u' should do 'undo-only'?
>
> #+begin_src emacs-lisp
> (defvar undo-repeat-map
>   (let ((map (make-sparse-keymap)))
>     (define-key map "u" 'undo)
>     (define-key map "r" 'undo-redo)
>     map)
>   "Keymap to repeat undo key sequences `C-x u u'.  Used in `repeat-mode'.")
> (put 'undo 'repeat-map 'undo-repeat-map)
>
> (defvar undo-redo-repeat-map
>   (let ((map (make-sparse-keymap)))
>     (define-key map "r" 'undo-redo)
>     (define-key map "u" 'undo-only)
>     map)
>   "Keymap to repeat undo-redo key sequences.  Used in `repeat-mode'.")
> (put 'undo-redo 'repeat-map 'undo-redo-repeat-map)
> (put 'undo-only 'repeat-map 'undo-redo-repeat-map)
> #+end_src
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Repeat lambda

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Maybe 'C-x u u' could start such key sequence with the command 'undo',
  > then 'r' could switch to a different keymap
  > where 'r' is bound to 'undo-redo' and 'u' to 'undo-only'.
  > Perhaps such heuristics makes sense that once the user typed 'r',
  > the next 'u' should do 'undo-only'?

C-x u is the recommended key sequence for novices to undo.
Please do not make it more complex in any way.
It would trip them up!

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: peat lambda

[Kévin Le Gouguec]

Richard Stallman <rms@gnu.org> writes:

> C-x u is the recommended key sequence for novices to undo.
> Please do not make it more complex in any way.
> It would trip them up!

AFAIU the change under discussion would be opt-in, by enabling the new
repeat-mode.  Novices would not suffer from the added complexity unless
they felt comfortable exploring this feature and deliberately turned it
on, IIUC.

Re: Repeat lambda

[Kévin Le Gouguec]

> Subject: Re: peat lambda

(Yikes, sorry for mangling the subject field; it seems my
message-subject-re-regexp has grown a tad overzealous)

Re: Repeat lambda

[Juri Linkov]

> You can do all this with a few lines of hydra,
> a undo/redo hydra that gets launched with C-x u, and then  -- u and U
> trigger the two heads in the hydra.

Unlike the hydra with heads, the repeat maps are more like
a maze of twisty passages.

Re: Repeat lambda

[Juri Linkov]

>   > Maybe 'C-x u u' could start such key sequence with the command 'undo',
>   > then 'r' could switch to a different keymap
>   > where 'r' is bound to 'undo-redo' and 'u' to 'undo-only'.
>   > Perhaps such heuristics makes sense that once the user typed 'r',
>   > the next 'u' should do 'undo-only'?
>
> C-x u is the recommended key sequence for novices to undo.
> Please do not make it more complex in any way.
> It would trip them up!

Then additional keybindings could be left up to personal customization,
so e.g. after activating undo repeating mode with 'C-x u', 'C-z' and 'C-y'
could be used to browse the undo history with 'C-x u C-z C-z ... C-y C-y ...'
after such customization:

  (define-key undo-repeat-map (kbd "C-z") 'undo-only)
  (define-key undo-repeat-map (kbd "C-y") 'undo-redo)

Re: Repeat lambda

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Then additional keybindings could be left up to personal customization,
  > so e.g. after activating undo repeating mode with C-x u

Since C-x u is the recommended way for neophytes to undo, we should
not add any complexity to it.  Please do not redefine it to enter some
sort of mode.  Please leave it alone.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: peat lambda

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > AFAIU the change under discussion would be opt-in, by enabling the new
  > repeat-mode.  Novices would not suffer from the added complexity unless
  > they felt comfortable exploring this feature and deliberately turned it
  > on, IIUC.

That makes a big difference.  If that is the case, then I have no
objection.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)