spacemacs icon indicating copy to clipboard operation
spacemacs copied to clipboard

[Feature] "out of the box" Cross platform/host configuration support.

Open timoc opened this issue 2 years ago • 4 comments

Hi,

I am coming back to Emacs after a few years, and i have been trying, for some time, to get spacemacs and tramp working with windows and linux. After all of my digging, googling, and research to try and fix this, I find i am beginning to litter my .spacemacs configuration with things like:

  (when (eq window-system 'w32)  
             (setq-default shell-default-term-shell "c:/Windows/System32/bash.exe"))

To be clear, spacemacs and tramp does not seem to work 'out of the box' on a modern windows system. The whole experience of setting up a fundamental feature like tramp and shells in a single cross platform configuration has soured me a bit to spacemacs. It seemed to me that the whole design philosophy for spacemacs was about reasonable configuration defaults (from the community) lowering the overhead of setting up and running emacs everywhere the community does - an assumption which i hoped would make my life easier at this stage.

So my "feature request", as such, is to formalise the way that host specific configuration works in a cross platform scenario so that it can be captured and shared. Maybe this is already in place? if it is, i cannot find any clear documentation no how to use it.

My emacs-foo is a bit old, but i am thinking about something like conditional layer loading of +os 'defaults' layers based on system-type and windows-system. With corresponding changes to (defun dotspacemacs/layers () and/or (defun dotspacemacs/user-env () , to allow hooks to tweak them.

The .spacemacs.env stuff would also need to be adjusted to he host specific or cross platform. Possibly also something like (defun dotspacemacs/user-env/<hostname> (), (defun dotspacemacs/user-env/<system environmental variable=value> (), and (defun dotspacemacs/user-env/<binary to test path for> (binary-available t) etc.

The ideal scenario as i see it, is that host specific configurations follow the current design approach. All i should need to do is create a dotspacemacs function in my spacemacs file to capture changes needed for a specific environment. I should never have to write and maintain any code in a configuration file, especially when it comes to testing for the system type, hostname, environmental variables, binary availability etc, when tweaking my spacemacs configuration for a given host.

timoc avatar May 12 '22 12:05 timoc

To be clear, spacemacs and tramp does not seem to work 'out of the box' on a modern windows system.

Windows is hard to use and support.

For a specific example, you used bash as default shell, but in general there's no bash installed on Windows.

lebensterben avatar May 12 '22 15:05 lebensterben

I take it as good sign that the Emacs user base is growing. And this is not to deter yourself or others from working on cross platform support (I would be happy to help in testing), but in the off chance you haven't considered Windows 11 WSLg: I can say my experience of using WSLg has been the path of least resistance. I've got about 1 1/2 years of Spacemacs on WSLg and have yet to run into window-specific issues/ having to work around leaky abstractions. There was some initial configuration woes in Windows 10 WSL2 related to graphics display, but I digress. Microsoft has been doing solid work with WSLg.

BenedictHW avatar May 12 '22 17:05 BenedictHW

I take it as good sign that the Emacs user base is growing. And this is not to deter yourself or others from working on cross platform support (I would be happy to help in testing), but in the off chance you haven't considered Windows 11 WSLg: I can say my experience of using WSLg has been the path of least resistance. I've got about 1 1/2 years of Spacemacs on WSLg and have yet to run into window-specific issues/ having to work around leaky abstractions. There was some initial configuration woes in Windows 10 WSL2 related to graphics display, but I digress. Microsoft has been doing solid work with WSLg.

Its a work system, so i have no choice in the OS version. But to be honest, the issue still stands. In all of the years i have used emacs, and carried my config-files, from version to version, os to os, system to system, place to place, all i have found is that everyone still has to hand roll any cross platform compatibility abstractions. I come back to try emacs/spacemacs after 4 years, and it is still the case.

timoc avatar May 13 '22 14:05 timoc

To be clear, spacemacs and tramp does not seem to work 'out of the box' on a modern windows system.

Windows is hard to use and support.

For a specific example, you used bash as default shell, but in general there's no bash installed on Windows.

I think you are missing the point of the feature. I should not have to set a shell for windows, especially for a feature like tramp to work. I, as someone who has already climbed some of the emacs learning curve, should only need to spin up spacemacs (or emacs for that matter) on any given platform and type ctrl+x ctrl+f /ssh:user@host:/path/to/file/i/need/to/edit/right/now! to get stuff done.

Openssh tools etc. are available on any windows system you can install a modern powershell on - including powershell 'remoting' (an ssh like feature) to other windows boxen. As for bash on windows, as far as i know, there are only a few commonly used 'out of the box' bash environments (which can be tested for):

  1. Windows 10 bash shell which has been around since 2018 - the one in the config shown above
  2. cygwin bash
  3. git-bash (cygwin based) from the windows git installer.
  4. 'Windows System for Linux' shell - running in a local (Ubuntu 20) container, which is the same as point 1, but could also be fish or whatever.

timoc avatar May 13 '22 14:05 timoc

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

github-actions[bot] avatar May 13 '23 15:05 github-actions[bot]