Absolute Beginner's Guide to Emacs (2012) • Hacker News Board

Re: Absolute Beginner's Guide to Emacs (2012)

#241

Post by dmitriid » Wed, Dec 05, 2018, 9:53 AM UTC

xte wrote: post #152

dmitriid wrote: post #141

Earlier quoted context omitted.

> isn't easy if you lack the imagination wat? > or the technical know-how (elisp) It's not just the technical know-how of knowing elisp. It's also the often arcane ways of configuring emacs and the arcane and often undocumented ways of configuring the packages and plugins and modes that you bring into the system. The amount of hacks one needs to maintain a reasonably working emacs is mind-boggling, and has nothing to…

With req-package and org-mode init you do not need any specific hack and anything that does not work remain "isolated". Many try el-get, borg, ... but personally I found simple setup effective enough and in years my config is now ~4000 lines of org+elisp + few personal packages...

> I found simple setup effective > my config is now ~4000 lines

We have critical production services which are a magnitude of lines fewer than your "simple config".

There's a reason I linked my own init.el: I'm not talking about something I have no idea about. It's quite short and quite extensively documented. And even there you see: somethign is set as global vars, something is buffer local args, something is inited through hooks, something is inited through hooks and then thorough a global var (doesn't work the other way around), something requires a lambda for a config, something requires a list of values, something is inited through a macro, some are just elisp macros you have to write yourself. And so on and so on.

Once you start extending emacs to be your personal programming environment (especially a multi-language environment), you'll run into exactly what I'm talking about: it's not a simple system. There are the often arcane ways of configuring emacs itself, and then there are often arcane ways to configure the modes and packages. And often these are undocumented, or specific ways to configure them are passed down in oral tradition from one init.el to another.

Even in this post you see multiple people recommending not just differenet packages, but different combinations of packages (each has to be configured separately).

And when something goes wrong? Good luck figuring it out.

Re: Absolute Beginner's Guide to Emacs (2012)

#242

Post by dmitriid » Wed, Dec 05, 2018, 9:55 AM UTC

kazinator wrote: post #180

xte wrote: post #150

Earlier quoted context omitted.

Well, in the past I have used Eclipse, Netbeans, SunStudio (essentially netbeans), IntelliJIdea, Oracle JDeveloper and others: all of them are enormously bugged, perhaps Netbans/Sunstudio was the least bugged. All of them suffer from an ever grown dotdirs that sooner or later brake and you need to restart from scratch... In Emacs I have had brackeage, and an emacs bankruptcy. But in all case I have recovered anything…

Exactly. If all those IDEs in the IDE graveyard were so good, why are they dead, while your Emacs is still here? Too tied to a platform or language, perhaps, and very specific processes related to these? No vision for extensibility or future maintenance? Sometimes IDEs are very tied to specific target platforms: like IDEs from microcontroller and DSP vendors and such. E.g. if you're programming PICs, you use Microchi…

> If all those IDEs in the IDE graveyard were so good, why are they dead, while your Emacs is still here?

Emacs on its own is nothing but a fancy extensible notepad. The things that make an IDE come and go in the emacs world, too.

Re: Absolute Beginner's Guide to Emacs (2012)

#243

Post by dmitriid » Wed, Dec 05, 2018, 9:56 AM UTC

xte wrote: post #163

dmitriid wrote: post #145

Earlier quoted context omitted.

In the context of emacs, you only ever need to learn terminology like - major and minor modes, - special, regular, mini and read-only buffers, - frames, - backup files, - dired, - mark and kill rings, - hooks, - the difference between C-x and M-x, - mode line, - registers - and whatever else there is in emacs' configs, packages etc. I dunno. Perhaps in emacs lingo "standard" means "no one uses these terms anymore"?

That's not a real problem, if you call it "advanced statusbar" instead if minibuffer, split instead of windows, contents instead of buffer it's only a matter of name. And most of them are pretty intuitive. Consider a thing: commercial always say "start with us is quick", and they do their best for that. Unfortunately they omit an important fact: start it's quick, if you already came from commercial environment witch…

> That's not a real problem, if you call it "advanced statusbar" instead if minibuffer, split instead of windows, contents instead of buffer it's only a matter of name. And most of them are pretty intuitive.

vs.

> Also standard terminology is normally used, for instance you never find FOSS project to invent terms like "BIA" (Cisco name for MAC address of a nic, "burn-in address") or "Enable mode", "write terminal" and things like that.

This is called hipocrisy.

There's nothing "intuitive" about emacs terminology.

Re: Absolute Beginner's Guide to Emacs (2012)

#244

Post by PurpleRamen » Wed, Dec 05, 2018, 11:25 AM UTC

SmirkingRevenge wrote: post #60

thecryusofiran wrote: post #8

Earlier quoted context omitted.

As an Emacs user I'm mostly "afraid" of VSCode getting so popular that people will make cool tools targeting VSCode only. Like, it'll become the Chrome of text editors.

Editor trends seem to fairly volatile. Textmate was the new shiny favorite until it wasn't. Sublime was the new shiny favorite till it wasn't. Atom was the new shiny favorite... etc.

