Emacs

Attached: 2015-01-05-205931_1366x768_scrot.png (556x768, 38K)

Other urls found in this thread:

0x0.st/zeS1.txt
youtube.com/watch?v=JWD1Fpdd4Pc
twitter.com/SFWRedditGifs

emacs

emacs as a daemon

LMAO

EMACS FAGS ALWAYS BTFO FROM NANO

NANO MUSTARD RACE

TAKE YOUR (((PROGRAMMING LANGUAGE)))((AND STICK IT UP YOUR ASS))

FUCKING EMACS JEWS

based

Bloat.
>inb4 not bloat
Bloat is always bloat. Being bruteforced by newer computers doesn't change the fact bloat is bloat and worst of all promotes bloat.

Install GNU Nano.
>b-but muh emacs email and web browser
A TEXT EDITOR should NEVER be bloated enough to read fucking emails.

>A TEXT EDITOR should NEVER be bloated enough to read fucking emails.
Good thing emacs isn't a text editor then.

It isn't? What is it then

Stop being underage and maybe you'll find out.

mmm emacs

Attached: emacs.png (924x876, 35K)

You fucking retard.
>b-but what about "and more"
Its primary function is being a text editor, anything else is bloat. That the GNU project tries to spin it as a positive doesn't change how bloated it is.

Attached: retard.png (693x323, 46K)

Epic. Why didn't you just go with the "m-muh elisp interpreter" meme? You know, like every interpreter comes with a text editor, window management and GUI capabilities. Because that's what emacs is.

@71451950
>Its primary function is being a text editor
Says who? Some random shitstain on Jow Forums?

Low IQ.

I just do everything in mousepad

>Says who?
Emacs' official website. Don't you know how to read?

Attached: retard 2.png (693x323, 46K)

@71452022
>Its primary function is being a text editor
Where does anyone except a disabled kid on Jow Forums say that?

>you shouldn't have the option to do more things or it makes that bloat
just don't use that, if it's bloat, how does it harm your experience™ if someone else uses emacs for email and you just want to kode or whatever

Email (Gnus) involves text. And IRC (ERC) involves text, and reading PDFs (docview, though pdf-tools is better) involves text. Oh and dired manipulates files that contain text. TRAMP allows you to edit text remotely. "and more" - And you can view images, manipulate images, listen to audio with emms, oh and you can play games!

Fuck man, I love bloat wtf.

Cute. Can you post the rest of your config?

Attached: 1557660740589.jpg (800x600, 80K)

Browsing the web also involves text. That doesn't mean one text editor should try to absorb every program that even faintly relates to text. If you want to integrate your editor with your mail program or something, invoke it from the mail program or integrate it to the GUI, instead of shoving everything inside Emacs.

I'm not saying it's a bad thing that Emacs can do this or that it really affects me at all, but there's definitely something fishy going on with people who spend their resources turning Emacs into a software suite.

>If you want to integrate your editor with your mail program or something, invoke it from the mail program or integrate it to the GUI
Thank you for your feedback. I'll do that immediately, surely you know how this is better than a workflow you admittedly don't even use/know anything about.

emacs plus Windowmaker, good choice OP

Please point me to where Emacs is reffered to as anything but a text editor. All of the other shit it can do is always touted as additional ""functionality"".

Attached: emacs.png (962x659, 96K)

>Please point me to where Emacs is reffered to as anything but a text editor.
Can this idiot even read? I wonder if he's actually pretending to be retarded at this point.

You do you.

>this is better than a workflow you admittedly don't even use/know anything about.
If you're an expert, surely you can shortly describe what advantages doing everything inside Emacs has over using dedicated programs with more dev hours behind them?

>Browsing the web also involves text.
I wish there was a modern web browser which ran in emacs.

Font?

>surely you can shortly describe what advantages doing everything inside Emacs has over using dedicated programs
This has quite literally been done hundreds of times, even counting this website alone. I guess using a dedicated program to search the archive is too much to ask of you.

