#emacs tramp

[mentalisttraceur-software]

Tonight, I've put the last finishing touch of functionality on my partial-save and partial-revert functions in Emacs: they now work over TRAMP.

And in particular, they work locally on files remotely accessed over TRAMP. That is to say, the temporary files/directories get created locally, and the "git" CLI and my "gp" wrapper script run on my device where I'm running Emacs.

So if I use TRAMP to open a file on some server/router/whatever, even if I'm accessing that box for the first time without any opportunity to install Git or my scripts on it, my partial save and revert will "just work". (A lesser benefit is that I don't have to worry about the security of temporary files on the remote.)

(The actual change to do this was trivial. My diff-unsaved-changes function, which also uses the "git" CLI to provide a diff, has worked over TRAMP like this for months, and the pattern only needed to change slightly for partial save and revert. This isn't an impressive feat - it's just a happy conclusion to a 3-4 day story.)

[writeformyself]

How did I go so long using emacs without ever even trying Tramp? I'm sure it was because I though it would be a big hassle and maybe it was in the past, but it really did work transparently for me. I opened a file on my work computer from my laptop at home and it just worked!

Now, will I use this regularly? Probably not, since nearly everything I do is under version control and I can just use git to push and pull copies around, but occasionally it'll be handy. I finally tried it out when I just wanted to copy a couple lines from a configuration file on my work machine so I could replicate the setup on my laptop at home.

[piratesexmachine420]

I love you emacs i love you M-x i love you M-: i love you C-h i love you C-x SPC i love you magit i love you org-mode i love you eshell i love you *scratch* i love you C-x b i love you M-q i love you M-x add-file-local-variable-prop-line i love you C-x 8 RET i love you calc i love you customize i love you elisp i love you TRAMP i love you dired i love you artist-mode i love you DocView i love you C-x 2 and C-x 3 i love you C-x r m and C-x r b i love you dunnet i love you indent-region i love you comment-region i love you LSP i love you MELPA i love you defun and add-hook and progn i love you C-x ( C-x ) C-x e i love you C-x z i love you recentf i love you M-x man i love you emacsclient i love you M-g g i love you describe-char i love you customize i love you zone i love you M-w and C-w and C-y i love you C-x u i love you C-g i love you eww i love you emacs i love you i love you

[mentalisttraceur-incomplete]

Learn Emacs?

I think Emacs is something best learned on the side, as a platform - as a programming language, a REPL for that language, a set of libraries, a framework for making GUIs (primarily but not exclusively text-oriented ones), and a package ecosystem. But you should not actually try to use it as your primary text editor, or even learn it as such. If you're like me, you'll spread this journey out in many little tries over many years, and that's fine.

Try the goodies built into Emacs that are not text editing. Try dired. Try eshell. Install Magit and try that. Maybe install and try a preconfigured bundle of config and packages like Spacemacs, not to grow into it but just to see what it's like. Try some Org mode stuff. If you ever use SSH or FTP or whatever, or even just sudo, try TRAMP. Try TRAMP with dired, try TRAMP with eshell, try TRAMP with anything else neat that you've found.

If you're like me, you'll probably walk away after each little thing thinking "yeah okay that's neat, But I don't really get what the big deal is, I could do the same with thing [...]". You'll notice how you could compose a lot of little UNIX programs together to do the same stuff, and you'll like that design more. You'll be annoyed by the startup time vs Neovim, you'll be annoyed by the out-of-the-box deficits relative to VS Code and IntelliJ's stuff and so on. That's fine. The goal is to gradually sample the platform.

To a much lesser extent, only if you're interested in sampling yet another possibility for text-editing interfaces, you might want to try learning its out-of-the-box keybindings for text editing, but... look, personally I think the out-of-the-box experience is at best bad-relative-to-what-you-already-know. I tried it a few times and for me, vi-style modal access to cursor movements and edit operations is a far bigger win than Emacs-style modifier-key access to the same.