Those had all legit flaws which prevents wider usage, like being limited to one platform, being commercial or slow or dead... They all lakc in concept, because they are editors first, and not much of an IDE. VS Code is the first who actually avoids all the flaws. It's flexible, yet still quite fast, relative tame on RAM, yet full of IDE-features, running on all platforms and cost you just some privacy if you don't know about the data-collecting.

Additionally, it sparked the LSP a movement which is benefitial for all editors/IDEs, and we will see how much more will come from this. So even if VS Code itself will lost traction, it's heritage might prevail. But overall the specs so far look very healthy for a project in that realm, and chances are good that it will stay for a while.

Re: Absolute Beginner's Guide to Emacs (2012)

#245

Post by sandos » Wed, Dec 05, 2018, 11:51 AM UTC

dmitriid wrote: post #241

xte wrote: post #152

Earlier quoted context omitted.

With req-package and org-mode init you do not need any specific hack and anything that does not work remain "isolated". Many try el-get, borg, ... but personally I found simple setup effective enough and in years my config is now ~4000 lines of org+elisp + few personal packages...

> I found simple setup effective > my config is now ~4000 lines We have critical production services which are a magnitude of lines fewer than your "simple config". There's a reason I linked my own init.el: I'm not talking about something I have no idea about. It's quite short and quite extensively documented. And even there you see: somethign is set as global vars, something is buffer local args, something is inited…

This is exactly what keeps happening to my emacs. I have tried emacs in 3 or 4 periods for work and home use. Every time, I add useful things to my config until something breaks, I try fix it and maybe fail or partially fix it.

I eventually give up. Latesty try was with spacemacs, which I quite liked. It gots so broken it refused to start up and I never even really bothered fixing it. I tried VS Code and that is where I am at.

Now my VS Code is getting slow, and Iv'e already had some problems extensions!

Re: Absolute Beginner's Guide to Emacs (2012)

#246

Post by xte » Wed, Dec 05, 2018, 12:07 PM UTC

dmitriid wrote: post #242

kazinator wrote: post #180

Earlier quoted context omitted.

Exactly. If all those IDEs in the IDE graveyard were so good, why are they dead, while your Emacs is still here? Too tied to a platform or language, perhaps, and very specific processes related to these? No vision for extensibility or future maintenance? Sometimes IDEs are very tied to specific target platforms: like IDEs from microcontroller and DSP vendors and such. E.g. if you're programming PICs, you use Microchi…

> If all those IDEs in the IDE graveyard were so good, why are they dead, while your Emacs is still here? Emacs on its own is nothing but a fancy extensible notepad. The things that make an IDE come and go in the emacs world, too.

Hem... We are people, so we are sometimes lovers, sometimes cookers, sometimes fighters, businessman, ... but we are still the very same body. So why our tools need to be divided and confined to a purpose if we are able to craft a single efficient and integrated one?

Re: Absolute Beginner's Guide to Emacs (2012)

#247

Post by xte » Wed, Dec 05, 2018, 12:21 PM UTC

dmitriid wrote: post #241

xte wrote: post #152

Earlier quoted context omitted.

With req-package and org-mode init you do not need any specific hack and anything that does not work remain "isolated". Many try el-get, borg, ... but personally I found simple setup effective enough and in years my config is now ~4000 lines of org+elisp + few personal packages...

> I found simple setup effective > my config is now ~4000 lines We have critical production services which are a magnitude of lines fewer than your "simple config". There's a reason I linked my own init.el: I'm not talking about something I have no idea about. It's quite short and quite extensively documented. And even there you see: somethign is set as global vars, something is buffer local args, something is inited…

That's why I use org-mode for my config so I can set :tangle no anytime, with {use,req}-pacakge I can handle the complexity without feeling it.

Actually I live (in IT terms) in Emacs, from the WM (EXWM(-x)) to MUA (notmuch-emacs) to personal finance (ledger-mode) to document system (skeletor+org+LaTeX+yasnippet) to programming environment (personal use of guile (geiser), hy, python (jedi etc), nim and various shells/DSL language), I administer systems inside Emacs with NixOS and tramp+eshell, I forget the concept of filemanger with dired (and tons of related addons), I super reduce CLI usage thanks to various Emacs packages, I have chat, rss, news all inside all well integrated... Yep, the start give me some frustration, I have a config bankrupt but after that things goes far smother than any other environment I have ever tried.

And yes, the config is big, but I do not made it before starting using Emacs, it evolve regularly in the time as I need so it's length and complexity have essentially no weigh. When something goes wrong (essentially after an update) I simply rollback and keep working until I have time to investigate. No real interruption, nothing like Windows update during presentation we all have seen.