Yeah, right. You could've used those characters to type something concrete if you actually had it.

>If you're an expert
He didn't claim to be, you however, said "invoke it from the mail program or integrate it to the GUI, instead of shoving everything inside Emacs", so clearly you know a lot about this approach. Why would anyone want to do that? What benefits does it offer?

emacs is a good lisp interpreter!

I use it everyday, i love it!

Ask (your home website) to spoonfeed you. I'm not your mother.

I actually just use gmail with the web client for mail, so that point doesn't apply to me. However, I have this magical tool, the system clipboard, which enables me to paste text from my editor to my web browser with basically no extra effort if I wish to type it with a dedicated tool.

Most things I actually do use however, such as git, are easy to integrate with any program of your choice.

Does Unix garbage always damage your brain to the point where you can't see any other way software could possibly function well?

Attached: 1555795504683.png (545x370, 169K)

Sure, it's not much though considering I only program in Guile, Common Lisp, and Forth and these
don't really require complicated configurations. 0x0.st/zeS1.txt
Tamzen, bold!

>gmail
Not surprised at your absolutely abhorrent taste.

How does Unix not work well? It's basically gotten us this far.

Isnt emacs the systemd of text editors?

>which enables me to paste text from my editor to my web browser with basically no extra effort if I wish to type it with a dedicated tool
Classic Jow Forums-tier "minimalist" retardation. I've yet to see even a single person who calls emacs "bloated" and understands it on a sufficient enough level where he would feel like an idiot for comparing using it for email to just copying text from it.

It leaves a better impression than cock.li, and your emails should be considered public information regardless since the recipent will use a botnet provider anyway.

Attached: 2019-06-16-132837_502x43_scrot.png (502x43, 2K)

>his brain is so damaged he sees me claiming that "unix doesn't work well" in that post
Way to prove my point.

>It leaves a better impression than cock.li
Not surprised at your absolutely abhorrent taste.

I don't think Emacs is that bloated, I just think using it for mail or web browsing is stupid when the approach I just explained to you does the same things as the Emacs setup you spent 5 hours setting up, without any unnecessary learning curve.

Not him, but why should only a single program not obey the Unix philosophy in an entire Unix-like OS? In what way does it benefit the end user?

>and your emails should be considered public information regardless since the recipent will use a botnet provider anyway
This. That's why I use Windows 10, hardware manufactures will use botnet chips anyway.

Yes that's why the interface on every open source program is garbage.

>I just think using it for mail or web browsing is stupid
Do you have anything to back this up? How could you possibly know this when you're clearly ignorant on the topic?
>does the same things as the Emacs setup
Reread my post.

>unixtard can't even imagine that "software functioning well" can be done outside of a Unix-like environment
Way to prove my point.

I'm not really an advanced programmer but I'll say why I enjoy emacs: Everything is exposed, and everything immediately responds to your changes. With an environment that allows you to modify nearly everything and how easily every piece of code can "communicate", I end up in such a joy of a workflow. Extending my emacs environment is painless in the sense that it's very easy to get things running thanks to the immediate documentation and source code available to you. Elisp is generally a joy to work in for extending emacs, though I do hear it has some problems, and sometimes you run into the need of doing something in C. But that has yet to happen to me personally.

I'm not saying other editors don't provide this, I wouldn't know, I've only used emacs and vim and I didn't get the vibe that I could easily extend vim. If I wanted something in vim, I had to rely on plugins that did black magic or I gave up and only wished for that feature. In emacs, I can extend it myself and I'm only limited by my own abilities, not the environment. I do hear neovim is better but I wouldn't know, I just stick to emacs because its what I know.

And to the so-called "bloat"? I find it useful that my programs connect to each other. Email, IRC, Dired, what everyone already listed etc. All of that is a joy to work in and I can also easily extend them. They're not some separated islands that I have to figure out.

Just a noobs perspective.

Why should every program on a Unix-like OS obey the "unix philosophy"? In what way does it benefit the end user?

Logical separation of programs is neat.

