So, let me get this straight

>so I don't know how that could be its salvation.
Have a concrete example: Automatically removing trailing whitespace on save

In vim:
function ShowSpaces(...)
let @/='\v(\s+$)|( +\ze\t)'
let oldhlsearch=&hlsearch
if !a:0
let &hlsearch=!&hlsearch
else
let &hlsearch=a:1
end
return oldhlsearch
endfunction

function TrimSpaces() range
let oldhlsearch=ShowSpaces(1)
execute a:firstline.",".a:lastline."substitute ///gec"
let &hlsearch=oldhlsearch
endfunction

command -bar -nargs=? ShowSpaces call ShowSpaces()
command -bar -nargs=0 -range=% TrimSpaces ,call TrimSpaces()
nnoremap :ShowSpaces 1
nnoremap m`:TrimSpaces``
vnoremap :TrimSpaces

emacs
(add-hook 'before-save-hook 'delete-trailing-whitespace)

Sorry, to *show* trailing whitespace and auto-delete on save.
The emacs snippet should be
(setq-default show-trailing-whitespace t)
(add-hook 'before-save-hook 'delete-trailing-whitespace)

>But Emacs is a better editor than Vim already out of the box, seriously.
>Modal editing is an ancient technical limitation of the past where modifier keys were not universally available.
If that's your opinion, fine, but I'll be sticking to vim if it does modal editing better.

>And yes, setting indentation size for a language is piss easy. Example:
That doesn't seem piss easy. Why isn't there one variable used for all modes?

>Notice that I'm purely talking about Emacs, the editor. Don't even get me started on the rest of its functionality.
Don't care, already have dedicated programs for non-editing things

>Literally false
This was referring to "global-use-line-number" or whatever that wasn't around in the earlier versions

Also yes I haven't used Emacs that much so I indeed am wildly uninformed. That's why the thread's made desu

>Everything beyond that becomes an eldritch clusterfuck nightmare
Doesn't really have to, just don't install neotree-like plugins. That stuff is already handled by your OSs file editor. If you want IDE capabilities, just install a LSP client on either editor, that's literally it. Both can do it just fine.

B-but Uriel told me Emacs is b-bloat...

Well, thanks for the example, though for a simple case like this I don't think either editor is gonna have much trouble

function! RemoveTrail(mode)
let g:prevPos=winsaveview()
let g:prevSearch = @/
exe a:mode."s/\\s\\+$//e"
call winrestview(g:prevPos)
let @/ = g:prevSearch
call histdel('/', -1)
endfunction

insights.stackoverflow.com/survey/2018#technology-most-popular-development-environments

you can see the same thing in reddit: 80k vim users vs 30k
and vim has several extra subreddits

when emacs community stick with emaclisp instead of using and boosting sheme, they probably doomed both projects

Attached: Screenshot_20190514_173742.png (711x686, 33K)

I'm not sure what line number system you're referring to. Do you mean old-school GOTO 10 line numbers down the entire column?

>Doesn't really have to, just don't install neotree-like plugins.
So don't install plugins. Got it.
>That stuff is already handled by your OSs file editor.
What?
>If you want IDE capabilities, just install a LSP client on either editor
Or I could *not* run entire backend daemons for every single language I work with and hope that their interop isn't a mess. I don't want to boot up an entire eclipse backend to edit Java files sanely.

I don't write vimscripts so I just grabbed the first thing off the wiki I saw. But you can't tell me you think that and the emacs equivalent are equal in simplicity.

>insights.stackoverflow.com
Yes and Javascript is the worlds most popular language for developers and ruby will pay you $110k if you use it.
There was another study that found people who used emacs were overwhelmingly more likely to be hired, so take that for what you will.

>if it does modal editing better
Emacs (evil-mode) does modal editing better than vim does.
>Why isn't there one variable used for all modes?
Did it ever occur to you that different languages could use different ways of indenting your code? Not to mention how language modes (being Lisp functions and thus defining arbitrarily complex code) can do much more than change mere indentation.
>Don't care, already have dedicated programs for non-editing things
I guess you can enjoy your disparate programs trying to mimic vi-style keybindings then, while I can get the full power of an actual text editor with all of my personal keybindings and conveniences when dealing with git (look into magit, it's seriously the best git client you could get), mail, the shell, or any other shit you use a terminal program for.

>I haven't used Emacs that much
I can tell.

The line number thing basically means being able to see the absolute number of the current line, and relative numbers of all other lines
reddit.com/r/emacs/comments/6drfjz/is_there_a_good_solution_to_relative_line/
emacs.stackexchange.com/questions/19532/hybrid-line-number-mode-in-emacs

>So don't install plugins. Got it.
Don't install plugins that try to turn your editor into a file browser or something that's not an editor. Also, the rainbow parens plugin should work just fine, but I don't see why you'd need it, Vim comes with matching parens highlight by default and formatting will make rainbow colored parens unnecessary even for lisps.

>Or I could *not* run entire backend daemons for every single language
You really don't need with Vim either. It works fine for any language as is, it's pretty language-agnostic as an editor, unlike Emacs. If you need those IDE things you were talking about, press a shortcut to fire up the language server.

> But you can't tell me you think that and the emacs equivalent are equal in simplicity.
Well, the emacs equivalent is basically just a convenience function that hides all the stuff the vimscript you posted does. How would you change the conditions before-save-hook fires under (for instance disable to it with a shortcut or for a filetype), and how would you use it to highlight whitespace? You could make a similar function in vimscript, but it would be similarly hard to customize.

You said Emacs was "dying". I told you it isn't. Now you're trying to move the goalpost by implying I somehow said Emacs is the most popular editor ever, which obviously isn't the case.
Fact is, Moolenar has zero plans for Vim once he leaves, and that matters a lot more for the future of the project than the number of its users.
While I would have preferred Emacs to switch to Scheme sooner, both Emacs and Guile are actively developed projects, with no sign of dying anytime soon.

>I'll be sticking to vim if it does modal editing better.
Emacs can do modal editing as well if you prefer it, and probably does it better. Apart from the usual evil-mode, check out Xah fly keys for an alternative modal mapping.
The guy is retarded in general (he literally has a page dedicated to talking to porn on his personal website!), but boy did he come up with good keybindings.

>Don't care, already have dedicated programs for non-editing things
Certainly you do, but here is the thing: what's really good about Emacs is not really, as most people who don't use it seem to believe, merely doing a lot of things. It's integrating those tasks seamlessly and effortlessly.
Just programming with a language which has a REPL is much better in Emacs than with any other editor I've seen (as a simple example, evaluating a certain portion of code is instant). There are plugins for other editors which try to mimic this functionality, but none are as good.
And Emacs is not replicating these programs' functionality: it's simply gluing them together.

>it would be similarly hard to customize
Yeah, this is so hard.
(add-hook 'c-mode-hook
(lambda () (add-to-list 'write-file-functions 'delete-trailing-whitespace)))

>Emacs (evil-mode) does modal editing better than vim does.
See, now this is what I was talking about. I don't see how it does, I just don't. Most Vim things feel "forced" on Emacs, it just isn't built up to be a modal editor. Can't even bind multi-key combos like "gyi" to actions.

>being Lisp functions and thus defining arbitrarily complex code
You could write the same stuff using vimscript autocommands, but for some reason Vim people aren't as obsessed with isolated and non-interoperable modes for every different task.

Also yeah, it's true I'd rather use git through the terminal and a GUI than a text editor. Same goes for everything else, really. If that's what you're after, I don't see what Emacs brings to the table that Vim doesn't do fine.

neovim will just fully take over

>relative line numbering
I still don't understand what that means.
What the hell is a relative line number? A line number is a line number, either I'm on line 87 or 88, there's no line 6 relative to 87. That's just line 93.

>Don't install plugins that try to turn your editor into a file browser or something that's not an editor.
What? Do you never, ever work on large projects where having access to a filetree is handy? You don't open other files while already in vim? You work solely on one file, save and close, then open the next one?

>but I don't see why you'd need it, Vim comes with matching parens highlight by default and formatting will make rainbow colored parens unnecessary even for lisps.
A) That's not what rainbow-highlighting does. It colorizes all the different variables within their scope to make them easier to differentiate. It's a pretty common plugin, I like it. It doesn't colorize parens.
B) Emacs also comes with matching/electric/highlighted parens so, ok.

>You really don't need with Vim either. It works fine for any language as is, it's pretty language-agnostic as an editor, unlike Emacs
You literally just told me to run an entire language backend and hook it into either editor instead of letting the editor do language-based tasks. Emacs is 100% language agnostic, do you even know what you're talking about?

>How would you change the conditions before-save-hook fires under
Here's one to only trim trailing whitespace in C
(add-hook 'c-mode-hook
(lambda () (add-to-list 'write-file-functions 'delete-trailing-whitespace)))

>but for some reason Vim people aren't as obsessed with isolated and non-interoperable modes for every different task.
It's because vim doesn't fuckin support it. You can write commands for vim but it has no concept of modes, you can't just write arbitrary functions and helpers and conveniences for particular languages and hook them into the language mode. There is no language mode. Vim is fast because vim is dead simple. It's one step above nano.
If you want something more than "modal nano" then you use emacs. That's literally it.

>If that's what you're after, I don't see what Emacs brings to the table that Vim doesn't
Have you ever used Visual Studio or IntelliJ? Know how they have all these stuff integrated right in for you? that's what emacs offers over vim. Integration. It's all there. Right there always. I don't need four different applications and a separate VCS program to manage my program codebase, I don't need a whole separate editor to write in Java vs Haskell vs C.

If you WANT to use 9 different programs in your workflow then yes, emacs offers you nothing. But neither does vim, you may as well just use nano.

>What the hell is a relative line number?
Relative to the current location of the cursor. The line above the cursor is line "1", the line above that is "2", etc. It's useful for Vim / evil mode users who want to type "2k" to go to 2 lines up.
>What? Do you never, ever work on large projects where having access to a filetree is handy?
Yeah I do, and I use a file manager for that. I can have several windows of that open, and I usually have a few editor windows open simultaneously. It's what the OS's window manager was made for, and it feels much comfier than trying to navigate the entire thing through one application.
>A) That's not what rainbow-highlighting does.
Oops, wrong plugin then. That's not a feature I'd personally still want, though.
>You literally just told me to run an entire language backend and hook it into either editor instead of letting the editor do language-based tasks. Emacs is 100% language agnostic, do you even know what you're talking about?
Vim is language agnostic since it doesn't try to make special accommodations for every single file type ever with different modes, there's only basic things by default like syntax highlighting. Everything else you can configure with .editorconfig, and all the language-specific features you get for realsies through an LSP server for any language with a client available (i.e. any relevant language).

>feel
What do you mean by that? "feel" for whom? For someone who admittedly hasn't used emacs and is just projecting some kind of retarded mix of Stockholm syndrome and sour grapes onto "new" technology?
>Can't even bind multi-key combos like "gyi" to actions.
This is blatantly false.
>You could write the same stuff using vimscript autocommands
You could, but why would you? Vimscript is fucking garbage, and there not being vim alternatives to magit or org-mode is proof of that.
>isolated and non-interoperable modes
Is that why there are so many modes and packages in emacs which build upon each other?
>I'd rather use git through the terminal
How is using git through the terminal more efficient than using magit from within your text editor?

Attached: 1551987182916.png (449x442, 197K)

>It's because vim doesn't fuckin support it
How so? You can make a vim autocmd that calls a function that saves the previous state of every variable and setting, then does whatever you want it to. That's literally what filetype-based plugins do. What's vim lacking here?

>integration
I don't want integration, whatever that means. I want a text editor that's predictable, is efficient to use, and does the things I need it to do, while occasionally also being able to interact with the semantics of the language through LSP. That's really all an editor needs to do, and I don't see how Vim's not sufficient for that.

>Relative to the current location of the cursor.
Given that this is pretty much an idea exclusive to modal editing, which emacs was not built around, it doesn't surprise me it's only a recent addition. It probably took the recent improvements to evil-mode and the flood of vim users bitching about it to defeat the "just press C-n twice...?" argument.

>I have several file manager windows and several windows of vim open all at once
I feel like nothing anybody says to you will matter at this point because you're still operating like an actual mongoloid. I don't even know where to start with this. You literally may as well be using nano, even vim users would tell you this is fucking retarded. Vim has a buffer system, you know that right? And it has a built-in file navigator just like literally every text editor past nano, right?

>Vim is language agnostic
*So is emacs*
What the fuck do you mean by language agnostic? Emacs detects file extensions and will auto-trigger a mode. You can just *turn the mode off*. Hell, you can turn any other fucking mode you want on.
>Everything else you can configure with .editorconfig,
Oh so you have to CONFIGURE it? Like you seem to think is insane?
>all the language-specific features you get for realsies through an LSP server
Which is FUCKING STUPID and generally unreliable.

I honestly don't know what to say to you since you don't even make use of vim. You also seem to think spinning up entire backends from other IDEs is a preferable alternative to letting your text editor do its job, so.
I dunno man. You seem to just be stubbornly stuck in your position of THE TEXT EDITOR SHOULDNT DO ANYTHING. MREH.

>what do you mean by feel
Things like relative line numbers just working OOTB.

Does the emacs keybinding scheme support mapping "gyi" and gyu" to different functions? I remember hitting a wall there.

>is efficient to use
see last point of >does the things I need it to do
Emacs can and will do precisely what you need it to do.
>occasionally also being able to interact with the semantics of the language
Why "occasionally"? Do you enjoy writing code in a crippled program which doesn't understand what you're writing on more than just the surface/syntactic level?

Configuring emacs is really easy though, I mean for gods sake my entire dotfile set is contained in an org mode file so its complete literate programming.
I'll give you the lack of a global indent that's mode overridden is kind of annoying, but the mode concept is excedingly powerful. Major modes that define an overall "scope" of the buffer with minor modes that interact with said mode is a very comfy modular layout.
Can't comment on mixed line number styles as I use relative and check overall buffer position in my modeline or with nyan.
Async does exist, and it's pretty nontrivial to add as a package.

Emacs is more configurable because its entire paradigm is a lisp machine. Practically everything but the very internals of the editor are exposed and modifiable at runtime, with a lisp language.
This model let's you very easily write powerful additions to the editor with minimal effort compared to vimscript. I'd like to see anything with the scope of org in vim.
Emacs is also very easy to configure as an editor, install evil and evil collection, keep your dotfiles under org and you're cozy and set for life.

>You can make
can. nobody does for the reasons I stated. It's a gigantic pain in the ass. Emacs has a kajillion minor and major modes because they all interop and hook together seamlessly and easily.

>I want a text editor that's predictable
Literally every single text editor
>is efficient to use
Subjective, but also literally every single text editor if you make use of its features. And since you don't even use vim buffers, you're not doing that anyways.
>and does the things I need it to do
Which is apparently "accept keystrokes"
>while occasionally also being able to interact with the semantics of the language through LSP.
So you don't want it to do anything on its own and desire instead a huge, slow, backend from a DIFFERENT IDE that you could be using instead to just float around in the background.

If you want a glorified notepad that can interop with eclipse then sure, use vim. Hell use ed. Pretty sure somebody has hooked that in at some point.
You're basically asking "why should anybody use emacs" when you yourself don't even make use of what vim offers you, of course you're going to think it's insane.

>OOTB
Why make this retarded distinction? Do you lack the brain-power to configure your editor?
>Does the emacs keybinding scheme
There is no such thing if you mean "set-in-stone" emacs keybinding scheme. You can change virtually everything about the editor.
>support mapping "gyi" and gyu" to different functions
I haven't tried it, but I know with certainty that it's possible.

>You literally may as well be using nano
Why would I? Nano has terrible UX, while using Vim is fast and comfortable. It's the editing experience I care about, not all the bells and whistles around it (like a fancier way to make git commits instead of just alt-tabbing to a terminal and typing "git commit -am 'whatever'") that take up 0.1 % of my dev time.

>using your OS's window manager is retarded
ok man. I'd much rather click or alt-tab directly to a window than first switch to my editor and the use its arcane buffering system to find what I need.

>LSP is stupid
Now who's the dumb one?

>Why "occasionally"? Do you enjoy writing code in a crippled program which doesn't understand what you're writing on more than just the surface/syntactic level?
Emacs doesn't have any deeper understanding of the language semantics without connecting a LSP server either.

Thanks for the constructive response!

>like a fancier way to make git commits
Can you easily (in 3-4 simple movements) selectively stage/discard hunks in a single diff and commit it from the terminal? I'd be genuinely curious to hear your solution for that.

>like alt-tabbing and typing git commit -am "whatever"
Or you could slap three keys and enter your commit message and have it happen without ever leaving the editor. The same editor that would also be used immediately in case of merge conflicts, allowing you to satisfy and resolve them with a message without ever changing windows.

>first switch to my editor
Why would anybody be "first switching" to emacs to do something? I have emacs open. It's in front of me. I am already editing a file. Why would I need to switch to it to open another file?

>Now who's the dumb one
You, apparently.

Imagine writing commit messages (i.e. editing text) in your terminal instead of an actual text editor.

A dedicated git GUI would be optimal for that, instead of trying to put the functionality into your editor. Too bad Linux doesn't have many good FOSS git GUIs.

But that's the thing, I don't commit so often it'd be worth it for me to setup and remember a custom keybind for it when I can just type it in and it won't make a difference on the time I spent in development. Meanwhile not having to constantly reach for a mouse and manually select things will build up to be a real time saver, but most importantly it's comfortable.

Why is switching windows a bad thing? That's one of the core functionalities of an OS, switching between tasks. Your DE might be configured badly if you fear window-switching, maybe you're using something like a dock even?

>Why would anybody be "first switching" to emacs to do something? I have emacs open
I don't browse through my editor, nor do I navigate files through it. This is what I've been talking about, I want it to just be an editor

I can omit the -m and write it in $EDITOR (vim) if I feel the need to. I don't have an issue using my terminal to enter commands (text!) though, especially since I have vi mode enabled

>Modal editing is an ancient technical limitation of the past where modifier keys were not universally available.
I honestly disagree. Modal editing made everything so much easier and convenient for me.
A mode is really nothing else than toggling a modifier key instead of holding it.

Just use nano.

Attached: mpv-shot0067.jpg (1280x720, 127K)

>A dedicated git GUI would be optimal for that
Yeah, that's what emacs has. A dedicated "GUI" which emacs spawns when you want to interact with git.
See youtube.com/watch?v=vQO7F2Q9DwA and try explaining how using a dedicated separate window for doing this is somehow more """"efficient"""" than opening magit from your source file.

You're comparing apples with oranges.
You're comparing an implementation of the equivalent function in vim with an interface to a pre-rolled function in emacs.
Not saying there is anything wrong with having that feature ootb, but it's like saying Python > every language because you can just import everything.

>I don't commit so often
>multiple filesystem windows
>multiple editors open at once
>alt+tab nonstop
There is officially nothing left I can say to you on a gregorian chant translation forum that is worth saying.
Your workflow is fucking retarded. If it works for you, great, use it. Use whatever you like.
But if you're gunna ask "why is X better than Y for my workflow" and proceed to shit on literally every reason why it's advantageous for workflow, including why the *current thing you use is not being used for your workflow*, then there's not a discussion or even an argument. It's just you saying IT'S NOT WHAT I HAVE BOOOO

>Meanwhile not having to constantly reach for a mouse and manually select things
you don't use a mouse in emacs...?

That's the first thing I found for vim by googling, which tells me it isn't built into vim.
We're comparing editors, not languages. I get your point but it's not quite equivalent in this context.

You can make a shortcut to launch a separate GUI program from your editor. Why try to put full git functionality into a text editor when a dedicated program can be more manageable and feature-rich? Same goes for file and web browsing, basically anything that's not related to the text buffer you have.

>Your workflow is fucking retarded. If it works for you, great, use it. Use whatever you like.
Says the guy trying to replace his OS with Emacs?

Yeah, I'm starting to get the point that the way I use Vim, it works perfectly fine and I really don't need to go through the hassle of switching to Emacs for basically very little benefit, unless I wanna do that later for fun.

>I want it to just be an editor
Is there any legitimate reason for wanting that? Cause I don't see any in this thread.

Using different programs for things they were made for, instead of trying to use one program for everything. Otherwise you're unironically using one of your programs as an OS and you end up with two layers of OSes. Ever heard the classic meme "unix is my OS"?

>Says the guy trying to replace his OS with Emacs?
At no point did I insinuate, imply, or indicate that.

>I really don't need to go through the hassle of switching to Emacs
Nigger you don't even use vim. You would be equally productive using notepad++, visual studio code, atom, nano, emacs, vim, vi, or a blind pipe from stdin to a socket from what you've described.

The Unix philosophy isn't about literal binaries you idiot

>dedicated program
Magit _is_ a dedicated (but not separate) program. The only difference with what you're describing is that you can actually access it from within emacs, since emacs wasn't built in a retarded way where it doesn't allow you to easily extend it. Why the fuck would you want to reinvent the wheel when making a new GUI for git when you could just use a program you interact with precisely the same way you would with your editor. You still fail to explain even such basic points of your retarded ""argument"".
>can be more manageable and feature-rich
>can
"epic".

>Nigger you don't even use vim
I very much do use Vim's bindings, registers and macros. I also have a few hundred lines of vimrc to make it even more efficient for my own needs.

>instead of trying to use one program for everything
Emacs isn't "one program which does everything". Emacs is merely a Lisp interpreter which runs other programs you feed into it. Like magit with git, or any other integration with any other software/OS functionality.

You don't use its file navigator or buffer system, you absolutely don't use vim. You're one of the stackoverflow statistics that is using vim as a notepad with some syntax highlighting but you don't actually use any of its benefits or features.
You would, and I shit you not, be just as well off with nano.

You're still having to navigate to emacs and then somewhere else inside emacs if you want to go from your browser to your tetris.

But I can extend Vim fine. Vimscript is annoying, but that's hardly a dealbreaker.

You tell me, why should every program be an emacs mode instead of a separate binary?

>But I can extend Vim fine.
Extend it to have something like org and magit.
>instead of a separate binary
All modes actually are separate binaries, or separate files with compiled byte-code, to be more precise.

No I don't, I go to tetris from my browser.

>why should every program be an emacs mode instead of a separate binary?
Not him but because that's slow as fuck. Compiling things down into a binary makes the binary fast, but binary interop has been and basically always will be infuriatingly slow. Build a program out of 1000 individual binaries and it's gunna chug.

To be fair, uriel would call Vim bloat too. He'd tell you to use acme, sam or ed.

>You don't use its file navigator or buffer system
I already have a file browser and terminal for that. Both are more flexible and powerful for their own purpose than either vim or emacs. Why would I need to regularly open file through Vim's limited file navigation to "be using Vim"? I didn't see Vim advertised as a file browser, it's an editor and I'm using it precisely for that.

>Both are more flexible and powerful for their own purpose than emacs
Will you actually prove this or are you just spouting retarded nonsense again?

>Why would I need to regularly open file through Vim's limited file navigation to "be using Vim"?
You...wouldn't, that's fucking insane?
What exactly do you think is being said here? I need you to tell me, in your own words, as plainly as you can, what you think is being said.
Because it sound like you think "vim is your filebrowser now!" is what's being said, and that's insane. And wrong. And you should take more ESL lessons.

I dont know what wiki youre looking at, but even so, the terseness and simplicity of regex recreates what your emacs function does in one line (from the wiki):
autocmd BufWritePre *%s/\s\+$//e
vim has first class support for regexes. And if you are too retarded for that you can always install a plugin

Okay, so emacs is better than your terminal, file browser, etc etc. How exactly aren't you just replacing your OS's window management with Emacs?

If you've got an issue with script performance, write it in a compiled language instead of an elisp interpreter.

>they aren't use acme

classic Jow Forums

vim.fandom.com/wiki/Remove_unwanted_spaces
this one, so I grabbed the first one I saw
which is, to be fair, the one most people are just gunna grab even if it's shitty.
I'm also gunna throw out the argument that even basic regex is still not as clear as the emacs alternative.

>If you've got an issue with script performance, write it in a compiled language instead of an elisp interpreter.
Reread the post.

>How exactly aren't you just replacing your OS's window management with Emacs?
I am, actually. I use EXWM on my laptop, it's an X window manager written in elisp.

Attached: 1555870138122.jpg (664x720, 98K)

>compiled language
There is no such thing, you mongoloid. Languages aren't "compiled" or "interpreted". Language _implementations_ can either be compilers or interpreters. Emacs can either compile .el source files to byte-code, or just interpret them.

And can you understand some people don't want to do that? This thread was about that, _not_ using Emacs as an OS.

Why would an emacs user need to do that if they don't want to? How is your post making any sense right now?

Point being, if a shell script is too slow, you can write it in any language that supports compiling to native binaries, and it'll be faster than an editor script being interpreted

The one liner is literally one section after the "function script"
>which is, to be fair, the one most people are just gunna grab even if it's shitty.
most people are retarded and will install a plugin (this applies to emacs too btw)
they are too retarded to read wikis
>I'm also gunna throw out the argument that even basic regex is still not as clear as the emacs alternative.
That's like your opinion man

>How exactly aren't you just replacing your OS's window management with Emacs?
Emacs works very well with tiling window managers. I use it with xmonad. A single Emacs instance can spawn several individual windows instead of internal panes, which still, however, share stuff such as clipboard, buffers, completion, etc.
Notice that this is different than using a client and a server.

What are you even trying to argue here? That you shouldn't use some software based on an interpreter just because it doesn't directly emit machine code? Are you writing hard real-time code in your editor customization files?

Addressing this
>Not him but because that's slow as fuck. Compiling things down into a binary makes the binary fast, but binary interop has been and basically always will be infuriatingly slow. Build a program out of 1000 individual binaries and it's gunna chug.
If binary interop is truly a problem, instead of converting every program into elisp, write your program in a different language, compile it to native code and use native libraries.

>Vim on the other hand is likely to die with Moolenar.
heard of neovim?
Also in the future it will neovim will be totally configurable with lua and vimscript will be phased out.

>instead of converting every program into elisp
How is writing new software which has some similar functionality to other software """converting""" programs into elisp?
>write your program in a different language
Why would I want to do that?

>neovim will be totally configurable with lua
fucking based

why not python tho?

do you happen to know by any chance

>lua
It's honestly not much better than vimscript.

>write your program in a different language
And lose most of the hackability emacs provides? You seem to know literally nothing about emacs, and yet you feel the reason to share your opinions for some reason.

>Languages aren't "compiled" or "interpreted". Language _implementations_ can either be compilers or interpreters.
This is literally, objectively true, and yet many people, even including prominent experts, seemingly refuse to understand it. Hell, even Stroustrup himself in his book calls C++ "a compiled language", for example.

>Modal editing is an ancient technical limitation of the past where modifier keys were not universally available.

Text-based interfaces are a technical limitation of the past where GUIs were not universally available.

This is true. And just like vim, UNIX weenies can't seem to progress past it.

That's right. That's why Emacs runs well in a GUI and provides additional functionality not possible in a terminal.
You didn't actually buy the "Emacs is a terminal editor" meme, did you?

>UNIX weenies
Kek.

Attached: 4500_john_mcCarthy_picture_2.jpg (700x700, 135K)

>additional functionality not possible in a terminal.

Such as?

Displaying images of cute girls in your editor.

Attached: witchmacs.png (674x626, 117K)

Right off the bat:
>additional color support
>additional font support (different fomts, sizes, etc.)
>images (useful for editing latex documents, seeing previews and such)
>spawning multiple frames instead of internal windows works much better for tiling window managers
>better mouse support
Sure, if you're constrained in a text-only environment such as a tty or a ssh session, you can use the terminal version only. Nothing wrong with it, it works fine.
But if you already have a GUI running, there is no reason to restrict yourself by not using the GUI version.

I'll utilize this chance to show off the Witchmacs website I've been working on:

snackon.github.io/witchmacs.html

Attached: witchmacs_icon.png (2200x2200, 1.83M)

There are evil people in this world who would call this bloat.
Never forget that.

Neat.

Attached: 057_1000.jpg (400x535, 43K)

Very cute logo.

Thanks
Please don't post 2d instead thanks

bump

Indentation is such a meme in emacs. Why is it so overcomplicated?

>Indentation is such a meme in emacs
Why would it not be? Indentation is quite literally an agreed upon social construct.

Because all of emacs operates off the idea that each language should have a mode with indentation logic to magically indent for you via the tab key. Why is indenting manually not the standard in emacs?

>Why is indenting manually not the standard in emacs?
Does this post even make sense to you as its writer?

I don't understand what the problem is? When you go to the next line it just copy pastes the same indentation/white-space then you remove or add indentation. It makes things so much easier across all languages, that's how Vim works.