Commit Graph

8 Commits

Author SHA1 Message Date
Johannes Altmanninger
746e0d032f rc windowing: allow to configure windowing system and window placement in new/terminal commands
Today I can control "terminal" and "new" by changing the terminal
alias but I always need to choose a concrete implementation, like
"tmux-terminal-horizontal", even when there is otherwise no need to
mention tmux in my config.

Allow to configure windowing system and window placement independently
by introducing dedicated options.

This allows to create mappings that work in any windowing system like

	map global user c   %{:with-option windowing_placement window new<ret>}
	map global user '"' %{:with-option windowing_placement vertical new<ret>}
	map global user '%' %{:with-option windowing_placement horizontal new<ret>}

For windowing systems that don't support all placements, you can wrap
the above in try/catch to fall back on the "window" variant which is
defined for all windowing systems.

When using multiple (nested) windowing systems, you might want to
add mappings like

	map global user t %{:with-option windowing_module tmux new<ret>}
	map global user T %{:with-option windowing_module wayland new<ret>}

---

This changes the default "terminal" alias for some modules. In
particular, instead of delegating to

    iterm-terminal-vertical
    screen-terminal-vertical
    tmux-terminal-horizontal
    wezterm-terminal-vertical

it will now by default delegate to the respective "-window" variant.
We could maintain backwards compatiblity here by setting the
"windowing_placement" option accordingly, but the new behavior seems
more logical?

Also, this removes the "terminal-tab" alias which was only defined
by the kitty module.

We could try to keep the alias approach and implement a "with-alias"
command, however that approach can only capture both dimensions
(windowing system and placement) if we add tons of commands
like "terminal-horizontal" (with implied windowing system) and
"tmux-terminal" (with implied placement).

Side thought: we could also get rid of the "focus" alias and instead
define

    define-command focus %{
        "%opt{windowing_module}-focus"
    }

Closes #3943, #4425
2023-11-13 22:54:49 +01:00
Maxime Coste
4106791adc Fix windowing detection echoing last module error if none matched
Display a more general message in the debug buffer.
2023-06-13 17:08:42 +10:00
Bob Qi
b64dce3e95 rc/windowing/wezterm.kak 2023-06-09 15:43:07 +08:00
Bob
4ff5de6273 Create zellij.kak 2023-02-22 13:17:04 +08:00
DixiE
0048e9f488 Support focus Within Sway WM
While Wayland offers nothing general to help us support `focus` on all
window managers, WM-specific implementations are generally possible.
Sway is a tiling window manager that mimics i3, and has a reasonably
powerful CLI that can help us achieve this.

In addition to supporting `focus` for Sway, this change paves the way
for additional WM-specific Wayland functionality by adding a detection
step to wayland.kak, in a similar fashion to detection.kak.
2022-06-02 10:57:28 +01:00
Taupiqueur
3fe4367ce0 Fix windowing detection priority 2021-06-21 16:05:09 +02:00
Reed Wade
feab20260a
Permit usage on wayland environments.
Some wayland wm will not setup a DISPLAY environment variable. Kakoune
should allow x11 windowing toolkit for those wm also.
2021-03-21 13:41:40 +01:00
Simon Fowler
b875a1802c Implement smarter detection of windowing environments.
This patch centralises the loading of windowing environments, in order
to ensure that by default only a single module is loaded, rather than
the current code which can load multiple potentially incompatible
modules; and in order to provide the user with more control over the
loading of windowing modules.

The patch introduces a new str-list option `windowing_modules` which
defines an ordered list of windowing modules to attempt to load. Modules
are loaded in the order specified in the list until a module loads
without error, at which point the process finishes.

When loaded each windowing module tests the environment to determine
whether it should load (e.g. the tmux module tests to see if it's being
run within a tmux session), and if it determines that it should then it
completes its loading without error. If it doesn't detect an appropriate
environment then it returns an error, and the module loading logic tries
the next module.

The user can override the default `windowing_modules` list to specify
their preferred modules (i.e. they can put kitty ahead of tmux if that's
their preference, or they can leave out the x11 modules alltogether). In
addition, if the `windowing_modules` option is an empty list this
bypasses the environment detection logic completely, and allows the
modules to be loaded manually - this allows a user to replace the
windowing module loading logic with their own manual set up.
2020-07-05 22:48:31 +10:00