Way to prove his point. What makes you believe that the "unix philosophy" is the only way to achieve this?

>Why should every program on a Unix-like OS obey the "unix philosophy"?
It's called "Unix-like" for a reason. If you install that type of OS, you want an Unix experience. And that includes its philosophy.
Are you familiar with "do one thing and do it well"? The same arguments that could be made against systemd could also be used against Emacs.
>In what way does it benefit the end user?
Less bloat, and everything intuitively works the same way.

>Are you familiar with "do one thing and do it well"?

Attached: Door-to-Door-Evangelism.jpg (500x342, 24K)

I didnt read your whole reply thread, only the one i responded to. I don't think muh unix philosophy is the only way to achieve logical separation, but its probably the most popular choice.

>unixtard _literally_ cannot imagine that something could intuitively work the same way and be non-bloated within a non-Unix environment
Way to prove my point.

When does something become bloat? If I use emacs for everything it provides, then is emacs still bloat? What if I install 100s of plugins into vim, is that now bloat even though i consider them useful? What if it's a well-designed and put together program that has a vast array of functionality? What in the fuck is bloat? I don't get it, help me anons.

>If you install that type of OS, you want an Unix experience.
Why are you telling me what I want? The only reason I use a Unix-like OS is that there are no alternatives right now.
>And that includes its philosophy.
I couldn't give less of a shit about following its philosophy.

>What in the fuck is bloat?
Anything not approved by either suckless or cat-v, i.e., absolute shit and unusable software like emacs.

Attached: slcon2017.png (1024x768, 407K)

>The same arguments that could be made against systemd could also be used against Emacs.
What actual and _concrete_ "arguments" have you made against emacs? Mentioning some random slogan isn't an argument.

Being an isolated subsystem inside your OS, even though your OS provides you everything for you to not need such an extra layer sitting on top of it
Its programs being niche compared to the software provided for the parent OS itself

Now, what are some arguments _for_ Emacs?

>Being an isolated subsystem inside your OS
Every userspace program following the Unix philosophy is _by definition_ an isolated subsystem inside your OS. Same with any programming language interpreter. This is not an argument.
>Its programs being niche
This is simply not an argument.

>Now, what are some arguments _for_ Emacs?
As soon as you make even a single concrete argument against me using emacs right now.

ah yeah well email is text too, retardo

>niche
I'm uninstalling my GNU OS and switching to Windows then.

>Every userspace program following the Unix philosophy is _by definition_ an isolated subsystem inside your OS.
I guess you have a point, but only if you do indeed use your Emacs installation as a mere interpreter and run your Emacs applications as individual windows on your OS. At that point I don't see how it's different from just using dedicated programs. If you're using everything from inside one dedicated Emacs window, you are indeed running a subsystem inside your OS.

And still, emacs programs are all built with Emacs' buffer editing and windowing APIs in mind. As such they're mostly text-based, unlike native programs built with GUI toolkits. Taking the time to learn the keybindings for every trivial program you use (such as a calculator or a git UI) is a waste of time if there's a GUI available.

Actually once you know all your commands using the emacs git and calc, for instance, are faster than moving your hand to your mouse and navigating through your window manager or whatever and opening your calculator or git client and then clicking on the proper menus and buttons and so on.

This is what I'm skeptic about - running a program requires hitting super and typing a few letters followed by enter, window switching is usually alt-tab or a direct click to a taskbar item. I don't see how putting my workflow inside Emacs' windowing system could possibly improve this, especially when I'd then have to move between Emacs and the rest of my programs in addition to navigating inside Emacs.

