[HN Gopher] Micro - a modern and intuitive terminal-based text e...
___________________________________________________________________
Micro - a modern and intuitive terminal-based text editor
Author : thunderbong
Score : 258 points
Date : 2021-11-06 09:18 UTC (13 hours ago)
(HTM) web link (micro-editor.github.io)
(TXT) w3m dump (micro-editor.github.io)
| yakkomajuri wrote:
| Definitely tough to "compete" in this space because locally most
| people end up going to their IDE of choice for heavier workloads
| and if you do decide to use a terminal editor, you'd rather have
| it be compatible with things you'd encounter in the wild (e.g. a
| remote server, someone else's machine).
|
| That being said, this is cool. I've set it as my default editor
| for the GH CLI to use it for pull requests and the like, let's
| see how it goes!
| kortex wrote:
| The ergonomics are so much better than vi/vim/nano that it is
| my go to edit from the CLI tool. Sometimes it's faster to just
| edit a line than mouse over to my IDE.
|
| And yes I think vim has bad ergonomics. It's so much effort to
| get it configured to work for me. I get way more out of Alfred
| and my moonlander keyboard with macros that work across the
| whole OS.
| mixmastamyk wrote:
| It's compatible with just about everything still maintained.
| And a simple scp if not installed.
| askonomm wrote:
| I wouldn't say something lacking a LSP is modern by todays
| standards, as that would mean it lacks syntax highlighting, go-to
| definition, and other basic things for a bunch of languages.
| jeddy3 wrote:
| LSP is definetely not needed (or even widely used?) for syntax
| highlighting.
|
| LSP is not even used for highlighing in vscode, where it
| originated.
| pxc wrote:
| LSP is not required for syntax highlighting, and in most
| languages global/ctags is good enough for jump to definition
|
| LSP is good though
| walrus01 wrote:
| This looks great as a software project. And a good alternative to
| Nano.
|
| But from the website: "curl https://getmic.ro | bash"
|
| NO!
|
| We need to stop getting people comfortable with the idea of just
| curling random stuff into their shell.
|
| Even worse is software that suggests you _sudo_ curl it into
| bash. What could possibly go wrong?
|
| Download and build it yourself. Or download and install a
| packaged .deb or .rpm or whatever is the equivalent for your
| platform.
|
| Do not just blindly curl into your shell things coming from
| people you don't know and trust to the level that they are
| personal friends and you would loan them your house keys or your
| car.
| laurent123456 wrote:
| Since the script comes from GitHub repo, and the source is also
| on the repo, isn't building the source the same as getting the
| shell script and running it? I mean if one is compromised, the
| other might be compromised too.
| Meekro wrote:
| Why is this more dangerous than installing a deb, which can
| also run arbitrary code as root?
| walrus01 wrote:
| a .deb at least went through some cursory level of
| examination by the people who downloaded the source, built it
| and are authorized by the debian project to submit new .deb
| files to the debian package servers.
|
| not just any random person can submit a .deb and have it go
| live on the gpg-key authenticated debian mirrors.
|
| https://wiki.debian.org/Packaging
|
| https://www.debian.org/doc/manuals/debmake-doc/index.en.html
|
| curl into bash can be as quick as "ooh look shiny new thing
| on website, let's copy/paste this string of text into my
| shell"
| qbasic_forever wrote:
| The reality is you need to install a random PPA or download
| a random deb from the author's website, github, etc.
| because the debian release is woefully out of date. So
| you're back to installing random binaries again.
| bscphil wrote:
| If you need the latest available versions of the software
| you use, you should probably use a distribution that has
| that as a goal. Debian is built with the intention of
| providing stability, under the assumption that most of
| its users can afford to go a couple of years without
| feature updates in the software they use.
| selfhoster11 wrote:
| If you need to install from the author's site, that means
| that there is no Deb available in the official repos, or
| that it's outdated. In both cases, you end up installing
| something that the author compiled.
| Meekro wrote:
| I agree that debs that were audited and distributed in the
| package manager are better in that way. I guess my
| objection is that "curl https://getmic.ro | bash" often
| gets a hostile reaction here on HN whereas "wget https://gi
| thub.com/zyedidia/micro/releases/download/v2.0.10/... &&
| dpkg -i micro-2.0.10-amd64.deb" does not.
| bscphil wrote:
| The latter absolutely should get just as hostile a
| reaction. The only thing it provides you over the former
| is that it at least guarantees you that the author went
| to the trouble of creating a deb.
|
| Actually, it should probably get _even more_ hostile a
| reaction, since installing it that way usually means you
| won 't get any updates for it. If you absolutely must
| install software from a (trusted) source other than your
| distribution, adding a source and then using `apt` is the
| way to go.
| jftuga wrote:
| Windows sys admin here. Micro is nice because it is a single-
| file, stand-alone executable that has mouse support, macro
| record/playback and syntax highlighting. (I haven't checked Nano
| recently).
|
| Because of this, I don't mind installing it on servers. It is
| great for making quick edits to json configs, batch files,
| powershell, python scripts, etc. Syntax highlighting and line
| numbering are key. The alternative is editing the file locally
| and then getting it onto the server which can be challenging for
| locked down systems, especially Windows Server Core which does
| not have a GUI environment.
|
| Even on my local machine, if I need to make a really quick edit,
| it is much faster to use this than waiting for VS Code or PyCharm
| to load. You also stay focused. By this I mean, your eyes don't
| leave the powershell window that you are currently working in.
| This allows me to more quickly complete the task at hand.
| ChrisArchitect wrote:
| Anything new here?
|
| Lots of previous discussion:
|
| 1 year ago https://news.ycombinator.com/item?id=23334190
|
| 4 years ago https://news.ycombinator.com/item?id=15360509
|
| 6 years ago https://news.ycombinator.com/item?id=11516902
| Severian wrote:
| As another commenter noted, this is a good alternative to Nano (I
| too need to learn Vim). I've checked this out, and I like what I
| see so far.
|
| Typically my main use for text editors is for log analysis
| (mainly Sublime Text). This usually means I write a lot of regex
| for searching.
|
| With that in mind, I do see one shortcoming in the choice of Lua
| as a scripting language. It's not really known for it's text
| processing abilities. One major shortcoming is that it doesn't
| have a true regex engine. This is something I use extensively.
|
| For most of my use cases, this would require I hack together a
| native search in the application, and then pipe the buffer to Lua
| for post-processing. I'm not sure if search/replace pipelines are
| going to be easy to code in this manner or efficient enough to be
| worth it.
|
| I use Sublime Text because it uses Python and makes this
| relatively easy. Or if I'm searching over thousands of logs to
| use ripgrep and just pipe in whatever that way since it can
| search 10GB in a few seconds with moderate sized regex.
|
| Otherwise, I like the approach and the helpful commands for the
| user! It is definitely nice to be able to stay in a terminal
| instead of using a GUI to edit.
| rcarmo wrote:
| If you're fiddling with logs, pick an editor that can handle
| (theoretically) unlimited file sizes -- which is something that
| very few mention supporting. vim will do you great stead for
| what you seem to need.
| Severian wrote:
| Yeah, buffering in an editor is important. I'll look into Vim
| a little more.
| Koshkin wrote:
| That's what I have never understood - why would you want to
| open a log file in a text _editor_ (when the standard tools
| of the trade in this case should be an "unbuffered" text
| viewer, which by design, can handle files of any size, fgrep,
| and, if you want to generate a report, a stream editor, such
| as sed).
| tstack wrote:
| Try out the Logfile Navigator (http://lnav.org) for working
| with logs instead of a text editor. It can provide a lot of
| benefits by default, like collating messages from multiple
| files together, syntax highlighting, decompressing files and so
| on.
|
| (Sorry this is a little off topic, but there's a lot of room
| for improvement for working with log files over a text editor
| without scaling up to a log service)
| chrisweekly wrote:
| I was about to post about lnav too. It's phenomenal -- and
| not just for logfiles! With embedded sqlite, it really is a
| mini ETL powertool with all the benefits of *nix-y CLI usage
| and scriptabity.
| chappi42 wrote:
| > (I too need to learn Vim)
|
| well, then start. What are you waiting for?
|
| E.g. here: https://danielmiessler.com/study/vim. Don't miss Vim
| as Language.
| VHRanger wrote:
| Love it as a replacement for sublime text to quickly look at or
| edit various random files
| RivieraKid wrote:
| I've been using this instead of nano for 2 years and can
| recommended it.
| skrebbel wrote:
| As a Windows native, for years I felt limited when shelling into
| Linux systems, because all editors felt weird to me. Obviously
| the solution would be "just learn vim already" but I'm lazy. I
| settled on nano because it at least shows what shortcuts are
| available, saving me from having to Google "how to find text in
| vim" every time. But its shortcuts are weird (to me) and even the
| descriptions are. UnCut? WhereIs? Huh?
|
| Micro really got the UX right for people like me and it made me
| more happy than I expected. It's now the EDITOR on just about
| every non-GUI system I have access to and I love it.
|
| Thanks, Micro authors!
| nirui wrote:
| I started to heavily using vim since the last few months
| because writing code through SSH is very attractive for my
| current situation.
|
| For me, learning vim is like learning an foreign language, a
| few hundred words (or few hotkey/:commands for vim) can get you
| started, but it's not easy to reach the level of native
| speakers, and some old rules in your language (for example,
| HJKL keys in vim vs the "natural" arrow keys) will interfere
| your progress.
|
| Maybe I'm going to piss many people off here, but vim is not an
| user-friendly text editor. An user friendly editor should pop
| some kind of prompt when I pressed the first g/G key and show
| me what I could press the next, not telling me to read :help
| (which probably has the volume of a dictionary at this point).
|
| Based on my 2 minutes with Micro and the information I read
| from it's `help defaultkeys`, the size of it's hotkeys are more
| healthy and manageable. So that's a plus from me.
| IshKebab wrote:
| Some IDEs support full development over SSH now - VSCode and
| IntelliJ - so you can be freed from vim.
| 0x4d464d48 wrote:
| "freed from vim."
|
| ... Does not compute.
| spijdar wrote:
| > An user friendly editor should pop some kind of prompt when
| I pressed the first g/G key and show me what I could press
| the next, not telling me to read :help
|
| You might be interested in the Kakoune editor. Despite being
| superficiality similar it's not Vim compatible, which may
| make it a nonstarter, and it has its own flaws that keep me
| from using it, but it makes a point of showing on-screen help
| for almost every command as you're typing.
| Riverheart wrote:
| There's always VSCode with the Remote SSH plugin, unless you
| prefer the minimal setup.
| anonova wrote:
| > An user friendly editor should pop some kind of prompt when
| I pressed the first g/G key and show me what I could press
| the next,
|
| See vim-which-key [1] and which-key.nvim [2] for something
| similar to this.
|
| [1]: https://github.com/liuchengxu/vim-which-key
|
| [2]: https://github.com/folke/which-key.nvim
| canaus wrote:
| For those add-ons, don't you have to provide them with the
| prompts? You still need to actively _know_ how to do
| something to have it provide you with information.
|
| You can use something like LunarVim which has everything
| already setup.
| adamnew123456 wrote:
| > Maybe I'm going to piss many people off here, but vim is
| not an user-friendly text editor. An user friendly editor
| should pop some kind of prompt when I pressed the first g/G
| key and show me what I could press the next, not telling me
| to read :help (which probably has the volume of a dictionary
| at this point).
|
| For anyone that wants this: these kinds of plugins are
| usually called "which key" after the Emacs mode. Most of the
| Emacs distros ship with which-key by default and it works
| very well with evil.
|
| I get the sense that they're less popular on the Vim end,
| though I'm not sure why.
| ARandomerDude wrote:
| Vim is simple but not easy.
|
| https://youtu.be/rI8tNMsozo0
| rackjack wrote:
| Vim is user-friendly the same way Unix is user-friendly: it's
| not. It's user-centric.
| williamdclt wrote:
| Absolutely agree that it's not a user-friendly text editor.
| It _does_ increase productivity when you're proficient. TBH
| being proficient took me a lot of time, mostly fueled by
| wanting to be cool in my first job (it failed), all in all
| I'm not entirely convinced it's a good investment.
|
| But being able to edit using Vim at all is very very useful
| to edit files on servers, which happens very often in various
| situations.
| chousuke wrote:
| I would say that vi (at least the more modern ones) is user-
| friendly, but not _beginner-friendly_. You really do need to
| start by running vimtutor.
| saagarjha wrote:
| Eh, I wouldn't even call it that. I consider it to be
| similar to git: you can do some incredible things with it,
| and people who know how to use it can do so effectively,
| but there is a lot of room for improvement.
| chousuke wrote:
| I have the same feeling of limitation when using Windows. As
| someone who's used to Linux and other UNIXy systems, the idea
| of having and using GUI software _on_ servers is... distasteful
| to me, to put it mildly. GUI configuration makes changes easy,
| but change management extremely difficult, which is not a good
| combination. Therefore I struggle with administering Windows
| because there is _no_ useful editor by default when you use it
| remotely over the console, leading to a lot of friction to just
| "browsing around" on a remote Windows machine, and most of the
| time installing what I need is not an option due to the lack of
| a default, trusted package manager. (though that might be
| changing, finally)
|
| While PowerShell is, well, powerful and nowadays there's at
| least OpenSSH for for secure and convenient remote access,
| unfortunately it's rarely installed and PowerShell over SSH is
| still very janky and even when it's there, many things assume a
| GUI, which is anything but convenient to me. My workflows tend
| to use SSH all over the place to make remote access
| transparent.
| skrebbel wrote:
| Btw fwiw I fully agree with you. I really like Windows as a
| desktop OS (or, more accurately, I dislike it the least), but
| the idea of using a GUI based server is just super weird to
| me.
|
| Even pre micro I preferred Linux for servers, for this reason
| primarily. I understand Linux way less well than Windows but
| I navigated down that insane ISS config panel once, a decade
| ago, and decided that once was enough :-)
|
| Given Windows' low popularity as a server OS these days it
| seems to me that plenty devs-who-use-Windows have a similar
| opinion.
| coldtea wrote:
| > saving me from having to Google "how to find text in vim"
| every time
|
| Escape, slash, and write whatever you want to find, and press
| enter: [Escape]/foo[Enter]
|
| After a few weeks, you'll start trying to do it on every
| editor...
| themodelplumber wrote:
| Since I haven't checked on this one for 10 years now: How
| screwed am I for using Ctrl-c instead of Esc? Using nvim
| mostly these days
| xigoi wrote:
| ^C is not fully equivalent to Esc. It won't trigger
| InsertLeave autocommands and doesn't work with a count.
| coldtea wrote:
| I think most "hardcore" vim users do re-map Esc for
| something else, like Ctrl-C (or maybe it's a built-in
| alternative keybinding) or Caps Lock.
|
| I've used vim for 25+ years, but always alongside other
| editors (only used it as my main driver for 4-5 years
| sometime in the 90s), so I've always stuck with Esc (which,
| is the default anyway).
|
| That said, I wanna jump back on with Nvim 5.0 when I get
| the chance to have a free day to setup and configure it to
| my liking.
| mixmastamyk wrote:
| Yes, but not just a Windows native, a DOS edit, Netware,
| Motif/CDE native, similar to Mac OS dialects.
|
| IBM CUA, from mainframe terminals to OS2. Later Geany and
| Sublime Text, recently VSCode.
|
| Unix was earlier so didn't get with the program. I limped along
| with nano and a subset of vim for years. Noticed "ne" about ten
| years ago, was ok.
|
| Micro is a godsend and in the Ubuntu repos now. Debian too? Not
| sure.
| Matthias247 wrote:
| Even though it feels weird, it will still pay off to learn the
| very basics of vim. The reson for that is simply that its pre-
| installed on most environments - including servers and embedded
| linux devices, and available in a ssh session. On some of those
| environments it might not be desireable/allowed to install
| additional software.
|
| Basics for me is i,a,:q,:wq just be able to edit something and
| get out of the editor again. Adding d,y,p,/,^,$ makes it a bit
| more productive.
| rgoulter wrote:
| > Obviously the solution would be "just learn vim already" but
| I'm lazy.
|
| Vim keybindings are great. :) But I'd rather people learn vim
| keybindings out of curiosity rather than necessity.
| oblio wrote:
| Yup. Great, well balanced light editor with almost 0
| installation worries. Just copy the binary over.
| vanous wrote:
| The mcedit (editor from midnight commander) has been my choice
| of editor before I switched to vim. Thanks for the micro
| suggestion.
| Osmose wrote:
| Micro is my go-to git commit message editor, especially because
| it can correctly syntax highlight verbose-mode commit messages
| (passing -v to git commit will put the diff you're committing
| below your message as a helpful reminder).
| andix wrote:
| Does it have a vim mode? :D
| zerr wrote:
| EDIT.EXE is pretty intuitive. Pity that it was removed from
| Windows eventually.
| eismcc wrote:
| At point while on the Windows kernel team, I was working on a
| port of edit.exe but when I left the team, development stopped.
| I was initially going for a identical replacement with a
| replica menu system but behind able to handle large files,
| modern capabilities.
| jimmygrapes wrote:
| edit.com I thought it was
| Koshkin wrote:
| Less than 64K in size, unheard of now.
| eismcc wrote:
| Yes, that's why it needed a rewrite. Particularly in terms
| of handling large files.
| rashil2000 wrote:
| Thankfully, the author of Yori[0] shell has made a modern port
| of EDIT called, well, Yedit[1].
|
| [0]: http://www.malsmith.net/yori/
|
| [1]: https://virtuallyfun.com/wordpress/2021/03/03/yedit-the-
| miss...
| gigatexal wrote:
| I am super duper keen to try out any new text editors but I can't
| move away from vi bindings and the vi mental model. It's done
| more for my productivity than anything else and I think has
| reduced or rather pushed back the time when I will eventually get
| RSI as I can effectively limit the number of key presses to get
| something done.
| VHRanger wrote:
| When has the number of key presses seriously been the
| bottleneck for anyone when developing software
|
| Look I like mechanical keyboards and editor setups as well, but
| let's not pretend it's this great panacea. It just feels nicer.
| avgcorrection wrote:
| RSI has got nothing to do with "bottlenecks". You can get
| repetitive stress even if you aren't doing something at full
| speed or at full intensity.
| infinitezest wrote:
| I would be interested to see a serious comparison between the
| two. This debate comes up every single time that Vim is
| discussed and I'm honestly not really sure where I come down
| on it. As a Vim user I know that editing this way _feels_
| better and faster but I'm not sure how true that actually is.
| One thing that I can say for sure is that it has done wonders
| for my RSI.
| chillfox wrote:
| Same thing kinda goes for anything on the command line.
|
| The amount of commands that are 2-3 characters long really
| slows down learning and when it comes to it you will often be
| typing another 80 ish characters after the command name for
| options and piping anyway.
| achikin wrote:
| It's not about the number of keystrokes, it's about the
| number of keystrokes pressed simultaneously - this where Vim
| makes a lot of difference. All that Ctrl-Alt-Shift-X stuff is
| what really harms hands.
| theshadowknows wrote:
| Personally I spend a lot of time staring at code thinking
| "wtf was this person thinking when they did this...I know
| there was a reason but..what was it" (doubly so if I'm the
| one who wrote it). So I think you're right, unless there's a
| key binding to read minds too :)
| avgcorrection wrote:
| Clearly writing stuff was so much effort for them that
| they/you couldn't be bothered to comment the
| code/document/make a good commit message.
| xyzzy_plugh wrote:
| What on earth are you talking about? The whole point of all
| these tools is to reduce the amount of key presses needed.
| Why do you think ed -- the standard text editor -- was
| conceived? I jest but this is kind of the whole point of
| modern computer interfaces vs typewriters and punch cards.
| Historically it has _absolutely_ been a bottleneck, and I
| feel like it's being taken for granted that you can search-
| and-replace or use sed or your IDE's context-aware
| renaming/refactoring.
|
| Have you even used macros in vim (or whatever)? It's
| practically a modern editor's _raison d 'etre_.
| TLLtchvL8KZ wrote:
| Doesn't seem to be mentioned yet but at least on my machine, it
| knows shellcheck is installed and as I save scripts I get red
| arrows at the side of "problems" and the description, for eg,
| Quotes/backslashes will be treated literally. Use an array.
| [SC2089]
|
| At the bottom, I find it quite useful although I'm not sure how
| one would turn it off as I didn't turn it on.
| kirillbobyrev wrote:
| This looks nice but I can't what the target audience and intended
| usage patterns are. It's somewhere between
|
| 1. "simple text editor to use on servers/whenever I need to edit
| something quickly". That place is taken by nano that is easy
| enough so that people don't have to learn it, or vim for those
| who mastered it. In this niche it's important for the editor to
| be ubiquitous enough and present even on the old machines.
|
| 2. Regular day-to-day code editor. Micro has _some_
| autocompletion, syntax highlighting etc. But for a modern editor
| to function, it really needs an LSP client implementation. But
| this seems to not be happening so far:
| https://github.com/zyedidia/micro/issues/1138
|
| Micro has some features in each bucket (simplicity, ease of usage
| vs. IDE-like features) but does not seem to really excel at
| either.
| mixmastamyk wrote:
| It runs everywhere and uses keybindings available everywhere
| else. It's not an IDE. Basically can take over all simple to
| medium editing tasks. i.e. a no-brainer.
| kortex wrote:
| > In this niche it's important for the editor to be ubiquitous
| enough and present even on the old machines.
|
| Why are people still treating this like a deal breaker? It's a
| static go binary, if I can ssh to it, I can scp micro to it, or
| more typically just curl the latest release from GitHub into
| ~/.local/bin (no sudo!). Just like you'd do with your vimrc.
|
| Apparently this is controversial.
| kirillbobyrev wrote:
| Because sometimes I can't download binaries from the internet
| and sometimes... well, I don't have the internet! One
| scenario for the latter is installing an OS from scratch.
|
| One might call me lazy but I don't want to end up learning
| multiple editors for different scenarios if the benefits are
| marginal, especially if I can get away with just one!
| makeworld wrote:
| I use Micro as a better Nano. The syntax highlighting is
| better, the copy pasting is better, and most of all, the key
| bindings are the ones I'm used to. I can use Nano fine, but
| Micro is much more intuitive.
| NelsonMinar wrote:
| Awesome! I keep looking for the perfect solution for this. I use
| GUI editors for real projects but when I need to quickly edit a
| config file on a remote machine I currently use mg.
|
| It's not bad but it doesn't support Unicode. It's also nearing 35
| years old now and while that has its advantages maybe something
| more modern would be better. The main reason I still use it is
| that it has emacs keybindings which sadly are seared deep into my
| brain.
| donio wrote:
| I use godit as my microemacs. It's written in Go so you get a
| statically linked executable, easy to cross-compile and it
| supports UTF-8.
|
| https://github.com/nsf/godit/
| beepbooptheory wrote:
| The things people build to avoid learning vi...
| Meekro wrote:
| I love my laziness, and won't give it up. =)
|
| I've already switched to this. Installing and configuring it
| was a lot easier than learning vi would have been.
| emptyparadise wrote:
| "If I had asked people what they wanted, they would have said
| faster emacs."
| quickthrower2 wrote:
| Or a typewriter with grep support.
| legends2k wrote:
| Nah... they use Emacs server now :P
| kortex wrote:
| I wish people would stop treating vi like it's God's gift to
| every programmer on earth. I forced myself to use it for two
| weeks just to see what the fuss is all about and try to push
| through any bias.
|
| So first off I use Dvorak so I have to switch tons of the
| bindings so I can use reference layouts. My moonlander keyboard
| already gives me directional movement on home keys. I don't
| have a ton of things to automate that I cant do in Alfred and
| my keyboard has over 1000 possible slots for keys and macros,
| more than I could ever use. Unlike Alfred workflows, the macros
| are trapped in vim. I have to add a ton of plugins to get
| anything approaching the experience of Pycharm and now it's
| just as slow, the auto completion is worse, and it looks like
| ass. But hey at least I can use it over an ssh connection
| (gotta transport all of my config first!), as if sshfs is not a
| thing, not that my work load is all cloud containers so I
| rarely ssh at all anyways.
|
| Micro fills a niche for me where I don't want to leave the
| terminal and just need to edit a few lines.
| pantulis wrote:
| I wish people would stop treating Dvorak like it's God's gift
| to every typist on earth.
|
| (Sorry, just joking, could not resist :P)
| throwawaybutwhy wrote:
| Ah ok. The usual editor wars. There's one point that has to be
| made: software lives or dies (or withers on the vine) due to
| network effects. In the case of Micro vs Vim vs Emacs it's all
| about keybindings and the time to learn them. Micro uses CUA [0]
| keybindings intuitive for most Windows users, while Vim and Emacs
| (cua-mode notwithstanding) are stuck in the middle of shallow
| local optima.
|
| [0]
| https://web.archive.org/web/20010107084700/http://publib.bou...
| Kessler83 wrote:
| I'm sure Micro is great, but I doubt it's anywhere even near
| Vim or Emacs, in any respect. Because it's not "all about
| keybindings," and claiming that either of those editors is
| stuck in a local optimum is simply counterfactual. As for
| living and dying, Vim is 30 years old and Emacs is 45 years
| old. We'll just have to see how long Micro stays in the game.
| donio wrote:
| But on the other hand a very large chunk of those who would
| ever consider using a non-GUI text editor come from a vi or
| Emacs background.
| [deleted]
| _def wrote:
| Tangent: I noticed more and more projects advertising a single
| executable as a way of distributing their apps. I don't want to
| judge, it's just another way of doing it, but I'm curious: is
| this a trend and what led to it? I feel like I missed something.
| theonemind wrote:
| "I tend to think the drawbacks of dynamic linking outweigh the
| advantages for many (most?) applications." - John Carmack
|
| http://harmful.cat-v.org/software/dynamic-linking/
| saagarjha wrote:
| n.b. John Carmack is a game programmer.
| gnuvince wrote:
| Single executable files are very nice because you don't need to
| run `apt install <14 dependencies>` to try a piece of software,
| you just try it and if you don't like it, you delete it without
| any cruft left on your system.
|
| Go and Rust are two languages whose compilers produce
| statically-linked executables and they are growing in
| popularity, so you should expect to see more and more of these
| kinds of programs. And as these programs become more spread, I
| expect that other languages (either existing or new) will make
| it easier for developers to distribute their projects as single
| files.
| nrclark wrote:
| Slight off-topic, but I wanted to address the above concern.
|
| APT, DNF, and many other package managers have an
| "autoremove" command that will uninstall unused dependencies.
| So if you did "apt-get -y install $PACKAGE && apt-get -y
| remove $PACKAGE && apt-get autoremove", you won't have any of
| $PACKAGE's dependencies hanging around after.
| gnuvince wrote:
| True. The scenario I was thinking of was `./configure &&
| make && sudo make install` and iterating on all the missing
| dependencies that the configure script flags.
| marmaduke wrote:
| Seems like a trend to me, enabled in part by tool chains like
| Go's which make it easy. I like them because using/deploying is
| simple: put the file somewhere and run it. No apt get runtime
| library config etc etc to worry about.
| neurobashing wrote:
| if I had to guess: things like Docker, K8s, and Lambda. All of
| them make installing sprawling apps with tons of dependencies
| really troublesome at best. A single executable with almost no
| dependencies really simplifies that problem.
| hasmolo wrote:
| this feels like the natural evolution if container based
| deployment. people have gotten focused on a "single thing that
| works everywhere" to the point that we are back to having
| binaries include all dependencies instead of making it clear
| what the host system needs.
| TingPing wrote:
| Go doesn't support shared libraries. The community likes it...
| vesche wrote:
| I tried Micro on for size for a few months earlier this year. I
| like it a lot, but stopped using it over time. Any time I reach
| for a text editor I kind of muscle memory open vim if it's
| something quick or VS code if it's a larger project.
|
| Micro is like nano re-built for the 2020's. It feels really
| natural to use with sane key bindings and text selection. I like
| that it's written in Go and has a nice plugin framework. I might
| have used it more if a file manager / code tree off to the side
| was a built-in feature. I found a plugin that could do it, but I
| had some hassles with it iirc -
| https://github.com/NicolaiSoeborg/filemanager-plugin
| mixmastamyk wrote:
| Rebuilt for the 1980s IBM CUA. :-D
| JasonFruit wrote:
| > curl | bash
|
| I hate this. I know everyone's doing it, but it's just awful.
| Read the script, then run it.
| speedgoose wrote:
| How is it different than running a binary you just downloaded?
| jtth wrote:
| you can do this when the installation is presented this way
| pkphilip wrote:
| This is really nice! Very easy to use and a very pleasant
| surprise! Congratulations!
| mhd wrote:
| For a while, I recommended the fte editor[1] to people coming in
| from the Windows/DOS camp, but that went out of development quite
| a long time ago. Good to have a go-to non-proselytizing
| replacement that works in a terminal and isn't nano.
|
| [1]: http://fte.sourceforge.net
| drran wrote:
| mc + mcedit is much better for those, who came from DOS camp.
| Aeolun wrote:
| Just in case one of the maintainers sees this. Searching for
| plugins name or description is case sensitive.
| capableweb wrote:
| Just in case you weren't aware, the project is open source and
| hosted on GitHub, where you can also find their issue tracker,
| if you really want to reach the maintainers:
| https://github.com/zyedidia/micro/issues
| le-mark wrote:
| Very helpful response, but generally I think the set of
| people who refuse to learn vi/vim is orthogonal to the set of
| people who are willing to go seek support!
| kseistrup wrote:
| Does `micro` have an "insert file at current cursor position"
| now? It didn't when I last tried out the editor, and that was a
| showstopper for me.
| stevekemp wrote:
| Just looking at the documentation nothing jumps out, but
| reading the plugin reference it seems like it would be an easy
| thing to add.
|
| You have access to read a file, you can get the current buffer,
| so inserting the text must be almost trivial.
|
| It seems like an odd showstoppper to have, but if you're
| tempted to switch writing the plugin might help you get a feel
| for how good the editor is in other ways.
| revscat wrote:
| Why don't you write a script that does that?
| kseistrup wrote:
| Perhaps I don't have the skills for doing that?
|
| I gave micro a try because I thought it looks like a nice and
| somewhat intuitive text editor, but I regularly need the
| "insert file" function.
| 95014_refugee wrote:
| Shell out, 'pbcopy < file', paste, done.
| mixmastamyk wrote:
| Can probably be run with Ctrl+E, aka Cmd, in micro.
| atombender wrote:
| For a couple of decades, my go-to terminal-based editor has been
| JOE (Joe's Own Editor). [1]
|
| JOE has everything I need -- it's fast, it has syntax
| highlighting, multiple buffers, etc. Also, it uses the WordStar
| key bindings, which are the same bindings used by Turbo Pascal
| and the other Borland IDEs that I grew up with.
|
| But Micro looks great, too.
|
| [1] https://joe-editor.sourceforge.io/
| vanderZwan wrote:
| I really appreciate that he ends the page with links to other
| editors to consider, in case his doesn't fit someone's needs
| donio wrote:
| JOE is where I started my Unix editor journey, the Wordstar
| bindings were familiar coming from DOS and Borland tools. From
| there I went on to jed which also had Wordstar support and it
| gave me a taste for extensibility. Jed's native keybindings
| were based on Emacs though so I eventually arrived to the real
| deal and it has been Emacs ever since then. But also learned vi
| basics along the way of course. :)
| garyrob wrote:
| I feel the same way, I use JOE's jstar mode because I fondly
| recall using Wordstar under CP/M, and it has enough features
| for basic editing.
| vanderZwan wrote:
| > _JOE 's jstar_
|
| Is that an intentional reference to JoJo's Bizarre Adventure
| or just a wonderful coincidence?
| garyrob wrote:
| I don't know JoJo's Bizarre Adventure, I think it's a
| bizarre coincidence!
| jlundberg wrote:
| Been using JOE in it's jpico form for many years now.
|
| What got me started was actually how much faster it is on a
| Raspberry Pi compared to nano.
| deltafourone wrote:
| I'm looking for Clion/Pycharm level quality code analysis and
| features in a terminal form factor. Does this solution exist? Can
| it exist? Will it ever exist?
___________________________________________________________________
(page generated 2021-11-06 23:01 UTC)