You will see mentions of swapping Ctrl and Alt, because that's the layout on the old computers that Emacs' defaults were designed for. You'll also hear people suggest rebinding CapsLock to Ctrl. Honestly I think this is a lower-value detour, presupposing that Emacs as an editor out-of-the-box is worth learning, if only you could just optimize it a little to not give yourself RSI. But if you're going to do that, I suggest also trying Sticky Keys. Maybe it's just me, but I find Emacs' constant modifier key demands far more ergonomic if I can latch or lock modifiers as-needed.

Eventually, once you learn Emacs-as-a-platform enough, you'll start to see that all the little lisp functions and "modes" do a better job of being small composable pieces that do one thing well than UNIX CLI programs. Once you're sufficiently fluent in Emacs-as-a-platform, you'll find it easier to implement the behavior you want in Emacs than in the shell, or in your favorite editor.

And then, only then, will it have been worth it to have learned Emacs. Because then you can build your editor in Emacs. If nothing else, there's a critical mass where it becomes easier to incrementally improve your favorite editor by emulating it in Emacs first. And someone else has probably already done most or all of that work. And then you can keep incrementally improving on it, converging on an editor that's personally optimized to you - a bespoke tailored tool for exactly your mind.

Or that's the idea anyway. I'm not at the end of that journey, I'm just forecasting where it leads. After years of on/off poking at Emacs in various forms, I'm finally fluent enough that I'm incrementally creating something better than my favorite editor (and shell, and window-managing workflow) within Emacs. Not for the sake of doing anything with Emacs, but just because it feels faster and easier within Emacs now than outside of it. I don't know where this lurch ends. Every other lurch into Emacs ended with disappointment, with just enough inefficiency or annoyances that I just gave up on it. This is the first one that felt like it could end with me switching to Emacs as my main thing, but it's still entirely possible that this too will run out of steam.

And that's fine, that's the whole point I'm getting at. Every time I've jumped into Emacs, I made some sort of progress. And then I jump back out and run for a while with a terminal, shell, vi, and various CLIs as my daily tools, because I have to get stuff done after all. Sometimes I did some mix of both - I have memories of using Spacemacs to edit and a separate terminal with a shell for git.

[jochenhayek]

emacs's tramp causes scp to complain about missing option "-T"

emacs’s tramp causes scp to complain about missing option “-T”

This problem started with tramp 2.5.1-pre (on macOS Mojave (10.14.6)). /usr/bin/scp: illegal option -- T If I set tramp-scp-strict-file-name-checking to “” (as suggested in tramp-sh.el), I bypass the problem.

[elisp-solves-problems]

tramp & shell auto-complete slow-ness

