Context

I am used to apply a scale factor (.7) to line-number-face. But enabling spacious-padding overwrite this customization. Is there any way to preserve such customization?

Using the new emacs' 29 alfa-background to set the opacity of only the background, the padding remains with a solid color.

Steps to reproduce:
On Emacs 29 add this line to init.el:
(set-frame-parameter nil 'alpha-background 50)

See here:

But with the mode enabled, those are missing?

Hey @protesilaos, thank you for this amazing package.

Problem happens only when using emacs server and it doesn't occur when I start emacs without running a server.

Screenshots

Specifications

• GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0)
• Archlinux (I use the Guix package manager for Emacs.).
• KDE Plasma 6 Wayland.

Hello,

thanks so much for your work on this and other very beautiful packages (like ef-themes)!

I've notice a small issue on starting up with emacsclient. Steps:

Save the following as .emacs.d/init.el:

(push "~/my/path/to/spacious-padding/" load-path)
(require 'spacious-padding)
(spacious-padding-mode 1)
(define-key global-map (kbd "<f8>") #'spacious-padding-mode)

Call emacsclient -c -a "".

Note the issues in the modeline. Others also become visible on splitting the window with C-x 3.

After we press f8 twice to toggle off and on again, the issues have gone away.

Thanks for the nice package, @protesilaos!
I use it to have some margin at the top for my webcam and it works nicely.
I only get the following error message and I have no clue why I get it.
Can you help me fix it? I think the problem is a comma between each key and value, but I am not sure.

face-spec-set-2: Invalid face box: :line-width, 0, :color, "#002630", :style, nil

Hello,

I would like to know if the following is intended, I believe it is not.

First, I start with emacs -Q.

Then, if I evaluate (describe-face 'mode-line), the following is set by default, that's Emacs default mode-line:

Foreground: black
Background: grey75
Box: (:line-width -1 :style released-button)

(Everything else is unspecified.)

Then I evaluate the following:

(package-initialize)
(spacious-padding-mode 1)

The padding kicks in, like I would expect, but the mode-lines background color turns white, with a grey thick border. If I re-evaluate (describe-face 'mode-line), I now get the following:

Foreground: unspecified
Background: unspecified
Box: (:line-width 6 :color grey75 :style nil)

Why did spacious-padding-mode changed the appearance of the mode-line like this (more precisely, why did it change the Foreground and Background colors)? The manual, at 1.2, says:

By default, ‘spacious-padding-mode’ does not refashion the mode lines
other than adding to them some extra padding (see Set the exact
spacing values).

That's what I would have expected, so shouldn't the mode-line have remained with a "grey75" background...?

If then I evaluate (spacious-padding-mode -1), and (describe-face 'mode-line), everything is now "unspecified", and the background of mode-lines remain white.

Strangely, if I re-evaluate (spacious-padding-mode 1) again, now the mode-lines get a black border...! And the (describe-face 'mode-line) now says that "Foreground" and "Background" are still unspecified, while "Box" is now "(:line-width 6 :color white :style nil)" (while it appears black!).

In other words, how come is Spacious Padding changing the mode lines foreground and background colors? Shouldn't it simply modify the padding (thus the mode-lines borders)?

I am using:

GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0) on Arch Linux

Configured using:
'configure --with-pgtk --with-native-compilation=aot
--sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib
--with-tree-sitter --localstatedir=/var --with-cairo
--disable-build-details --with-harfbuzz --with-libsystemd
--with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
-fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat
-Werror=format-security -fstack-clash-protection -fcf-protection -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
-Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto'
'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto''

Thanks a lot for your support and great packages!

I was wondering whether it is possible to have instead of :internal-border-width also e.g. :top-border-width. Then only a margin at the top border is applied.

In my case I am using sketchybar and in full-screenmode the Emacs window is "behind" the sketchybar. It would be totally sufficient only to have a margin on top.

Great work with this and the other packages!

Hello,

I encountered an issue using spacious-padding along doom emacs.

I was trying the following use-package declaration:

(use-package spacious-padding
  :config
  (setq spacious-padding-widths
        '(:internal-border-width 15
          :header-line-width 4
          :mode-line-width 6
          :tab-width 4
          :right-divider-width 15
          :scroll-bar-width 8
          :fringe-width 8))
  (spacious-padding-mode)

But when starting doom, the paddings where not visible.
I had to M-x spacious-padding-mode again for them to display as expected.

The thing that I finally understood is that there is a hook that mess with spacious-padding.

I had to add the following expression to my use-package declaration:
(remove-hook 'doom-init-ui-hook #'window-divider-mode)

With this it works as expected.

I am documenting this just in case someone else encounter the same behavior.

Great job with this extension! The only issue is that it is not compatible with tabs, as you can see in this image:

Is there any way around this?
Thanks!

Hej @protesilaos

I am trying to put spacious padding to use because I find it gorgeous and cleverly simple. However, I run into the problem that whenever I activate spacious-padding-mode, a good chunk of my tab-bar-mode tabs is concealed up to the point that I cant decipher the writing anymore.

Whereas in your 2023-11-15 presentation blog post, spacious-padding-mode and tab-bar-mode go along nicely, I run into this problem both with emacs -Q and with my full configuration.

emacs -Q

full configuration

I am on openSUSE Tumbleweed GNOME, with all parts up-to-date (OS, emacs, spacious-padding).

I fear that this bug is kind of specific to GNOME, because when I change to IceWM (which is bundled with GNOME on openSUSE), I don't run into this problem.

Is anyone able to reproduce this issue with a window manager other than GNOME? Because otherwise, I suppose I'd have to report to GNOME, right?

Have a good day!

EDIT: It seems like GNOME Xorg does not have this problem, unlike GNOME Wayland I am using under normal circumstances. Well well, things get more specific, dont they :D

Hi Prot,

Spacious-Padding is great! But when I turn the mode on, the border around my mode-line disappears. I'm using modus-operandi-tinted.

Thanks for looking into this!

Best regards,

Titus

P.S.: Using Spacious-Padding version: 0.3.0 and Emacs version 30.0.50.

Hello Protesilaos,

first of all thank you for this package, I really like the aesthetic changes it allows.

While working on my configuration I found a condition that perhaps should be addressed (in the code or the documentation).

Reading the docstring for spacious-padding-widths I thought that it was not required to specify all the elements in the new plist. For example, at a certain point it says (emphasys added by me):

The more specific keys :left-fringe-width and :right-fringe-wdith can be used for finer control.

I extended this and interpreted the instructions as they were saying that all keys are optional, and somehow defaults are enforced for those not specified.

But, elsewhere in the code:

Since I initially didn't specify a value for :right-divider-width, the call to plist-get returns NIL, which > does not like.

I think there should be a guard, a default value, or a note in the docstring specifying what values are mandatory.

Hi, thank you for this wonderful package. I find the following bug: fringe is always the same color as the default background. It does not consider the background of buffer-face-mode-face. Any idea to fix this?

I use the theme doom-gruvbox from doom-themes which provides an option to pad the mode-line doom-gruvbox-padded-modeline.

"If non-nil, adds a 4px padding to the mode-line. Can be an integer to
determine the exact padding."

With spacious padding on, this border in made invisible by changing the box color to the background color. to my knowledge this would effect anyone's mode-line that has a box around text face attribute and is not a doom theme specific issue.

sorry my screenshot tool can only take inactive screenshots it seems.

Context

When running a shell command that write to standard output, the buffer scrolls but the cursor stays invisible, hidden by the resized modeline (See the small pink rectangle on the shared screenshot).

I want to make clear that I am a novice and was setting up emacs from ground up with the help of forums and guides. I am using spacious padding so Emacs looks less cramped and more spacious. And I am actually very satisfied with the result, but the issue is, when I open a new instance of emacs, the padding is oriented for full screen res rather than the window size.

Emacs when booting up:

Emacs after resizing/using a C-x or M-x command:

Could this be an issue of my window manager (herbstluftwm+xfce) or is it a issue with emacs? I can understand that this issue is very superficial and trivial, but I would love to resolve this little untied knot.

Cheers :)