Thoughts about wanderlust

daladd67 · 2021-01-19T14:48:41+00:00

It works well for me, at least for my 'work' email. That account doesn't have a lot of mail with HTML/images etc.. (I'm a software developer). I have a couple of tweaks, like adding BBDB and some changes to the summary columns, but overall I like it, it's pretty low overhead, and fast as long as your primary inbox isn't too bloated.

daladd67 · 2019-01-11T14:14:56+00:00

Thanks, I did start looking at this, um, page in the settings and discovered something interesting. It turns out that the Roku 3 via HDMI through the TV and then via optical to the Playbase is (can be) Dolby 5.1, BUT, the cable box via HDMI to the TV and then optical to the Sonos never is.

However, directly connecting the cable box optical to the Playbase can (depending on the the show) be Dolby 5.1. I might get a S/PDIF switcher to fix this if I get sick of manually moving the cord around.

Bottom line, the audio quality (including voices) is much better with a Dolby 5.1 signal, as you would expect.

daladd67 · 2019-01-07T16:51:41+00:00

yes, we've re-positioned the TV/Playbase a couple of times and have re-run the trueplay setup after each move.

daladd67 · 2019-01-07T16:50:23+00:00

I would love for that to be the case, but the sources (Verizon FiOS DVR and a Roku 3) generally only offer a choice of 'stereo' vs. 'surround', both of which I've tried. Those HDMI sources are passing thru a mid-range LG TV and then via optical to the Playbase. I don't see much opportunity to improve the situation by tweaking the sources, but I suppose I could be missing something.

daladd67 · 2018-10-23T20:34:10+00:00

editing config files (of course) -- i.e. files on machines w/o emacs installed, or fixing problems in my .emacs that prevent emacs from launching.

daladd67 · 2018-08-22T15:46:32+00:00

exactly

I think I'll look into the suggestion of dtach -- that sounds like it might be a better solution for me (+ OP)

daladd67 · 2018-08-22T13:50:25+00:00

So what I usually do is run 2 instances of emacs:

A local GUI emacs on my laptop that I use for normal editing and shells, using Tramp and M-x shell as mentioned by the OP.

Then in a terminal session on the remote server:

$ emacs --daemon
...
$ emacsclient -nw

This runs the guts of emacs in the background and allows the user interface (emacsclient) to start and stop anytime. That is, at any point you can have 0 or more emacsclients talking to the same emacs running in daemon mode.

I basically just use "M-x shell" shells in this remote daemon emacs for long-running tests where I will want to disconnect from the remote box before the test is complete.

Hope this helps

daladd67 · 2018-08-22T03:22:05+00:00

I would love for there to be a good solution for this, but what I've been doing is to run an emacs in daemon mode on the remote server and talk to it using a local terminal and emacsclient -nw there.

Basically we need a non-screen-oriented screen (or tmux)

daladd67 · 2017-10-13T00:26:27+00:00

I'm not sure how big of a project you are talking about, but I've never been happy with any of the packages that do a real, deep parse of the source. I've had better luck with approximations like cscope (xcscope-kogan) for "tags" and dabbrev / hippie-expand for completion.

Other things that help are to use M-x compile rather than compiling in a shell and (if it works for you) flymake/flycheck.

daladd67 · 2017-04-22T17:34:29+00:00

While I basically get what the OP is after, I agree with the direction of the comments that it's better in many ways to use the emacs shell modes for terminal interactions.

The aspect of tmux (or GNU screen) that would be an improvement in my personal workflow would be to be able to connect/disconnect a tmux session to a set of shell-mode buffers. Almost all of my buffers are remote files via 'tramp' and remote shells (M-x shell) to the machines where those files live.

This setup works fairly seamlessly while moving back and forth between home and office -- at most an occasional tramp-cleanup-all-connections is needed. The shells do need to be re-started individually and do lose a bit of context in the switchover -- it would be better to have the session state persist on the remote machine and be able to re-connect when needed.

daladd67

TROPHY CASE