23 ms·

I think that the Emacs concept is really good, but it clearly has a lot of problems that make it altogether unattractive to new potential users. - The keybindi

by snazz 6y ago

I think that the Emacs concept is really good, but it clearly has a lot of problems that make it altogether unattractive to new potential users. - The keybindings are not the standard CUA ones. Even with Cua Mode, every page on the internet still suggests using the regular old Emacs keybindings. There's weird conflicts between some packages, especially if you use non-default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie is a thing...) or mnemonic, so there's really nothing but historical interest that makes them the way they are. - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging. - Lots of other defaults are super user-hostile. To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts. - The base is minimal in a way (it's missing a ton of what is needed to be considered useful today) and also very bloated (it has things like mail readers and web browsers and IRC clients included). The set of default utilities needs to better match what people actually use a text editor for. At the same time, it does do plenty of things right: - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp. - Unicode works OOTB, which is impressive for a project of that age. - Some of the "killer apps" like Magit and Org-mode are really good and have spawned their own ecosystems. - Emacs is oftentimes the first editor to get support for super-obscure programming languages through a package. A lot of what makes Emacs so cool and so difficult comes from the fact that it doesn't have an "extension API"---packages just run the same kind of Elisp that the editor itself is (mostly) written in. Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.

dmortin 6y ago
> To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts. Isn't it the same with VIM or other free editors?
- snazz 6y ago
  To an extent, yes, but I would say that the Vim philosophy involves utilizing external tools much more than in Emacs. Vim packages like the one for Go (https://github.com/fatih/vim-go https://github.com/fatih/vim-go) feel better-integrated into Vim than the equivalents do into Emacs. This is mostly subjective, so I can see where you're coming from.
- stupidthrottle 6y ago
  To be fair these days you come far by just installing ’lsp-mode’.
jolmg 6y ago
How do you fix your con, > - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging. without sacrificing your pro?: > - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp. The fact that you can go to any package source file, modify a function and reload it on the currently running emacs instance (with C-M-x/eval-defun) kind of depends on definitions being standalone and at the top-level. You can have namespacing in the form of prefixing identifiers with the package name. If there's name-clashing between packages, it's because they didn't follow that convention. What more would you want out of namespacing that you can get without sacrificing or limiting that pro you mentioned? > Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives. There are many reasons to hate pretty much anything. I'm not sure how you expect one to respond, if you don't give some idea of what it is that you find terrible about it. It's always pros and cons with most things. "modern" also doesn't mean anything. Are you talking about languages that were invented recently or that are still maintained, evolving, and/or used despite being invented in "non-modern" times? Where does "modern" even start?
- timmy-turner 6y ago
  Agreed. I personally had never any problems with packages overwriting each other. Everybody knows that you have to namespace all the functions and it works, just like it works in C. And the upside that everything is accessible in the scratch buffer is really worth it. And for me, Elisp has been a kind of constant during my career. I wouldn't bet that in ten years, I'm still doing Typescript or Javascript. But if I'm still into programming computers via keyboards I will definitively use Emacs for that.
sachdevap 6y ago
> I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives. This is a commonly seen complaint, and I do not completely disagree with you. But really, if there were better options to create an editor on top of some sort of lisp-machine equivalent, why are there such few equivalent editors out there? I would be happy to move to a new mature ecosystem that allows the sort of flexibility offered by emacs, on which tools like magit and org-mode may become popular, but I am yet to find anything in the same ballpark.
eadmund 6y ago
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives. I think it's arguably the second-best language out there, losing out only to Common Lisp. Maybe third, after TCL. I certainly wouldn't want to use JavaScript, Go or Rust to extend my editor …
ragnese 6y ago
> There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging. The worst aspect of this is keybindings. As "free-form" as Emacs is, I think it would benefit greatly from having a centralized "database" of all (custom?) keybindings. I am sick of defining my own super-cool keybinding and then either having it get overridden by a package or unknowingly overriding a package's keybindings. I kind of wish a warning would be thrown or something if you try to bind a set of keys that's already bound. I don't know what system would be good/better, but I know I hate it as it stands today.

by snazz 6y ago

dmortin 6y ago

> To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts. Isn't it the same with VIM or other free editors?

snazz 6y ago
To an extent, yes, but I would say that the Vim philosophy involves utilizing external tools much more than in Emacs. Vim packages like the one for Go (https://github.com/fatih/vim-go https://github.com/fatih/vim-go) feel better-integrated into Vim than the equivalents do into Emacs. This is mostly subjective, so I can see where you're coming from.
stupidthrottle 6y ago
To be fair these days you come far by just installing ’lsp-mode’.

jolmg 6y ago

How do you fix your con, > - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging. without sacrificing your pro?: > - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp. The fact that you can go to any package source file, modify a function and reload it on the currently running emacs instance (with C-M-x/eval-defun) kind of depends on definitions being standalone and at the top-level. You can have namespacing in the form of prefixing identifiers with the package name. If there's name-clashing between packages, it's because they didn't follow that convention. What more would you want out of namespacing that you can get without sacrificing or limiting that pro you mentioned? > Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives. There are many reasons to hate pretty much anything. I'm not sure how you expect one to respond, if you don't give some idea of what it is that you find terrible about it. It's always pros and cons with most things. "modern" also doesn't mean anything. Are you talking about languages that were invented recently or that are still maintained, evolving, and/or used despite being invented in "non-modern" times? Where does "modern" even start?

timmy-turner 6y ago
Agreed. I personally had never any problems with packages overwriting each other. Everybody knows that you have to namespace all the functions and it works, just like it works in C. And the upside that everything is accessible in the scratch buffer is really worth it. And for me, Elisp has been a kind of constant during my career. I wouldn't bet that in ten years, I'm still doing Typescript or Javascript. But if I'm still into programming computers via keyboards I will definitively use Emacs for that.

sachdevap 6y ago

> I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives. This is a commonly seen complaint, and I do not completely disagree with you. But really, if there were better options to create an editor on top of some sort of lisp-machine equivalent, why are there such few equivalent editors out there? I would be happy to move to a new mature ecosystem that allows the sort of flexibility offered by emacs, on which tools like magit and org-mode may become popular, but I am yet to find anything in the same ballpark.

eadmund 6y ago

> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives. I think it's arguably the second-best language out there, losing out only to Common Lisp. Maybe third, after TCL. I certainly wouldn't want to use JavaScript, Go or Rust to extend my editor …

ragnese 6y ago

> There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging. The worst aspect of this is keybindings. As "free-form" as Emacs is, I think it would benefit greatly from having a centralized "database" of all (custom?) keybindings. I am sick of defining my own super-cool keybinding and then either having it get overridden by a package or unknowingly overriding a package's keybindings. I kind of wish a warning would be thrown or something if you try to bind a set of keys that's already bound. I don't know what system would be good/better, but I know I hate it as it stands today.