|
|
|
|
|
|
by codemac
3841 days ago
|
|
|
> For example, file-name completion (the tab key) in shell mode in Emacs has been programmed to use the backslash character to escape, e.g., spaces in file names (which are part of the base system on OS X). But rc does not grok the backslashes: it uses a different convention to quote characters like spaces, and no one as far as I have been able to discover has modified shell mode to use rc's convention. It's quoting is it's power! And I fixed shell-mode in emacs for myself with the following: https://github.com/codemac/config/blob/master/emacs.d/boot.o... The remaining function to fix is comint-quote-filename - of which you'll see commented out there. It's slightly different from the shell-quote-command override in that it needs to only be enabled during shell-mode and it needs to know when to skip quoting all together. Don't fear, I'll try to get it working and send it to you (and on my github). I truly enjoy rc and emacs simultaneously, so hopefully any discoveries I make can help you if you'd like them. If not - it sounds like you want to switch to eshell anyways, which could be great (albeit will have bad things as well as it doesn't support i/o redirection). |
|
|
That would be welcome.
And you've guessed wrong about my wanting to switch to eshell.el: I took a fairly long look at eshell.el, but adopted shell.el instead. After about 5 years of using shell.el, I wrote my own mode for running and capturing the output of command lines, which I have been happily using for the last 9 months.
Like shell.el, my mode relies on a traditional shell like bash or rc to parse the command lines entered into it.
Although I do want to learn how to use Emacs Lisp code to parse the command lines I write, when I do, I'll probably just turn most of those parse trees right back into command lines (i.e., strings) and pass them to rc, bash or dash.
Once I have the ability to quickly modify my Emacs to intercept the occasional command line before it is passed to a traditional shell, in other words, I will probably feel like I have all the control I need over my relationship with the somewhat unruly beast that is the traditional Unix shell and will not feel the need or desire for the code I wrote to actually stop sending command lines to it. I'm not one for making larger changes to my software environment than necessary.
If I could figure out which of the over 13,600 lines of code that is eshell.el is responsible for parsing command lines, I'd use that, but my experience with eshell.el leads me to believe that it will probably be quicker and easier for me just to write code from scratch.