Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X Command Line Utilities

mitchchn.me

Post reply on HN
Print view View original

201–210 of 243 posts

Re: OS X Command Line Utilities

#202

Post by cityhall »

nesyt wrote: post #158
yangyang wrote: post #139

Earlier quoted context omitted.

A frame in Emacs terminology is actually a top-level window.

So MacVim does have this functionality then, yes? You can have multiple top-level windows, each having multiple tabs, each having multiple splits.

They don't share anything. Different buffers, registers, and I think even different extensions loaded.

Re: OS X Command Line Utilities

#203

Post by aroch »

ch4s3 wrote: post #180
aroch wrote: post #151

Earlier quoted context omitted.

You can scroll in Terminal.app too, use the MouseTerm SIMBL plugin

Well, once you're bolting on plugins for features that come with iTerm2, why not use iTerm2?

Because I find iTerm to be a pile of crap on most of my systems

Re: OS X Command Line Utilities

#204

Post by theOnliest »

Touche wrote: post #113
huskyr wrote: post #6

Awesome. I knew about `pbcopy`, but i never knew you could also pipe stuff into it. That saves a lot of time saving script outputs to temporary text files and copying!

alias copyssh="cat ~/.ssh/id_rsa.pub | pbcopy"

Or without the extraneous cat: "pbcopy < ~/.ssh/id_rsa.pub"

Re: OS X Command Line Utilities

#205

Post by pirateking »

twic wrote: post #107
pirateking wrote: post #84

After years of living on the command line, OS X specifically, and learning its quirks and tricks, I am actually ready to move on. Right now I am more interested in creating simple visual interfaces on top of UNIX-y tools, for my own personal use cases. The main benefit of this is the ability to better experiment with and optimize my workflows for different properties as needed through different combinations of single…

Why do you think that having a visual interface will make it easier to experiment with your workflow? This is a genuine question - personally, i find command line interfaces to be far more hackable than graphical ones, so i would expect the opposite to be true, and hence i'm interested in your perspective.

The command line is a textual interface, and both code and data can be represented as text at a low level. It would seem that this is a good thing for efficiency and usability, as it minimizes context switching between interface paradigms, and offers direct access to a low level representation of the system using a high bandwidth input device (a keyboard).

I still think textual interfaces are a great thing for those reasons, but I don't believe they are the best thing in many cases. Yes, they are very capable and customizable, but have serious weaknesses with usability, especially when working with data of higher dimension.

I don't really think of it as text versus graphics, but rather an issue of data being represented in its best form for doing some particular work with it, and having the best interfaces to those different forms and the work. The traditional one-domain/one-application GUI model is unsustainable for this purpose, and has the weakness of constant context shifting. Composable visual interfaces are an anti-application paradigm, and more focused on data flow. To avoid problems with pure visual programming environments, symbols would still be considered the best representation for certain work (like editing text and working with logic).

Re: OS X Command Line Utilities

#206

Post by yangyang »

massysett wrote: post #187
cozmorado wrote: post #137

Earlier quoted context omitted.

Vim can absolutely do multiple "frames". They're called splits.

No, it cannot. An Emacs "frame" is a separate editor window, managed by the window manager. Different Emacs frames running the same Emacs session talk to each other--they share the buffer list, etc. Within the Emacs "frame" you can have split "windows". One Vim session can live only in one window that is managed by the system window manager. You cannot have multiple windows that talk to each other. You can split a si…

You can also run Emacs as a daemon, and connect to it from both graphical and tty sessions. So you could ssh into your desktop and (with emacsclient), work with the same instance running on your X desktop.

Re: OS X Command Line Utilities

#208

Post by xraystyle »

ansimionescu wrote: post #118

Additions: * lunchy: wrapper over launchctl, written in Ruby – https://github.com/mperham/lunchy * brew cask: "«To install, drag this icon...» no more", as they say – https://github.com/caskroom/homebrew-cask * have fun with "say" – https://github.com/andreis/different

Speaking of fun with "say", this was a hit around my office for a while: https://github.com/xraystyle/talking-computer

Re: OS X Command Line Utilities

#209

Post by kroger »

enneff wrote: post #65
Angostura wrote: post #56

Earlier quoted context omitted.

OK, how did you discover that?

The "cellos" voice always sings that song, regardless of the words you ask it to speak. The syllables were chosen to fit the song.

Nice! You can do something like:

    python -c "print 'foo ' * 26" | say -v cellos

Re: OS X Command Line Utilities

#210

Post by 0x0 »

DCKing wrote: post #120

Could you imagine Apple would have gone for BeOS or a custom developed kernel with no significant terminal-based userland when making OS X? It would probably still be used by many casual users or those doing graphical work, but I doubt it would be used by hackers at all.

Didn't BeOS ship with bash and everything?
Post reply on HN