Subject: Re: bug#73728: 29.3; Specifing an --alternate-editor for emacscleintw.exe with custom --init-directory does not work on Windows

From: Eli Zaretskii <[email-masked]>
Date: Thu, 10 Oct 2024 16:23:12 +0300

> Date: Thu, 10 Oct 2024 14:32:30 +0200
> From: Jonas Großekathöfer <[email-masked]>
> Cc: [email-masked]
> 
>  Can you explain why you need a custom --init-directory in that case?
>  
> Quality of life improvement: I have my configs online in a git-repo. I manage the dotfiles on my Linux machine
> with stow. On my Windows machine I want Emacs to follow that structure. As such I want to link to the config
> via --init-directory, so that I can place the Dotfiles-Folder where ever I want. However, I can't place the
> Dotfiles folder so, that the ".emacs.d/"-folder ends up under the parent "~/" as well.

Then you need to be aware that --init-directory does NOT replace your
user home directory for all purposes.  See the description of what
this does in the Emacs user manual for details.

> I already tried a route via tangling to different targets for Linux and Windows. But that introduced other
> problems... so I decided to follow this route. Seems the most straightforward to me actually. For the start I
> decided to place it under "~/" on Windows as well. As such I ended up with that specific location. But AFAICT
> my problem is location agnostic.
>  
> I am open to suggestions if I am missing the super obvious solution here. (:

Why not load a specific file from your usual .emacs instead?  If that
avoids the need to quote stuff in complex ways, it's a net win for
you.

>  Don't use single quotes, they are not supported by Windows.
> 
>  But I admit I don't understand why you needed nested quotes at all.
>  What happens if you use double quotes around the entire argument of
>  the -a option?
> 
>  
> Do you mean like how in the first example I gave?
>  
> -a "%UserProfile%\bin\emacs-29.3\bin\runemacs.exe --init-directory %AppData%\Dotfiles\emacs\.emacs.d\"
>  
> That one gives "file name or Argument required. Try --help"

First, remove the last backslash before the closing quote" it prevents
the closing quote from being recognized.  And if that doesn't help,
maybe we have a real bug.