Hacker News Reader

Comment by moosingin3space | Hacker News Reader

The target audience is people who casually use the terminal (probably over ssh) and need something simple to edit a config file with. This comes with all the basics that people expect from a graphical editor like Notepad++ and comes with familiar keybindings from CUA applications. I could see something like this being very useful for that use case.

View on HN

That's actually a big market. People coming from vim will wonder what would you use it for when vim is so much more powerful. But this is a godsend to users who are used to gui editors. If they want something that behaves like every other editor and IDE they use there is very little available. In particular I don't know of any terminal editor that comes as a single binary and uses standard keystrokes like micro.

I wrote an editor which more-or-less matches that description: http://www.github.com/marssaxman/ozette

I've never expected nor done any work to attract users other than myself, so there are a handful of rough edges I've never bothered to polish, but I have in fact been using this thing full-time for several years.

Perhaps I wouldn't have written it if micro had existed back then.

Cool, any screen shots? Would like to see the tabs with a few files open.

Thanks for your interest. I've added a couple of screenshots to the readme. I usually run ozette in a terminal filling one monitor, with 2-3 files open. It works fine with more, but you just can't see much of their contents; still, seeing the edges of the other files in a stack behind the active tab somehow helps my sense of spatial navigation.

It's funny how life works. There is nothing especially sophisticated about this bit of code, it has many little bugs I've never bothered to fix, and I'd design it completely differently if I started now. Still, though: after thirty-plus years writing code, I've gotten more actual use out of this little tool than anything else I've ever written. Judging by the ratio of hours spent writing it to hours spent using it, nothing else even comes close, not within an order of magnitude.

The reason they don't use those standard keystrokes is because for a terminal there is a much older standard that takes precedence regarding control characters. What's ctrl-z do? Background, or undo? It's nice for undo, but losing backgrounding capability is crippling if you use it.

Solution. Add an additional unix control key to all keyboards.

Maybe actually instead of caps-lock.

I think I've solved all my keyboard related problems know.

The solution adopted by Unix-era GUIs, and the Macintosh, was to use a different key for GUI shortcuts rather than overloading Control. X11 generically calls it ‘Meta’, USB calls it ‘GUI’, Sun had Diamond, etc. It was only Windows that botched it, and the this-is-finally-the-year-of-Linux-on-the-desktop-trust-me-this-time crowd who slavishly imitate it while ignoring Unix experience.

Funny enough, I use the Win key on my keyboard effectively as a 'meta' for all my shortcuts in i3. It was the only key that wasn't doing anything.

It’s rare to need to background a console editor, and many can run commands themselves in the background. Combined with tabbed and split terminals not much if anything is lost.

> It’s rare to need to background a console editor,

LOL. My experience with an average of 5-6 backgrounded vims *per each named tmux session" which I use to keep track of different source files I'm working on goes against this. Sure, I can use vim's windows, but I don't want split screen usually (I'll use the other terminal I have open if I do). I don't use tmux's windows either really. It's more a way to preserve session when changing workstations (these are remote terminals), and preserve against network drops. I use each tmux session as a contained work environment for the most part. I do all my software development using vim on a remote server, and have for most of the last two decades. I've worked with numerous other developers that work similarly for professional projects, personal projects, or both.

Let's just say that there might be people that use the combined features of terminal applications, terminals, and remote connections in ways that you might think were rare, but actually have large following and leave it at that. :)

It requires a modified setup, but you can set vim up to open multiple unsaved files in a single process. Not splits ir windows, but buffers. I have bindings set up to quickly do :bn and :bp and :bd. Your tmux usage sounds like mine, and if you did not know that there was depth to vim buffers this may be valuable to you.

I'm aware of stuff like that, and things like nerdtree. In the past, I've had many boxes I might end up on so I kept coming relatively stock to the distribution. In the last four to five years it's been primarily one box, so I've finally started putting in more advanced features slowly.

There are benefits to being comfortable in a somewhat stock Vin, and there are benefits to having it highly customized. I find the benefits imparted might be outweighed by the discomfort when it's not as you expect if your work flow forces that situation on you, so as my work flow has changed with the type of work I do, I've tried adopting different vim strategies.

You may choose to do that but it isn’t required, I listed three alternatives that work fine and there are probably more. Going in and out of an app all the time is inefficient.

If I don't want a separate SSH connection for every tab, then some in-terminal level management is required. Additionally, it's not really that inefficient. It's no different than alt-tab in windows to background and foreground apps. In this case, it's like alt-tab when in a remote desktop connection.

But in the end it's not about whether it's efficient, it's about whether it's rare, and I think it's not from the different vim users I've encountered, which may be an entirely different subset than the ones you have.

It sounds like you’re already happy with vim, so why not keep it? Also the micro keybindings are configurable, so not much to see here.

I wasn't complaining about Micro. I wasn't complaining about vim. I was just noting why terminal applications don't generally use those same key bindings historically, and why it still matters today. The only reason we are off in the weeds like this is because of your assertion that it's rare to need to background a terminal editor, which doesn't match my experience at all.

I just open a new tmux window per-file I edit, named after the file. Well, I do still bg vim processes sometimes, but mostly I do the per-window vim thing. I even have a vim wrapper to do this so that editing files from cscope automatically starts a new tmux window with the vim in it and returns control to cscope.

Windows doesn't have sshfs, do they? If it did, you could just mount the remote, and use whatever UI editor you want. I do this with gvim (but on Linux)

Reply on news.ycombinator.com