>individual windows
How low-IQ do you have to be to think of applications following the "Unix philosophy" to a higher degree merely because they're individual windows? Does using tmux violate the Unix philosophy now? You should really mail this to the suckless guys. In very simple terms, tmux "panes" are effectively how you work with multiple buffers at the same time in emacs, except it isn't all completely detached and is running from the same interpreter. You can split them into multiple individual X windows too, but I don't see how this makes them "follow the Unix philosophy" more.
>unlike native programs built with GUI toolkits
Emacs is a native program built with a GUI toolkit.
>Taking the time to learn the keybindings for every trivial program you use
You mean like you do with the dozens of Unix-like programs mimicking vi-style keybindings with subtle differences, and yet still never giving you full editing/navigational power of vi? Sounds retarded when I could just launch my shell/file manager/mail client as a legitimate "process" in the program I also happen to edit text in and have everything (as far as navigation/editing/etc. is concerned) already be exactly as I like it.

>running a program requires hitting super and typing a few letters followed by enter, window switching is usually alt-tab or a direct click to a taskbar item
This is painfully slow even for a non-emacs workflow. You should just have keybindings for doing your most common actions. You can obviously have the same in emacs.
>and the rest of my programs
There are emacs alternatives to most development/writing tasks (using these terms very loosely here). I don't see how using dedicated programs for the rest (modern web browser, video player, etc.) is an efficiency issue, you tab out from them to use other programs anyway, now you're just doing it less.

>How low-IQ do you have to be to think of applications following the "Unix philosophy" to a higher degree merely because they're individual windows?
Yes, running a terminal multiplexer inside a graphical WM is stupid. You're using a window managing system inside a window managing system, same as people do with Emacs.
>Emacs is a native program built with a GUI toolkit.
The programs run on it aren't native binaries, we were still talking about interpreting, right? About the GUI part, I've heard that implementation is not pretty - which isn't surprising, since this is a piece of software intended as a text editor first and foremost, after all.
>You mean like you do with the dozens of Unix-like programs mimicking vi-style keybindings with subtle differences, and yet still never giving you full editing/navigational power of vi?
If a program finds it reasonable to mimic a familiar interface of emacs or vim, fine, I'll take it. Most programs work fine with standard GUI conventions, though. That doesn't make the programs any less modular or less Unix. If you want the exact interface of your editor, the program should either offer support for launching it or integrating it into the GUI instead of the program being forced to be implemented inside your text editor.

>This is painfully slow even for a non-emacs workflow.
Huh. Certainly comprises an insignificant fraction of the time I spend using the computer. How could it be faster? By binding shortcuts to launch select programs? That would be just more stuff for me to memorize, when typing 2 keys of the program name already suffices.
>efficiency issue
The efficiency issue I was pointing out was mostly just potentially having to switch to Emacs and then to a program inside Emacs - two navigation steps, as opposed to one.

@71453478
You seem to have a terminal case of Unix-retardation where you are unable to actually think about what you read and why that might be beneficial. You don't present any actual arguments, instead you say "If you want the exact interface of your editor, the program should either offer support for launching it or integrating it into the GUI" with literally nothing concrete to back it up. What does "offering support" for your editor interface even mean? Why does a developer of a file manager need to """""offer support""""" for some interface when it could already gain that interface simply by virtue of running in an environment whose sole job is to provide that interface? How does "launching" emacs from an external program to use emacs to navigate that external program make any sense? Do you even think before writing this?

The first two points aren't even worth responding to.

>since this is a piece of software intended as a text editor first and foremost, after all
"citation needed"

no because you choose exactly how much of you workflow is done inside emacs, systemd sucks up everything it comes across

Attached: systemd.gif (426x284, 3.99M)

>That would be just more stuff for me to memorize
Yeah, I bet your brain can't handle such complicated stuff. That's a common problem among retards who shit on emacs when they demonstably don't understand it and yet still feel the need to argue about it for some reason.

>What does "offering support" for your editor interface even mean
Ever done a "git commit" without the -m parameter? Ever seen a "open in editor" button in a GUI app? Ever had your browser suggest you a program to open a downloaded file in? Some programs do indeed also allow rendering Vim _or some other editor_ as part of the GUI. This is modularity and integration - you can replace any component of the equation with another and still have them play together. The same isn't the case when you drink the Emacs cool-aid and shove everything inside the one opionated editor environment, and become unable to swap the editor part or one program running on it for something else (unless all the alternatives are programmed for Emacs as well).

