Live data from Hacker News

Tmux 1.9 released

sourceforge.net

111–120 of 121 posts

Re: Tmux 1.9 released

#111

An absolute staple of my development setup, and one of those rare tools that always just seems to work. Thanks for all the work! Sidebar: if you're a die-hard tmux user in Linux, and you do something like, say, open vim and then realize you haven't opened it in tmux, check out https://github.com/nelhage/reptyr - it lets you do things like ctrl-z to background vim, start tmux, then steal the vim process into your new…

I love and use tux all the time, but for me it doesn't always just work. I regularly run into weird backspace/delete behavior when using tmux with ssh. For example, ssh from ubuntu into rhel and then running tmux will give me a completely different behavior compared to when I tmux in ubuntu and then ssh into rhel. I know that backspace/delete behavior has more to do with the terminal than tmux, but gnome terminal see…

I've run into this a few times, too -- seems to have something to do with the termcap info for tmux's virtual term. FWIW, I was able to work around it with 'stty', e.g.:

$ stty erase ^?

to recognize DEL (ASCII 127, or ^?) as backspace. I have that in my .bashrc on a particular machine that gives me this problem...

Re: Tmux 1.9 released

#112

I have to say that the tmux-users mailing list in general, and Nicholas Marriott in particular, are really nice and friendly. I had a feature request (256 colors in fbterm so you can get 256 color tmux/vim without x), quickly got patch code, got support (I had never used patch before and didn't tell it to ignore whitespace) and when it worked, was told it would be in 1.9, and there it is. :-)

Just spent half an hour trying to figure out why 256 color mode stopped working in Vim. I'm blaming you =P In all seriousness actually trying to get 256 colour mode auto detecting and working reliability across different xterms, tmux/screen, ssh and so on, without some hack that forces the 256 on even when it's not supported seems impossible :/ I added the following to my zshrc, which seems to have helped. Why don't…

The escape sequences to set 256 colors were previously hardcoded into tmux, instead of detected from terminfo. That works fine, until you use a program that uses different escape sequences.

I suspect terminals don't set 256 colors by default for backward compatibility reasons. tmux itself didn't assume, you needed something in your config file or a command line option. Now though, I believe it can detect it based on your term.

Re: Tmux 1.9 released

#114

> 'default-path' has been removed This kind of annoys me, but I'm successfully using this workaround (hinted at in the announcement): bind c run 'tmux new-window -c "#{pane_current_path}"' bind-key '%' split-window -hc "#{pane_current_path}" bind-key '"' split-window -vc "#{pane_current_path}" Anyone know why this change was made?

No, but I am very thankful for your posted workaround.

Re: Tmux 1.9 released

#115

Earlier quoted context omitted.

Yeah, as an emacs user, every time a tmux post pops up on HN, I go read about it and wonder what it would really do for me. I guess what I'm seeing is that for my emacs sessions it really doesn't buy me anything. I'd be curious to hear about things I can do with tmux that I can't do with emacsclient and emacs daemon.

Tmux is for your shell sessions. Emacsclient is orthogonal. Or do you do all your shell work in emacs?

> do you do all your shell work in emacs?

I do! eshell is a very good shell that integrates nicely with emacs. For instance, I love egrep in eshell, you can move your cursor over the output and emacs will take you right to the line that matches.

So let me temper that just a wee bit, I do use eshell a lot, but there are a few cases where it doesn't work quite well, but those cases are few and far between, certainly not enough to warrant using tmux, at least I can't be convinced yet.

EDIT: I said eshell integrates nicely with emacs. That's not true, it's a shell written in elisp for emacs, no integration whatsoever. Sorry, but I don't feel like rewording what I wrote, so just adding this edit comment ;)

Re: Tmux 1.9 released

#116

Earlier quoted context omitted.

Tmux is for your shell sessions. Emacsclient is orthogonal. Or do you do all your shell work in emacs?

> do you do all your shell work in emacs? I do! eshell is a very good shell that integrates nicely with emacs. For instance, I love egrep in eshell, you can move your cursor over the output and emacs will take you right to the line that matches. So let me temper that just a wee bit , I do use eshell a lot, but there are a few cases where it doesn't work quite well, but those cases are few and far between, certainly n…

If you do any sort of work on Middling-to-Fairly-Big Data, eshell is not for you. I love emacs, and would love to love eshell, but I prefer running grep/awk/sed/etc in tmux since it's just soo much faster.

And of course, if you need to use any sort of curses type thing, eshell (or M-x shell) often fails in ugly ways.

Re: Tmux 1.9 released

#117

Earlier quoted context omitted.

> do you do all your shell work in emacs? I do! eshell is a very good shell that integrates nicely with emacs. For instance, I love egrep in eshell, you can move your cursor over the output and emacs will take you right to the line that matches. So let me temper that just a wee bit , I do use eshell a lot, but there are a few cases where it doesn't work quite well, but those cases are few and far between, certainly n…

If you do any sort of work on Middling-to-Fairly-Big Data, eshell is not for you. I love emacs, and would love to love eshell, but I prefer running grep/awk/sed/etc in tmux since it's just soo much faster. And of course, if you need to use any sort of curses type thing, eshell (or M-x shell) often fails in ugly ways.

I upvoted you because I think you present a fair point, especially about "big data" and curses programs, though I recently noticed that top is behaving well in emacs and I don't think it was before, so maybe it's getting better and I need to revisit some of my old workflows to see if I can incorporate them.

As for running grep/awk/sed in tmux being fast, I don't doubt running the individual program and getting your results is faster, but the interaction in eshell and going beyond, say, grep output and actually being able to go the the line in question, the whole workflow, is much faster than running grep and then firing up an editor on the file and moving to the line. That is the real power, the whole workflow is made faster such that the fact that grep is a slow elisp implementation doesn't matter. And elisp grep really isn't that slow, accessing the file system is the slow part and that's true for both implementations and both can benefit from aggressive file caching anyway.

The less I have to leave emacs during an editing session, the faster/more productive I'll be. And that's the real power of eshell IMO.

Re: Tmux 1.9 released

#118

Earlier quoted context omitted.

If you do any sort of work on Middling-to-Fairly-Big Data, eshell is not for you. I love emacs, and would love to love eshell, but I prefer running grep/awk/sed/etc in tmux since it's just soo much faster. And of course, if you need to use any sort of curses type thing, eshell (or M-x shell) often fails in ugly ways.

I upvoted you because I think you present a fair point, especially about "big data" and curses programs, though I recently noticed that top is behaving well in emacs and I don't think it was before, so maybe it's getting better and I need to revisit some of my old workflows to see if I can incorporate them. As for running grep/awk/sed in tmux being fast, I don't doubt running the individual program and getting your r…

As an emacs user I do agree with what you're saying. I do all my codebase searching using ag from emacs[1] instead of grep and I absolutely love it: you get the results in a compilation-mode buffer which instantly jumps you to the search hits.

Maybe I should use eshell or one of the comint shells more. But I wouldn't want to leave bash/zsh behind -- I might as well be on windows then :) (which is, btw, a strong argument in favor of the workflow you're describing -- for those poor people who are forced to use windows, eshell is a blessing.)