I'm at a different $WORK from before! Now I get to (have to?) SSH directly into remote boxes again, which I haven't had to do in a while, as previously my workflow was based around Kubernetes and kubectl, (which meant I didn't have autocomplete at all...).

Anyway, I was noticing that (I thought) company-mode was triggering and taking upwards of 5 seconds to finish composing an autocomplete list for me to pick from. I also have a very low company activation setting, as I don't even have a keyboard binding to activate company's autocomplete.

Turns out it was projectile that was creating most of the lag, as it purportedly is trying to figure out what directory to put in the modeline or something. Long story short, turning off projectile in shell mode made it much more bearable:

(add-hook 'shell-mode-hook (lambda () (interactive) (projectile-mode -1)))

That being said, projectile is indispensable for the rest of my workflows! But just not with tramp in *shell-mode* :)

UPDATE: Huh, turns out projectile-mode turns it off globally, which actually isn't what I wanted - I thought it would've been a buffer local setting. Welp, some additional digging turned up a hook that short-circuits the expensive find-file-hook from projectile that was causing the issue:

(add-hook 'find-file-hook (lambda () (when (file-remote-p default-directory) (setq-local projectile-mode-line "Projectile"))))

ht: https://www.reddit.com/r/emacs/comments/320cvb/projectile_slows_tramp_mode_to_a_crawl_is_there_a/ , https://github.com/bbatsov/projectile/issues/1232

[vim-official]

holy shit, me mentioned. hi emacs!

Modal editing is a big jump of the mind for many people; you will spend the first couple hours thinking "this is dumb, why did they make it this way?" new Linux users and long time anything else users are used to key combinations like guitar chords, and learning an editor is as simple as "okay I need Ctrl b to do this alt 7 to do that Ctrl shift tab to do this"

I personally don't like doing it that way, and I have found that after even a short time, I find editors other than (n)vi(m) to be difficult to get back to. it sucks using Word at work.

on Emacs' point about server hopping: most unix systems come installed with vim, though in some cases nano is used instead of vim.tiny, I noticed this when installing Gentoo. also worth noting that if you're sshing into an ancient Debian server, spinning up a Fedora workstation, or a using a BSD, you might find that there is not vim but only vi (or vim tiny in 'compatible' mode), which has a more restricted feature set. if all you know is vim nocompatible then you might develop habits like using arrow keys, back space, or enter while in insert mode, instead of going to normal mode (and using hjkl, x, or o respectively). if you want to see what that's like, try installing the vim-hardmode package.

package installation on vim (not nvim or vi) is a bit harder than emacs, getting a very customized experience takes some doing, and I keep my .vim in git. the more you customize your vim locally, the less prepared you are to jump to another system. if you're a customization freak, try emacs tramp mode, or scp your .vimrc to any server you remote in to.

I have kind of two brain settings. when I compose original documents in VimTeX, I use my own highly customized vim. I'm still competent with system default vi(m), or I might try some solutions where I can get a traveling vimrc that can rollout quickly onto any server. I don't think I want to learn nvim, because if I'm going to learn a programming language to get an editor I can live in all the time, I may as well make it Emacs Evil.

most of all, and you can throw out everything else I've said today: vim is comfortable to me. I don't like using other stuff. this is Linux, try new things, use the free will with which you were endowed by your creator, find the one you like, and stick with it. long use and practice at the editor you enjoy using (with features that help you) will give you the most seamless, enjoyable writing experience, and you will actually finish your projects.

Should I learn emacs I've been coding in nano

@perl-official

I always recommend emacs. But depending on your use case you might want to learn something else first.

If you hop between different servers a lot and can't expect to have access to your favourite editor on there, I recommend learning the basics of vi/vim since that is preinstalled pretty much everywhere. Also, most bigger IDEs you might use in the future have a setting or extension to use vim-keybinds.

If you just want to program on your own machine, I recommend trying out a few different text-editors and then decide on one.

To learn emacs, I recommend using the built in tutorial. You can access it using C-h t (thats CTRL-h followed by t) while beeing in emacs.

To learn vim, you can use the vimtutor. I think it is automatically installed with vim on most distros, but may have to be installed separately on some. Also neovim/nvim is way better in term of extensibillity to regular vim

Other Editors you could try:

- VS Codium (Visual Studio Code fork that removed most Microsoft Stuff)

- helix - a Vim like Editor

- zed - way too fucused on AI features for my taste but I heard it has some other nice features

If you want some more infos on why emacs is great: here two semi serious posts I made in the past:

Pingin some people who also might have something to say:

@vim-official @helix-editor @emacs-evil-mode

[vishers]

Effective Emacs: How to Have Your Fancy Prompt and Eat Your TRAMP Cake, Too.

Between DotFiles and Is this Shell Interactive? I was able to figure out how to write a test in my .bashrc that disables my fancy prompt so that TRAMP can recognize it.

if [[ "$-" == *i* ]] then export DEFAULT_PS1='\n\D{%FT%T}\n\u@\H\n\w$(__git_ps1)\n\$ ' export PS1="$DEFAULT_PS1" fi

I should really write up my PS1 rationale at some point. :)

[mentalisttraceur-software]

After trying Magit for a bit, I ended up doing my own simple+minimal thing for Git in Emacs, built on a generic function I wrote. The only piece I'm using from Magit is the with-editor package.

I wrote a function which pops open a buffer to run a command. The buffer is named after the full command. I can supply context which is added to the buffer name after the command, or override the name entirely. The buffer is created if it doesn't already exist. By "pops open", I meant the same way that for example the help buffer is popped open, with `pop-to-buffer` - I call it `pop-to-command`.

(I actually have two variants of the function - one runs the command in a raw terminal emulator buffer, and one runs it in an Eshell buffer with terminal emulation. Both use the Eat terminal emulator package. I use the Eshell+Eat variant for this, because it keeps my keybinds+UX more consistent+ergonomic, has TRAMP integration, and lets the with-editor package do its magic.)

(Because I'm using Evil for the greater efficiency+ergonomics of vi-style modal keybindings/UX, I wrap the base function to add a modal nicety: When the command starts, the buffer is put into vi "insert" state (or the "Emacs" state in the case of no-Eshell-just-Eat variant), so that I can interact directly with the command. When the command terminates, the buffer is automatically put into vi "normal" state, so that I automatically return to the keybinds I use for switching/manipulating Emacs buffers, windows, etc.)

I then have a wrapper function to run Git commands with that pop-to-command function, using the current buffer's Git repository as the context.

So let's say I'm editing a file inside a Git repo I have cloned at `~/code/my-cool-project`, I save some changes, and I'm ready to stage them. I hit a keybind, and Emacs pops a buffer named `*eshell: git add -p (~/code/my-cool-project)*`. Since it's running `git add -p`, I am just using the normal Git CLI to review and stage hunks. Same knowledge and muscle memory that works outside of Emacs. Same diff view as outside of Emacs, which would be worse than Magit but lets me reuse better-than-Magit diff improvements like git-delta and difftastic. In the very rare event that I need the granularity of the "e" action in `git add -p`, that opens in my current Emacs instance thanks to with-editor. (Naturally I also have keybinds for the "-p" versions of git checkout, git reset, and git stash.)

When I'm ready to commit, I hit another keybind, and Emacs pops a buffer named `*eshell: git commit (~/code/my-cool-project)*`. Thanks to with-editor, that immediately opens the commit message for editing in Emacs itself, in the same window. When I'm done editing, my normal "save and close" keybind makes the commit - I can also quit without saving to abort the commit. (I monkey-patched with-editor using Emacs' "advice" so that if I save and then quit as two separate Emacs commands, the change is still left saved in Git's COMMIT_EDITMSG file even though the commit isn't made, as would normally happen with any other editor.) Naturally, I have a separate keybind for `git commit -‍-amend`.

Magit automatically always shows the staged diff in a separate buffer while writing/amending a commit. I don't normally need that, but it's really nice to have when I do. I get this on-demand because I have two more keybinds: one for `*eshell: git diff (<current-repo>)*` and one for `*eshell: git diff -‍-staged (<current-repo>)*`. Or sometimes I just leave the `*eshell: git add -p (...)*` buffer open until I'm done commiting.

Of course I also have keybinds for other git commands that I regularly want: git log [-p], git reflog, git pull, git push [-‍-tags] [-‍-force], and so on. Anything I use often enough to get annoyed by the handful of keystrokes it takes me to open Eshell and execute that command from a fuzzy-find on my shell history. (The only Git operation I don't handle this way is blame - I use the built-in vc-annotate for that, configured to wrap lines instead of truncating. The indirection of Eshell-running-Git-running-a-pager doesn't bother me with diffs and logs, but it bothers me in blame due to the different patterns in reading/navigation/search/copying. Also the color-coding by age is nice, and the step-back-through-blame-history feature is one I find valuable when I have to do code archeology to figure out the cause or intent of code which doesn't make sense.)

I have a nice keybind for `quit-window` in these run-one-command buffers which doesn't make sense in normal Eat and Eshell buffers. (Because I'm using Evil, this nice keybind is the mere "q" in vi "normal" state, which overlaps wonderfully with the "q" that you get in the default `less` pager when doing `git log` and so on. So for example I just hit "q" once to quit the log command and once more to quit the window - so I keep the benefits of totally decoupled composition where these pieces don't have to understand/track/assume anything about each other, while still getting something so ergonomic and intuitive that I never notice any delays, mistakes, or cognitive load.)

For me this approach covers basically all the value that I would get from Magit, without any of the rare-but-annoying latencies that I sometimes hit with Magit (or common-and-annoying latencies that I always hit with Magit when using Emacs in Termux on my Android phones). I sorta, theoretically, very very very rarely, miss the ability to just put my cursor on a diff hunk and stage/unstage it with a key stroke, or drill down into the diff for just one commit when already looking at a log. But I basically don't miss it - because it would only save me a few seconds and a handful of keystrokes. I don't miss Magit automatically reusing the diff buffer for staged and unstaged diffs, making it impossible to see both side-by-side. I really don't miss Magit asking me to save the file every time I asked for a Git diff. So I gain some value this way too.

I have some desire to eventully put the pop-to-command functions into their own package on the Non-GNU ELPA, and maybe do the same with my minimal Git wrappers if there's demand.

[admintome-blog]

Emacs 26.1 released

Emacs 26.1 has been released!  If you love Emacs like I do then you should be excited about this release too.

Highlights of this release include:

 - Limited form of concurrency with Lisp threads

 - Support for optional display of line numbers in the buffer

 - Emacs now uses double buffering to reduce flicker on the X Window    System

 - Flymake has been completely redesigned

 - TRAMP has a new connection method for Google Drive

 - New single-line horizontal scrolling mode

 - A systemd user unit file is provided

 - Support for 24-bit colors on capable text terminals

I wrote a blog post on how to install it from source on Ubuntu 18.04:

http://www.admintome.com/blog/install-emacs-26-1-on-ubuntu/

[monaddecepticon]

Emacs + tramp + dired + shell (+ vterm if I can't avoid it)

[mentalisttraceur-software]

Really, this Plan 9 thing has been eating away at me for years, ever since I understood what it could have been if we just mainstreamed the concepts it used.

We could have so much, so nicely, with so much less development effort, with so much more flexibility and composability.

This is so true that if you look around, countless tools implement special case emulations of what in Plan 9 was trivial to do once and then reuse in every tool. File browsers and editors letting you open archive files like .zip and remote storages like Dropbox and protocols like (S)FTP as if they were directories, to name just one ubiquitous example. Attaching a local debugger to remote processes, to name another.

Something like TRAMP mode in Emacs, when and if it actually works smoothly, is a little taste of one facet of what we could have. But TRAMP mode has all this subtle brittleness and inefficiency and complexity under the covers because it has to implement the same end user behavior while dangling off an infrastructure foundation which does not support or empower doing it.

And all of these solutions might have horrible exploitable security vulnerabilities, but who has time to audit that much code!? I sure don't. Or we could just stop reinventing a bunch of this functionality in countless libraries and programs. We could just have a small, nicely composable implementation in the operating system that we could audit much easier. Where the security controls could be concentrated.

But unless enough people actually take the time to see just how much the Plan 9 way enables, and thus develop that vision, and then spread it, we never will.

Linux already implements almost everything needed for it, it is just stuck in this paradigm where things like FUSE mounts and namespaces are privileged resources. And there is not really a great technical or security reason for that limitation, unless you're just stuck thinking about technical or security matters in the box of how things already are.

That goes for anything else that can run something like Docker, by the way, not just Linux.

We're so close. These ideas and ways of interfacing with things is so good that they are pressing in from all sides despite the lack of underlying foundations. Yet it remains frustratingly unusable in practice.

Imagine if you had to run as root or type in your admin password every time you needed to make a pipe, and no one used pipes and all the little tools that work well with pipes were not there, but you could see it in your head, how you could just solve this problem if you could just

... | grep foo | cut -d\< -2 | cut -d\> -f1 | sed 's/foo/bar/' | awk '{ print $1 }'

or whatever, but instead you have to write a C program every time because there are no pipes.

That's how it feels for me at least once a week.

[jochenhayek]

tramp says: "Cannot find local copy program: pscp" – but that does not mean there is something wrong with your emacs/tramp/PuTTY set-up

tramp says: “Cannot find local copy program: pscp” – but that does not mean there is something wrong with your emacs/tramp/PuTTY set-up

I guess it frightens you as well. It does not mean, there is something wrong with your tramp/PuTTY set-up. Try accessing a couple of other files! You will see, your set-up still works. I haven’t yet fully analysed the problem. Once I will have succeeded doing so, I will describe the situation here.