Sometimes I have encountered "strange" bugs, the last few days ago that doom-modeline break notmuch-mua-new-mail: I quickly rollback and do my stuff; in a moment of free time I try to figure out what happen and yes I encounter some difficulties (my knowledge of elisp it's not well enough) so I simply ignore the problem. Yesterday I update again and the problem was gone. Long-story short in many case a problem is not only mine and tons of people working on Emacs find and debug it :-)

Re: Absolute Beginner's Guide to Emacs (2012)

#248

Post by xte » Wed, Dec 05, 2018, 12:26 PM UTC

sandos wrote: post #245

dmitriid wrote: post #241

Earlier quoted context omitted.

> I found simple setup effective > my config is now ~4000 lines We have critical production services which are a magnitude of lines fewer than your "simple config". There's a reason I linked my own init.el: I'm not talking about something I have no idea about. It's quite short and quite extensively documented. And even there you see: somethign is set as global vars, something is buffer local args, something is inited…

This is exactly what keeps happening to my emacs. I have tried emacs in 3 or 4 periods for work and home use. Every time, I add useful things to my config until something breaks, I try fix it and maybe fail or partially fix it. I eventually give up. Latesty try was with spacemacs, which I quite liked. It gots so broken it refused to start up and I never even really bothered fixing it. I tried VS Code and that is wher…

I have experienced far in the past a similar situation, I've tried both Emacs and XEmacs at that time and give up sticking to vim. After, time ago pushed by curiosity and few demos I casually see I tried Emacs again but with a far slower start, only as a side curiosity and a step at a time I grow my config keep using (n)vim until I decide it's time to jump. After that I still experience some problems but I keep evolution speed slow to avoid frustration, in few months Emacs became my environment.

Maybe you have tried Emacs as an editor expecting to been able to use it quickly as other "editors" you already encounter and that cause the fail. Emacs is an OS, not an editor, an ancient one that have some idiosyncrasy because of that vestige. And we know that learning an OS is not as simple as learning a single-purpose application.

Re: Absolute Beginner's Guide to Emacs (2012)

#249

Post by xte » Wed, Dec 05, 2018, 12:32 PM UTC

dmitriid wrote: post #243

xte wrote: post #163

Earlier quoted context omitted.

That's not a real problem, if you call it "advanced statusbar" instead if minibuffer, split instead of windows, contents instead of buffer it's only a matter of name. And most of them are pretty intuitive. Consider a thing: commercial always say "start with us is quick", and they do their best for that. Unfortunately they omit an important fact: start it's quick, if you already came from commercial environment witch…

> That's not a real problem, if you call it "advanced statusbar" instead if minibuffer, split instead of windows, contents instead of buffer it's only a matter of name. And most of them are pretty intuitive. vs. > Also standard terminology is normally used, for instance you never find FOSS project to invent terms like "BIA" (Cisco name for MAC address of a nic, "burn-in address") or "Enable mode", "write terminal" an…

> This is called hipocrisy. IMO it's simply a way to lock users in, like Cisco, like Oracle, like OpenBravo, like any other vendor try to do. Emacs simply was born many years ago, and kept going since that, why change terminology just to ease the newcomers make unhappy actual users?

> There's nothing "intuitive" about emacs terminology. And so what? Emacs is an OS not a small single-purpose apps, did you expect to being able to learn it an a day clicking around? In my personal experience, as a hardcore vimmer for more than a decade, as someone who have used different OSes (casually born on Irix thanks to a present by a family friend, evolved on FreeBSD, RH/Fedora/Debian/Gentoo, Solaris, OpenSolaris, Ubuntu/NixOS) I have seen anywhere "non intuitive" terminology, and I'm still there...

What about slices instead of partition? What about /dev/ notation in various unices? What about pfexec vs su vs sudo vs pkexec vs ...?

Re: Absolute Beginner's Guide to Emacs (2012)

#250

Post by zimablue » Wed, Dec 05, 2018, 1:50 PM UTC

YuukiRey wrote: post #144

zimablue wrote: post #24

Earlier quoted context omitted.

VSCode has very much opposing philosophy to Emacs. It's a Microsoft product and it shows, they don't have standard concept of buffers/windows, so trying to do customization is ugly. For example, you can't easily implement a shell which moves around the windows and can also sit on a side, because windows and sidebars are totally different concepts in the code. VSCode depresses the hell out of me, it's almost a summary…

I don't usually do this "argument by argument rebuttal" but since your post is extremely misleading I can't resist: > pretty much an inferior copy of an existing thing (Atom) How? For starters, it's a lot faster which appears to be a major reason why people switch > but not really built as a nice platform to be meaningfully extended Well that's up for debate now isn't it? Its plugin ecosystem disagrees with a perceiv…

1. Kind of fair, it's better in some ways and worse in others. I would emphasise extensibility (this is after all an emacs thread) so I'd call it worse. You don't seem to dispute that it's a copy (in terms of engine/approach) 2. Same as 1, having read the issues and some of the source I stand by the statement. 3. Ask yourself why else Microsoft would build something 4. Fork it is naive to the point of being dishonest. You cannot outfork something with 10 professional developers, unless you're Stallman doing it full time.

You only disputed some of my points, "most people will download it with spyware", "it will damage existing more truly extensible efforts" seems to be a pretty key ones you haven't disputed. If only those two were true it would be enough for me to dislike it.