[1] https://github.com/Wilfred/ag.el

Re: Tmux 1.9 released

#119

Earlier quoted context omitted.

I upvoted you because I think you present a fair point, especially about "big data" and curses programs, though I recently noticed that top is behaving well in emacs and I don't think it was before, so maybe it's getting better and I need to revisit some of my old workflows to see if I can incorporate them. As for running grep/awk/sed in tmux being fast, I don't doubt running the individual program and getting your r…

As an emacs user I do agree with what you're saying. I do all my codebase searching using ag from emacs[1] instead of grep and I absolutely love it: you get the results in a compilation-mode buffer which instantly jumps you to the search hits. Maybe I should use eshell or one of the comint shells more. But I wouldn't want to leave bash/zsh behind -- I might as well be on windows then :) (which is, btw, a strong argum…

Thanks for sharing about ag, I'm going to check that out! Luckily I'm on Linux for most of my development, but sometimes I am on Windows and you're right, eshell is a blessing there :)

Re: Tmux 1.9 released

#120

> 'default-path' has been removed This kind of annoys me, but I'm successfully using this workaround (hinted at in the announcement): bind c run 'tmux new-window -c "#{pane_current_path}"' bind-key '%' split-window -hc "#{pane_current_path}" bind-key '"' split-window -vc "#{pane_current_path}" Anyone know why this change was made?

For anyone else who shares tmux configs between different versions, this is a good way to do it:

    if-shell "[[ `tmux -V` == *1.9* ]]" \
        'unbind c; bind c new-window -c "#{pane_current_path}"'
Post reply on HN