Voting this up, because mc is great and deserves more attention. Sometimes cp/mv/rm or grep just are not sufficient. Mc is great for browsing your filesystem quickly and for example copy partial content of certain directories only. I use it on macos and even on my vps. Using it since windows xp - when i switched to linux from scratch ;-)
That said, i am not sure what this fork adds. I know a lot of mc tricks, i use it a few times a week. But im not a shell, editor, whatever customizer anyways. So not sure if i would miss scripting. I like it if stuff works out of the box, which mc already does!
A few screenshots of those editing features would help. And maybe contribute some of those new features to the main project. Anyways, nice job!
Seconded! A double panel file manager is a very convenient concept, strongly suggest those that have not tried it do so!
I mostly use the core feature of organizing files such as downloads, moving from one folder to another; sorting by size, date, etc, for a quick overview. What would your tricks be?
Not sure if it really qualifies as a trick, but the game changer for me was <ctrl-o>. Being able to pop into and out of MC from the shell, even while in the middle of typing a command is great. It's easy to ignore if the command line suffices, and instantly available when helpful.
cd ftp://<whatever address> and then copying files remotely to whatever local location is my personal favorite.
I just tried and it also works for sftp as well! Though it doesn't seem to read ~/.ssh/authorized_keys -so you have to enter your password each time.
But typing something like cd sftp://<server>/<directory> is a great way to access my unsupported (no guest additions) virtual machines from WSL
There's one snag with ctrl-o; it only works for Linux consoles and xterms. It doesn't appear to work with a BSD (or whatever) console -at least it always gives me errors.
I see this is mostly about the editor MCedit, not the dual-pane filemanager itself.
Does anyone know if the contributors of this fork ever talked to the current maintainers of mc? Since the fork of mc about 10 years ago, there has come a lot of new features and bugfixes into mc the filemanager. I would assume they are open for contributions.
Anyone, I really love this Midnight Commander, It is maybe my most important and most used piece of software :)
So there is also a plugin system in Lua waiting, it just needs someone to care for it. The S-lang plugin system will not go in mc itself since they prefer to get rid of S-lang alltogether, in favor of ncurses as screen library.
This same author had a Python plugin system first, but scrapped it in favor of this S-lang plugin system.
And yes, I can imagine they are looking more for people doing maintenance instead of innovators. They do seem genuine nice guys though.
I'm pretty new to heavy console-based Linux adminning - I just have a raspbian pi4 I'm using for a bunch of local services around my house, but I've gotten pretty comfy editing files and tweaking services and chmodding/chowning.
However, I refuse to climb the learning cliff of Vi, but nano is... Okay at best?
Is mcedit a good option? I'm still just doing everything from shell and nano.
If you're interested in becoming proficient text editing in the shell, I highly recommend just biting the bullet and learning the basics with vim. It's significantly less of a "cliff" than you'd expect. Just spend a few minutes running through the built-in tutorial (vimtutor), learn how to save and open files and move around the document, and set a few defaults in your config.
Only about 30 minutes of effort will be enough to make it much easier to use than nano, in my opinion. Then over time you can learn what makes it powerful, play with mouse control, check out neovim, etc...
Upvoting/seconding this. It doesn’t take as much effort/pain as you think it will. Don’t believe the FUD. That said, plain old vi on older Solaris systems is still a pain in the ass lol.
If you think of vim as a language to edit text it becomes a lot easier to remember how to do something... if you just try to memorize a bunch of incantations it will be awful.
for instance in normal mode where you issue commands to edit text(opposed to insert mode which is akin to any other editor where it's mostly just typing information into the document) you can issue something like delete a(round) word and it deletes the word `daw`. or delete inner word `diw`. want to change a word? change d to c and it deletes the word and leaves you in insert mode to type. all of the commands are very composable and form a "language" to edit text that's a lot more approachable than you'd think. one fun one is something like `ci'` or `ci"` which will if you are on a line with an open and closing " or ' will search forward in the line for a " or ' and delete what's inside that and leave you in insert mode to make your edits....
You'll probably save yourself a lot of trouble if you can edit with vi. It's installed everywhere, and editors like nano are really painful without a mouse.
I don't recommend wasting your time getting great with it or anything. Just enough to be able to use it to do anything you could do with nano...but it will be 3x faster and easier on a console instead of using nano if you learn enough to do what you can do with nano with it.
Maybe try thinking of vi as a programming language (for interacting with text) rather than a text editor. It's really a Human Programming Interface (HPA not API?) which you can run in the line editor of your shell (readline), or in emacs, tmux, even firefox, but of course it works best in vi/vim/nvim.
Learning the vi language makes me think about interacting with computers in a new way.
I recently discovered 'micro' which is along the lines of nano in a way but more modern and just about perfect for me.
I wish TextAdept had become more popular since I always thought it was a strong choice for a modern editor with solid Lua customization support. But it seems like 'micro' is the popular one. Has 16000 stars on GitHub.
As someone who has wasted like 30 years off and on learning how to edit like it's 1979 in vim, I recommend you do not do get peer-pressured into that. Take a look at micro or TextAdept or use gedit with sshfs or VSCode or.. just something from recent decades.
In my experience, that's not a real option in large, professional system admin settings. You wouldn't dare do that on a production machine without your change management process, and your team of admins won't care about installing micro on the thousands of machines you have to manage. You'd have to do a pull request to some kind of config management repo, and no one will agree your pet editor merits a deploy, and your boss will think you're wasting everyone's time.
I'm not covering half of it. Trust me, it is just generally not an option for system administration in the large.
You're right, of course it's impossible for anyone to approve installing a modern editor. How ignorant of me to suggest that. Everyone must use the editor and paradigm from the late 1970s. That's the only way professional system administrators and organizations can operate. No one has time to approve a pull request, no matter how outdated the editor is. We all learned it. Everyone else has to learn it also. Until the end of time. Amen.
I mean, I’d be surprised if the percentage of SAs that are proficient in vi is less than 90% (even that percentage is probably low), so I really don’t think it’s a problem that needs to be solved. vi/m works superbly as the main text editor on *nix servers. Sounds like you just hated it from the get go and refuse to learn it. And that’s also fine.
I learned it and use it all the time. It's just an outdated editor and religion. And there is no logical reason not to replace it with something modern and superior. And it's a shame that people are suggesting that young people waste their time with it.
It's just amazing that says admins are literally suggessting they can't install a program.
Given its prevalence in the SA landscape (which I don’t think even you can deny), to state that learning Vi would be a waste of time for any young person interested in the industry, would be, well, completely inaccurate. But we obviously completely disagree. We can just probably leave it at that.
*nix system administration at many companies means that there are 1000s of RHEL or CentOS or older Solaris servers that you may very often need to edit a file if there is no config management (which is often the case). What all these servers will have to do that will be vi (or vim if you’re lucky). In most cases you can’t just go install some random other text editor that you happen to like better or be more proficient in. That means you have to be at least somewhat functional in vi to be able to perform basic tasks.
If you literally have to log into an ssh session on 1000s of machines running discontinued operating systems to manually edit files and can never install new tools for editing or anything else in those machines, then you deserve to go out of business.
you don't need to eschew model editing if you go to something like vscode... there's a great neovim plugin for vscode that gives you full vim in the background but also has a nicer vscode interface for the frontend.
I just suspect that people who advocate for modal editing and hjkl etc. think that those things are some grand UX secret that only real nerds know about. But really they are just artifacts of that particular historical circumstance.
"How did vi's mode switching idea came from?
Back in 1970s, terminal screen are 80 columns by 24 lines. There's no real-time editing. You edit by typing a command, then call another command to have the screen update to show the result of your command. Vi's “modal editing” is evolved from this. This is also why emacs's manual calls itself “Real Time Display Editor”. Emacs is the first or one of the first “Real Time Display” editor.
Why vi uses j k h l for cursor movement?
Unix vi's use of j k h i for cursor movement, and the choice of Escape key for mode switching, came from the keyboard it was developed on, the ADM-3A terminal."
> I just suspect that people who advocate for modal editing and hjkl etc. think that those things are some grand UX secret that only real nerds know about. But really they are just artifacts of that particular historical circumstance.
while it's true that it was born of historical necessity and the decisions for it were partly due to keyboard constraints and the other constraints, I disagree vehemently with the assertion that it's not a more efficient way to edit code. writing a screenplay? maybe not but programming? yes... especially in the context of a larger ide.
And what happens when another dev can’t think of a name for their clone? What do they do then? Name it Neoneomc? The dev should have gone down the less-more-most route. Midnight commander, Twilight commander, Dusk commander, Midnight Admiral, Twilight Mutiny... I may give ‘mc’ a try again. Never bothered before.
I doubt Neo Emacs' existence, emacs is very extensible and rather than a separate fork you'd get something like Spacemacs[0] which builds over the default Emacs distribution.
How do I navigate to the same directory which is opened in the other panel or to a root of a particular device (a USB drive or a hard drive partition) quickly? These are the 2 things I use heavily in all the "commanders" but couldn't find in MC. Lack of these makes it useless for me as I hate manually crawling the global file system every time I want to switch a drive.
According to the "File" menu, the shortcut for "Quick cd" is `M-c` ( Alt and c). Works well, no tab-completion alas, but quick enough to get to /mnt or /media or where ever.
Lately I switched from mc to vifm[1][2]. It's ncurses-based two-panel file manager with vi-like navigation. Quite recommend for those who use vim daily.
I wish somebody created Volkov Commander for modern computers. I need exactly that much functionality. Just two fixed sized panels (50/50) and the ability to navigate in the folder structure. Nothing else.
That said, i am not sure what this fork adds. I know a lot of mc tricks, i use it a few times a week. But im not a shell, editor, whatever customizer anyways. So not sure if i would miss scripting. I like it if stuff works out of the box, which mc already does!
A few screenshots of those editing features would help. And maybe contribute some of those new features to the main project. Anyways, nice job!