Hello!
My name is Daniel or Daniil Rose.
I use Emacs in my everyday life,
from programming in C or Rust for work,
to writing reports for classes.
I'd like to start by adding
an overarching theme to this talk.
If there's only one thing
that you remember from today,
I'd like you to walk away
with the understanding
that the philosophies or ideologies
are just that.
By trying to box yourself in with a concept
you might be blind to other methods.
We live in an ever-changing world,
and I hope that you can appreciate
being flexible and adaptable.
UNIX philosophy? As a quick intro
for those who don't know,
the UNIX philosophy
was written by Doug McIlroy.
It's wordy, so there is
a great summarization
by Peter H. Salus:
Write programs that do one thing
and do it well.
Write programs to work together,
and write programs to handle text streams,
because they are the universal interface.
So enter Emacs.
Emacs doesn't quite adhere
to those principles.
"Do one thing and do it well"
surely doesn't apply,
since Emacs does /a lot/ of things
and does the majority of those things well.
It might apply if you consider Emacs
purely as a Lisp environment, however.
"Write programs to work together?"
Arguably the thing Emacs is best
out of the three,
proven especially
by all the various packages
that work with external programs,
LSP, and whatever else.
"Handle text streams?"
Well, that one depends.
So, Emacs versus the original ideas.
The summarizations are good,
but they aren't truly what was said.
If we look back at the originals,
we'll see that Emacs strongly adheres
to the second rule:
Design and build software,
even operating systems,
to be tried early,
ideally within weeks.
Don't hesitate to throw away
the clumsy parts
and rebuild them.
The concept of LISP,
self documentation of Emacs,
and the "REPL" style all make it
a shining example of this rule.
But why compare to UNIX?
Truly, why compare to the UNIX philosophy?
Although the "rules" set down are good ones
for most programs,
Emacs isn't most programs.
The rules and summarizations
even were written decades ago,
before we had REST APIs, JSON,
or any other modern interface.
If the world adapts,
why too can't we adapt the past?
This concept of breaking the rules
and forging its own path
has allowed Emacs to continue
and be reworked for modern eras.
Emacs /does/ work with the UNIX philosophy.
By looking at both of these ideologies,
why must they be mutually exclusive?
Emacs does work with text:
Magit is a wrapper for the git CLI
Dired is a wrapper for ls,
Consult grep for grep, and so on.
Why rewrite poorly tools,
when we can use the existing powerful ones?
Well, that in itself
is part of the UNIX philosophy.
It seems that most strongly
the UNIX philosophy
applies to the command line.
If we look at most graphical applications,
these notions fall apart.
But that isn't true for Emacs.
It is a graphical application
(at least for me)
but it does use many other tools.
Some have proposed
that Emacs should be looked at
alongside UNIX, as its own OS.
It has windowing capabilities
handles its own formats,
and so on, but I disagree with this concept.
Philosophies don't really matter
in computing.
It's true, they don't.
As people, we like to group things.
We like to have our set ways
to describe them,
but that doesn't always work.
By sticking with a common concept
in the Emacs community,
do everything in Emacs,
is it truly benefitting me and you?
Android Studio. Here's an example.
I work most often in Emacs.
But I also have courses
in Android and iOS development.
I can absolutely install
~android-mode~ and ~kotlin-mode~,
and use ~adb~ in Emacs,
but at that point,
I am creating more work than it's worth.
When unmaintained,
things tend to fall apart,
and many features of ~android-mode~
no longer work for me.
So I have two main options:
fix the existing mode or write my own,
or use the assumed tools for the job,
like Android Studio and/or IntelliJ.
Looking at Android Studio:
I have plenty of plugins for colour themes,
just like Emacs.
I have Emacs keybindings built in,
and other quality-of-life features.
According to the UNIX philosophy,
in a round-about way,
I should be using one tool
that does its job well.
While not minimal,
Android Studio accomplishes this job.
Does that mean that I shouldn't use Emacs at all?
Of course not!
And while it may seem obvious,
I feel we in this group
often get caught up
finding solutions
in the one particular way
we want it.
This is where being adaptable
comes in again.
I need to learn how to mold my tools
to my workflow,
but also mold my workflow
to the tools available.
Window Managers.
Another example of this is window managers.
Although I've probably dabbled
in window managers or desktop environments
as much as the next person,
I have usually stuck with DWM.
But DWM doesn't follow
any of the Emacs concepts:
it has different keybindings--
you can sort of do Emacs ones,
no REPL (it's a C program after all).
But I can still mold it to my workflow.
If I run Emacs as a daemon and a client,
what difference is it?
My WM is essentially a wrapper
for Emacs and my other vital programs.
I don't need to make Emacs my WM,
and bring along all the other issues.
Browsers are a similar conversation.
Initially, I understand the value
of having my browser in Emacs, but why?
If a tool exists that works well,
ignoring the UNIX philosophy for a moment,
why should I take the effort to rewrite it?
Now, don't misinterpret what I'm saying.
If you have a better way to do something:
you can make it faster, easier to use,
that I understand.
But if I have, say, Nyxt or Firefox?
Why would I take the effort
to try and rewrite that into Emacs?
Instead, this is a scenario
where using a different tool
alongside Emacs might be better.
There's a talk later on in the conference
about that from someone else.
Vim. Even vim, jokingly,
is the enemy of our community,
but it's a good tool.
Sometimes I just don't want to
run Emacs as a daemon with evil-mode
and I just want to quickly do something.
And most people come from
a power user terminal background,
or at least I would assume s,.
and those I have spoken with.
If I need to quickly edit something,
it might benefit me to
just run a quick vim ./file
in the terminal.
I often have terminals open anyway
due to the graphic acceleration
from things like Alacritty.
Speaking of terminals,
this is the main tool I don't use in Emacs.
While vterm might be nice,
I often want to use a TUI tool.
I most often write programs in C or Rust
due to those being my main languages
that I use professionally.
If I can write a faster C or Rust program
in half the time it'll take for me
to write a slower Elisp one,
I might prefer to do just that.
Especially in the case of a TUI program,
Alacritty helps me develop them faster
but also run them.
So if you've been using systemd
or running commands in the terminal for years,
it might take more effort to learn
the way to do it in an Emacs frontend
than in the terminal.
And remember, most shells come with
Emacs key bindings by default
and macOS, for example,
can use Emacs keybindings in most places
including browsers.
Do what helps you most,
not what a philosophy or group tells you to do.
I hope this illustrated some ways
that Emacs is a tool in your belt,
but not the belt itself.
Do what works best for you,
as being the most efficient
doesn't always grant the best results.
If you're used to doing something one way,
consider still doing it that way
while learning new skills
and being adaptable. And after all,
this is an Emacs conference
so maybe consider learning a tool
for both Emacs and the terminal,
and then you might be
just a little bit more flexible
in the future.
Thank you for listening to my talk today.