Now, what concrete advantages does this Emacs paradigm of things offer in exchange for the loss of modularity?

Ah yes, and Emacs users have infinite memory? Every keybinding for your overly complicated email program is taking up space from something actually worthwhile.

@71451964
hehe, look at this faggot.
then watch this former vimtard.
youtube.com/watch?v=JWD1Fpdd4Pc

>infinite memory
I bet memorizing ~10 keybindings to open your commonly used programs would require what seems like "infinite memory" to a retard.
>taking up space
That's not how memory works.

Damn, I wonder how ugly you incels are

>Ever done a "git commit" without the -m parameter?
All the time in magit, your point being?
>Ever seen a "open in editor" button in a GUI app?
>editor
You don't seem to be on the same page here. I don't want to open something in emacs' editor, I want to use the emacs interface to navigate a program. What you're saying makes zero sense to someone who has used emacs for more than 15 minutes.

Didn't even bother reading the rest.

>potentially having to switch to Emacs and then to a program inside Emacs - two navigation steps, as opposed to one.
When would you ever need to do this when you're actually working (as opposed to constantly switching to discord to watch your favorite twitch streamer)?

I use both, Nano works fine for quick edits. They have similar default keybindings.
You don't have to restrict yourself to a single editor.

>Why does a developer of a file manager need to """""offer support""""" for some interface
Also this: the devs can make it be able to use Vim or Emacs-like bindings for navigation - but running the full Emacs environment for this makes little sense since the file manager isn't for writing text (inb4 dired) - its navigation isn't text navigation, so even if the shortcuts are similar, they're fundamentally different from your editor's shortcuts and thus shouldn't need to be provided by your editor directly.

See, this is the problem here. You want to achieve a uniform interface by putting everything inside one opionated sub-environment. I don't care about things not being completely uniform, and rather would have them be modular and only directly play together where it makes sense or a clear difference in productivity. Convention (like GUI standards or editor-like keybindings) can still be (and is being) successfully used to achieve necessary levels of unity between different programs, so this system works well. This is advantageous because not all software is provided for the one environment you want, so you'll have to adapt either way.

every day, since i can hit two buttons to compile a program or run a git command or shell command or open an ssh session without ever having to change terminal windows.

>the file manager isn't for writing text
>its navigation isn't text navigation
>thus shouldn't need to be provided by your editor directly
Says who?

Are you implying you can't do all of that without ever leaving emacs?

I. Fight me, faggot. I only ever type short pieces of text when I'm naming a file or performing a search (which usually happens with find or ag instead)

>I
Use a dedicated program to post that to your blog.

The browser would have to do, though it's basically a nasty extra layer as well.

>The browser would have to do
That's not very suckless of you. Why not write a 200-line shell script implementing this functionality?

Why do threads dedicated to editors degenerate into pointless arguments to convince others to use what they use?
Literally who cares. Periodically try out new tools when you've got some time to spare, and come to your own conclusions. If they aren't willing to do it and they stick to whatever they've been using, despite being suboptimal for their task, that's their loss.
With that said, is anyone here using Emacs for Haskell? I'm soon going to work on an existing Haskell codebase, and I've never used Emacs for it. What's your setup? So far, I've installed haskell-mode (obviously) and FlyCheck seems to work fine for syntax checking with ghc. company-mode also works nicely, as it does with other languages. Anything else to suggest, possibly Haskell-specific?

Attached: 1551280395697.jpg (300x449, 108K)

>Why do threads dedicated to editors degenerate into pointless arguments to convince others to use what they use?
Because having angry debates about what's Unix and whether it's good or not is fun

Has anyone ever seen an intelligent programmer who is also an ardent vim defender?

Attached: 1559905079262.jpg (338x368, 18K)

Has anyone ever seen an intelligent programmer who posts anime images on 4chin?

Anybody write code on C# in Emacs? My question is how to compile my n00bish console application?

Trick question.