New GNU Emacs website(gnu.org)
gnu.org
New GNU Emacs website
http://gnu.org/software/emacs/index.html
236 comments
Personally it has never mattered to me how many people adopt Emacs because it has enough users to ensure development forever. I know for a fact that if the Emacs developers weren't doing a bang up job, which they are, then I would immediately allocate some of my time to help.
Emacs is emblematic of the community aspect of software development that rms usually brings up when talking about free software, and I think it's a subtle notion that separates Emacs from a typical "open source" project. Projects that are as they say "Open Source" tend to be commercially oriented more than community oriented.
Whether or not Emacs is a large or small community does not really matter to me, the software is pretty much stable enough that the future is bright even if everyone on the developer mailing list dropped dead.
I don't mean to complain about "open source" software nor do I claim that the way that Emacs is being developed is better than any other. What I mean to say is that Emacs is an old application and I found it on its old crusty website, decided to dedicate a bunch of time on learning macros, because that's simply the kind of person I am. Whether or not Emacs had a great website would not be the factor that swayed me, and frankly I'm not in the business of trying to sway people as an Emacs fan. Use what you want. I know I'm getting the best development environment for me, because I know me, and I've made Emacs mine.
I don't mean to complain about "open source" software nor do I claim that the way that Emacs is being developed is better than any other. What I mean to say is that Emacs is an old application and I found it on its old crusty website, decided to dedicate a bunch of time on learning macros, because that's simply the kind of person I am. Whether or not Emacs had a great website would not be the factor that swayed me, and frankly I'm not in the business of trying to sway people as an Emacs fan. Use what you want. I know I'm getting the best development environment for me, because I know me, and I've made Emacs mine.
I know for a fact that if the Emacs developers weren't
doing a bang up job, which they are, then I would
immediately allocate some of my time to help.
https://lars.ingebrigtsen.no/2016/05/03/emacs-bug-trends/
Same author also wrote a nice, short intro on how to get started with Emacs bug hunting: https://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-de...
It may not be that they are commercially oriented, but that they have adopted startup-like mentalities regarding "growth".
This in turn leads to all kinds of changes to appear more fashionable and appealing to the masses.
Frankly i think thats a fools errand. Seems to me that when it comes to fashionable in relation to computing, we are dealing with a Giffen Good (or perhaps even a Veblen Good). Meaning that to be a fashionable computing platform, it has to be an expensive one.
But in the process you end up with something similar to New Public Management for FOSS projects. Trying to evangelize and drum up attention as if they were pitching a for profit product, much like NPM tries to put market forces into public services.
This in turn leads to all kinds of changes to appear more fashionable and appealing to the masses.
Frankly i think thats a fools errand. Seems to me that when it comes to fashionable in relation to computing, we are dealing with a Giffen Good (or perhaps even a Veblen Good). Meaning that to be a fashionable computing platform, it has to be an expensive one.
But in the process you end up with something similar to New Public Management for FOSS projects. Trying to evangelize and drum up attention as if they were pitching a for profit product, much like NPM tries to put market forces into public services.
I think this is a good lesson to people whose projects aren't Emacs' size yet.
Of course Emacs can get away with it, but this sets a good example of what a nice, simple website can look like for your project.
Don't spend too much time on the website, of course (the core project is what's important), but first impressions affect adoption, right?
Of course Emacs can get away with it, but this sets a good example of what a nice, simple website can look like for your project.
Don't spend too much time on the website, of course (the core project is what's important), but first impressions affect adoption, right?
Hey, it's not called the Editor for Middle Aged Computer Scientists for no reason!
I read Middle Aged as in medieval, and saw lots of alchemist scribing lisp on parchments.
What is the benefit for an existing CS student to switch to Emacs who is already comfortable with using IDEs like Visual Studio, Eclipse or IntellijIDEA?
In 20 or 40 years, emacs will still exist, as will the hooks and tools you've integrated and built up to support it.
VS, Eclipse, and IntellijIDEA very likely won't.
And I say that as someone who doesn't use Emacs much -- I'd learned it at one point and used it pretty heavily for a job, with a very nice set of modes for a proprietary software tool I was using at the time, but made the critical career error of working for an idiot boss who didn't believe any software other than what the vendor provided was necessary on corporate servers.
So yes, I use vim.
But I've learned ... at least a dozen editors and development environments which are either dead or proprietary and not availa ble to me. Time which I could have devoted to learning persistent tools and extending them.
That's among the strongest arguments in favour of using Free Software tools generally, from a technical PoV. Your knowledge tends to remain relevant far, far longer.
VS, Eclipse, and IntellijIDEA very likely won't.
And I say that as someone who doesn't use Emacs much -- I'd learned it at one point and used it pretty heavily for a job, with a very nice set of modes for a proprietary software tool I was using at the time, but made the critical career error of working for an idiot boss who didn't believe any software other than what the vendor provided was necessary on corporate servers.
So yes, I use vim.
But I've learned ... at least a dozen editors and development environments which are either dead or proprietary and not availa ble to me. Time which I could have devoted to learning persistent tools and extending them.
That's among the strongest arguments in favour of using Free Software tools generally, from a technical PoV. Your knowledge tends to remain relevant far, far longer.
> VS, Eclipse, and IntellijIDEA very likely won't.
VS was first released in 1997; Eclipse in 2001; and IntelliJ in 2001 as well. I wouldn't take that bet.
VS was first released in 1997; Eclipse in 2001; and IntelliJ in 2001 as well. I wouldn't take that bet.
>In 20 or 40 years, emacs will still exist, as will the hooks and tools you've integrated and built up to support it.
> VS, Eclipse, and IntellijIDEA very likely won't.
Why do you think so ?
Intellij and Eclipse are both open source. I suspect they will be around as well. The companies supporting them may go out of business, but there are enough users for it at the moment that someone will be able to keep maintaining it or build new businesses around it.
> VS, Eclipse, and IntellijIDEA very likely won't.
Why do you think so ?
Intellij and Eclipse are both open source. I suspect they will be around as well. The companies supporting them may go out of business, but there are enough users for it at the moment that someone will be able to keep maintaining it or build new businesses around it.
Emacs is a very general and fundamental tool. It's "do one thing well" is "organise textual interactions, via lisp". And that ranges from editing to shell to numerous programming environments to email to web....
I'm actually thinking of picking up Emacs again as a preferred option to a browser.
Eclipse and Intellij may be open source (and I'm sufficiently unfamiliar with them that I'd blown that fact, thanks for the correction), but they're far narrower in scope. That itself tends to be a strike against. Even broadly-used tools -- say, Perl -- can be, pardon the term, eclipsed by others.
Mind to: learning multiple ways isn't a Bad Thing. But being highly mindful of what tends to survive and what doesn't is itself useful.
Emacs dates from glass TTYs, and has survived to mobile devices. I've seen enough of other tools to note the quirks of their own tech origins and how this has or hasn't limited them over the years.
So: consider mine a somewhat informed, somewhat uninformed opinion. Though I'd still strongly recommend Emacs as a durable, extensible, and exceedingly useful skill.
I'm actually thinking of picking up Emacs again as a preferred option to a browser.
Eclipse and Intellij may be open source (and I'm sufficiently unfamiliar with them that I'd blown that fact, thanks for the correction), but they're far narrower in scope. That itself tends to be a strike against. Even broadly-used tools -- say, Perl -- can be, pardon the term, eclipsed by others.
Mind to: learning multiple ways isn't a Bad Thing. But being highly mindful of what tends to survive and what doesn't is itself useful.
Emacs dates from glass TTYs, and has survived to mobile devices. I've seen enough of other tools to note the quirks of their own tech origins and how this has or hasn't limited them over the years.
So: consider mine a somewhat informed, somewhat uninformed opinion. Though I'd still strongly recommend Emacs as a durable, extensible, and exceedingly useful skill.
There is a difference between brand/product name and product itself. As @dredmorbius mentioned in a sibling comment, IDEs by definition do not "do one thing well" - various tools are integrated with varying degrees of tightness. Take old VS project, old Eclipse workspace and they have to be first converted to a new format. How can one be sure that there is 1:1 mapping between old and new formats?
Having worked on VS6 does not guarantee that old tips&tricks will be valid in VS2016 or VS2030. Imagine if they decided to switch from VC to clang - it is integral part of VS and cannot be dismissed. Even though I'm not emacs user I'm pretty confident that overwhelming majority of what I learn today about the tool will be valid 20 years later.
Having worked on VS6 does not guarantee that old tips&tricks will be valid in VS2016 or VS2030.
They do if those tips&tricks include basic editing functions, which is what you're talking about if you're comparing it to vi/emacs.
They do if those tips&tricks include basic editing functions, which is what you're talking about if you're comparing it to vi/emacs.
My "tips and tricks" include how to read email and RSS/ATOM feeds in Emacs, which I do using Gnus.
In fact, reading email and RSS/ATOM in Gnus is also a tip/trick, since it was originally written (in 1987) for Usenet.
I'm not at all saying that others should use Emacs for their email. I'm pointing out that Emacs customisation can involve far more than "basic editing functions", and that these customisations can continue working for decades.
In fact, reading email and RSS/ATOM in Gnus is also a tip/trick, since it was originally written (in 1987) for Usenet.
I'm not at all saying that others should use Emacs for their email. I'm pointing out that Emacs customisation can involve far more than "basic editing functions", and that these customisations can continue working for decades.
Point is, if you use emacs and vi, you're stuck doing basic editing functions in a different way than the rest of the world. We see vi users adapt to this by trying to cram vi plugins into everything, and emacs users by trying to cram everything into emacs.
Not stuck, empowered
After witnessing many of these discussions, it's just FUD. Just because Emacs is older doesn't mean that IntelliJ or Eclipse aren't likely to follow you until retirement. Java hit critical mass a long time ago and both IDEs have mass adoption and are also OSS, as you mentioned.
The POV presented in that comment is basically a sales pitch. It's too standardized and common not to be (it pops up in most of these threads).
The POV presented in that comment is basically a sales pitch. It's too standardized and common not to be (it pops up in most of these threads).
There is an interesting rule from biological evolution of rates of extinction with species age that I'd thought of in relation to this. Essentially: they're constant. That is, a species is as likely ro go extinct when old as young: there is no increased survival probability with age.
Leigh Van Valen's Law of Extinction, related to the Red Queen Hypothesis.
https://en.wikipedia.org/wiki/Red_Queen_hypothesis
I don't know how well this translates to areas such as software, but it does give me pause.
Leigh Van Valen's Law of Extinction, related to the Red Queen Hypothesis.
https://en.wikipedia.org/wiki/Red_Queen_hypothesis
I don't know how well this translates to areas such as software, but it does give me pause.
Nassim Taleb disagrees with you https://mises.org/library/how-time-and-uncertainty-can-make-...
Eclipse, maybe not. But IntellijIDEA, I doubt that it will stay if Jetbrains goes away. They do not fully open source their IDE.
VS, Eclipse, and IntellijIDEA very likely won't.
Well, I hope they won't. But I'm sure their many common UI conventions will. Those conventions are shared between hundreds of thousands of apps already.
In 20 or 40 years, the Emacs UI will still rule only in a single program (and if we're unlucky maybe a few other tools still, like the readline library!).
As for vi, I'm sure some people will still be installing vi plugins everywhere to get 1/10th as smooth an experience as everyone else, and telling themselves they're more productive for it. Already these UI conventions developed for a line editor have outlived much of the generation that has ever used a line editor, so I'm sure it can go on for another 40 years!
Well, I hope they won't. But I'm sure their many common UI conventions will. Those conventions are shared between hundreds of thousands of apps already.
In 20 or 40 years, the Emacs UI will still rule only in a single program (and if we're unlucky maybe a few other tools still, like the readline library!).
As for vi, I'm sure some people will still be installing vi plugins everywhere to get 1/10th as smooth an experience as everyone else, and telling themselves they're more productive for it. Already these UI conventions developed for a line editor have outlived much of the generation that has ever used a line editor, so I'm sure it can go on for another 40 years!
Disclaimer: I have only used vim and emacs, so I really don't know what an IDE can do.
Things I wish I knew about emacs earlier in life:
Emacs benifit plan volume 1:
* You will finally love the ui/ux for `info` pages
* macros (save and repeat a sequence of commands, commands can be applied to anything)
* registers (save locations in buffers, save text for later pasting)
* Frames (M-x speedbar for starters)
* modes (which to use and how to configure?!)
* built in documentation is awesome!
* what does this sequence of buttons do is only a `Ctr-h k <sequence of buttons>` away
* Mostly solid remote editing (tramp mode is no match for rsync on large files, luckily, RMS and friend have afforded us our freedom and we can configure this to our liking.)
* Freedom (as already identified by many people here but not by the word 'Freedom'. Also Freedom causes longevity. I have no source on this)
* Why is Freedom not number one on my silly list? If this were ORG mode I could bump it up to the top quickly.
* Excellent (multi-language (multi-language)) support. This is a recursive joke and the base case for me at least is English Bash. Emacs is language agnostic and language aware
* You will never have to write a 'throw-away' shell script ever again because emacs macros are that good. Still like shell scripting, incorporate shell commands in your macro.
* Carpel tunnel syndrom (cts) is a real thing, but, IMO, poor posture is more likely to give you health problems than cts. In reality, with Ctrl-R reverse search and Ctrl-S forward search, you can basically cycle through every command you have ever typed.
* Default key bindings in bash are emacs based and I actually enjoy the emacs bindings more than the vi ones despite spending lots of time in vim
Last reason: It's fun to play with a "real time display editor" and realize that emacs is an endless journey on the road to freedom in your ability to manipulate computation, however it may be expressed in years to come.
Things I wish I knew about emacs earlier in life:
Emacs benifit plan volume 1:
* You will finally love the ui/ux for `info` pages
* macros (save and repeat a sequence of commands, commands can be applied to anything)
* registers (save locations in buffers, save text for later pasting)
* Frames (M-x speedbar for starters)
* modes (which to use and how to configure?!)
* built in documentation is awesome!
* what does this sequence of buttons do is only a `Ctr-h k <sequence of buttons>` away
* Mostly solid remote editing (tramp mode is no match for rsync on large files, luckily, RMS and friend have afforded us our freedom and we can configure this to our liking.)
* Freedom (as already identified by many people here but not by the word 'Freedom'. Also Freedom causes longevity. I have no source on this)
* Why is Freedom not number one on my silly list? If this were ORG mode I could bump it up to the top quickly.
* Excellent (multi-language (multi-language)) support. This is a recursive joke and the base case for me at least is English Bash. Emacs is language agnostic and language aware
* You will never have to write a 'throw-away' shell script ever again because emacs macros are that good. Still like shell scripting, incorporate shell commands in your macro.
* Carpel tunnel syndrom (cts) is a real thing, but, IMO, poor posture is more likely to give you health problems than cts. In reality, with Ctrl-R reverse search and Ctrl-S forward search, you can basically cycle through every command you have ever typed.
* Default key bindings in bash are emacs based and I actually enjoy the emacs bindings more than the vi ones despite spending lots of time in vim
Last reason: It's fun to play with a "real time display editor" and realize that emacs is an endless journey on the road to freedom in your ability to manipulate computation, however it may be expressed in years to come.
> Carpel tunnel syndrom (cts) is a real thing, but, IMO, poor posture is more likely to give you health problems than cts
Also, use sticky keys (https://en.wikipedia.org/wiki/Sticky_keys)
I use all software with sticky keys enabled and I can't go back to a state without sticky keys. I wonder why others also don't use it. Stick with it for two or three full days and I am certain that you will love not having to press shift to capitalise text or how easy it is to press the Ctrl keyboard shortcuts in general. Not to talk about how easy it makes Emacs usage.
For exampe, to paste the URLs above, I pressed Shift with my left pinky and pressed Insert with right pinky one after the other, easier than contorting (it feels so now, after using sticky keys for some time, earlier it was okay) hand to press Ctrl-V. Also, to open and close brackets is real easy, tap Shift then press 9.
>I recommend trying out sticky keys if your OS supports it, because your hands really feels better. It takes a while to switch mindset e.g. from M-x to M x (pressing one after the other), but it’s worth it. No less effective and less stress in the hands. - https://www.emacswiki.org/emacs/StickyModifiers
In Windows I place the sticky key icon in taskbar where I can see it instead of placing it inside the tray so that I can see the state of keys so as to avoid any confusion.
Also, use sticky keys (https://en.wikipedia.org/wiki/Sticky_keys)
I use all software with sticky keys enabled and I can't go back to a state without sticky keys. I wonder why others also don't use it. Stick with it for two or three full days and I am certain that you will love not having to press shift to capitalise text or how easy it is to press the Ctrl keyboard shortcuts in general. Not to talk about how easy it makes Emacs usage.
For exampe, to paste the URLs above, I pressed Shift with my left pinky and pressed Insert with right pinky one after the other, easier than contorting (it feels so now, after using sticky keys for some time, earlier it was okay) hand to press Ctrl-V. Also, to open and close brackets is real easy, tap Shift then press 9.
>I recommend trying out sticky keys if your OS supports it, because your hands really feels better. It takes a while to switch mindset e.g. from M-x to M x (pressing one after the other), but it’s worth it. No less effective and less stress in the hands. - https://www.emacswiki.org/emacs/StickyModifiers
In Windows I place the sticky key icon in taskbar where I can see it instead of placing it inside the tray so that I can see the state of keys so as to avoid any confusion.
You'll love KeyChord (https://www.emacswiki.org/emacs/KeyChord).
Yes they are nice. I always become indecisive when it comes to assigning keys with keychord.
Also, Sticky keys are system-wide as it is an OS provided feature. It makes life very easy, for example, to select text, just click where you want to start selecting and go to end of your selection, tap shift and click mouse, selected. I wish more people give it a chance.
Also, Sticky keys are system-wide as it is an OS provided feature. It makes life very easy, for example, to select text, just click where you want to start selecting and go to end of your selection, tap shift and click mouse, selected. I wish more people give it a chance.
Keychords are a bit of a pain in the ass if you type quickly and want to have mnemonic shortcuts.
In a job setting, don't. Integration is more important at first. Emacs is a way of life. You got a lisp, with beautiful libraries (binary parser, ~bnf parsers, hashtables, trees) that allow you to parse, interact, render data as you see fit at the tip of your fingers.
Lisp systems are dynamic, you can extend/modify them on the fly. It's a bit ugly but for a personal experience it beats Eclipse plugins by far. Most IDEs are fixed and complicated to modify. The way they understand UI and UX are also often subpar (magit is way more effective than most IDE versionning interfaces I've seen).
Emacs ain't perfect (~fragile shell integration, old culture => weird defaults), but its value offset its warts.
ps: Oh, and I forgot, you also have a symbolic calculator. Always handy.
Lisp systems are dynamic, you can extend/modify them on the fly. It's a bit ugly but for a personal experience it beats Eclipse plugins by far. Most IDEs are fixed and complicated to modify. The way they understand UI and UX are also often subpar (magit is way more effective than most IDE versionning interfaces I've seen).
Emacs ain't perfect (~fragile shell integration, old culture => weird defaults), but its value offset its warts.
ps: Oh, and I forgot, you also have a symbolic calculator. Always handy.
There's a subtle benefit that I haven't seen any of the other comments describe: the UI is made up of text, and I don't mean that in some curmudgeonly "things were better back in the day" way. I mean that all of the commands you use for navigating and manipulating text, moving between frames and windows and so on all use one consistent interface. With magit, I can be editing a file, hit Ctrl-C, g, then do some git manipulations and switch back to my work with a much smaller mental context switch.
And because all of the modes share that emacs feel (except for the vi-emulation, I guess), that knowledge is transferable across every language you work on, instead of learning a new (possibly proprietary) IDE for each new language.
And because all of the modes share that emacs feel (except for the vi-emulation, I guess), that knowledge is transferable across every language you work on, instead of learning a new (possibly proprietary) IDE for each new language.
Completely agree. I often got frustrated that the "modern" featureful IDEs don't allow me to incremental/regexp search in drop-down menu items nor to use set-mark-command + kill-ring-save keystrokes within dialog messages.
If you're working with something else than C#, Java or the like (i.e. languages that benefit hugely from features offered by IDEs (or that require IDEs to write in them and stay sane - if you're not feeling charitable)), then yes - benefits of speed, flexibility and efficiency. That's without even bringing up the topic of org-mode... :).
Can you give me some example of efficiency? I've always thought IDEs are more efficient, i.e. intellij IDEA indexes everything and provides superior auto-completion.
For your ordinary average everyday normal well-supported language, stick with the IDE.
But suppose you're working with some random language that nobody's ever heard of. It's some tool-, product- or site-specific thing. If you're very lucky, there's some ropey Scintilla-based text edit widget that lets you work with one file at a time. If you're not, there's quite literally fuck all. When you search on Google, there's 0 useful results (until you get to page 9, and there's 1 single post from somebody, on some random forum for general blarney, ranting about how they're doing some contract work and using this stupid language and it's terrible because there's no tools and they're stuck using notepad and their life sucks).
If you've got an IDE, now you're sort of stuck. Maybe you can find a language it supports that's a bit like, and then you've got syntax highlighting - sort of - and autoindent - maybe. But you have to do code browsing by grep, effectively, and you've got 0 in the way of code completion.
With emacs on the other hand you can relatively easily code up some language-specific support for syntax highlighting (takes 5 minutes) and autoindent (5 minutes for something basic, maybe 1-2 hours if you want to get fancy). Add some imenu regexps (5 minutes) and you've got code browsing from within a file. Put your imenu regexps into Exuberant Ctags (15 minutes), and you've got cross-file code browsing. Code completion... well... yeah... it's not perfect, but if you squint a bit, dabbrev (2 minutes if you need to tweak your syntax categories) is fine.
I've never failed to turn a time/effort/hassle profit from doing this.
But suppose you're working with some random language that nobody's ever heard of. It's some tool-, product- or site-specific thing. If you're very lucky, there's some ropey Scintilla-based text edit widget that lets you work with one file at a time. If you're not, there's quite literally fuck all. When you search on Google, there's 0 useful results (until you get to page 9, and there's 1 single post from somebody, on some random forum for general blarney, ranting about how they're doing some contract work and using this stupid language and it's terrible because there's no tools and they're stuck using notepad and their life sucks).
If you've got an IDE, now you're sort of stuck. Maybe you can find a language it supports that's a bit like, and then you've got syntax highlighting - sort of - and autoindent - maybe. But you have to do code browsing by grep, effectively, and you've got 0 in the way of code completion.
With emacs on the other hand you can relatively easily code up some language-specific support for syntax highlighting (takes 5 minutes) and autoindent (5 minutes for something basic, maybe 1-2 hours if you want to get fancy). Add some imenu regexps (5 minutes) and you've got code browsing from within a file. Put your imenu regexps into Exuberant Ctags (15 minutes), and you've got cross-file code browsing. Code completion... well... yeah... it's not perfect, but if you squint a bit, dabbrev (2 minutes if you need to tweak your syntax categories) is fine.
I've never failed to turn a time/effort/hassle profit from doing this.
Too much clicking in the IDE, though I guess this complaint goes more towards Eclipse than IDEA :).
But Emacs (and Vim) offer you superior text editing, if you can be bothered to learn it. Semantic navigation, convenient incremental search, semantic editing, keyboard macros, etc. etd. - you can do much more in fewer keystrokes, which is important in keeping yourself in the flow. In Emacs, you get all the benefits of highly optimized keyboard navigation and editing for every task you'd like to do - writing code, managing files, inserting simple and complex code templates, managing projects, complex work with Git repositories, etc. - and it's all consistent - you can do the same regex incremental search in e.g. your commit logs as you do in your source files.
My overall personal impression about Emacs is that it's the most efficient environment optimized for anything text-related out there (especially if you switch to vim keybindings for text editing and navigation, which are arguably smarter).
But Emacs (and Vim) offer you superior text editing, if you can be bothered to learn it. Semantic navigation, convenient incremental search, semantic editing, keyboard macros, etc. etd. - you can do much more in fewer keystrokes, which is important in keeping yourself in the flow. In Emacs, you get all the benefits of highly optimized keyboard navigation and editing for every task you'd like to do - writing code, managing files, inserting simple and complex code templates, managing projects, complex work with Git repositories, etc. - and it's all consistent - you can do the same regex incremental search in e.g. your commit logs as you do in your source files.
My overall personal impression about Emacs is that it's the most efficient environment optimized for anything text-related out there (especially if you switch to vim keybindings for text editing and navigation, which are arguably smarter).
I'm using emacs for a year now but I'm reallt bad at it, I wish there was a text like your comment with the words linked to specific webpages or videos which explain how to install everything you need for that word and show how to use it. I would link:
"Semantic navigation", "incremental search", "semantic editing", "keyboard macros", "optimized keyboard navigation", "inserting simple and complex code templates", "managing projects", "complex work with Git repositories", "regex incremental search"
"Semantic navigation", "incremental search", "semantic editing", "keyboard macros", "optimized keyboard navigation", "inserting simple and complex code templates", "managing projects", "complex work with Git repositories", "regex incremental search"
Something I learned way to late was to use the build in features for learning about functions and variables.
C-h f : find help for functions C-h v : find help for variables C-h k : Get help for a key-combination
If you have helm mode installed it's often very easy to find the functions you are looking for.
C-h f : find help for functions C-h v : find help for variables C-h k : Get help for a key-combination
If you have helm mode installed it's often very easy to find the functions you are looking for.
You're probably right about the autocompletion. I've never been able to get it to work particularly well in emacs (although I'm probably due another attempt). If you're focused on a particular target with a good IDE (i.e. Visual Studio, something by IntelliJ and probably nothing else) then they can be a good tool to use.
Among other things, I'm current developing some code for an Atmel chip. The environment for this is Atmel Studio (VisualStudio based), which has excellent Intellisense based autocomplete/navigation etc.. The thing is, I keep finding myself using emacs. Apart from the obvious 'force of habit' reasons for this, I think there are two factors:
1) Even with the autocomplete I still code faster in emacs. The various features like being able to load up multiple files at once on split windows, better facilities for swapping code around (I could go on) mean that it just goes faster. I still use the IDE for bits and pieces - it's particularly convenient for when I'm using unfamiliar parts ofthe hardware libraries - but I keep going back to emacs.
2) Developing for the Atmel is only ONE of the devices I'm targeting at the moment. I've got another ARM device (using Keil), a whole host of Python bits and pieces, a Windows GUI app. Being able to write the code for all of these in one place is unmatchable. Particularly as they interrelate and share code. It even helps the style look the same (where appropriate). A well configured emacs gives you a great development environment for anything.
Among other things, I'm current developing some code for an Atmel chip. The environment for this is Atmel Studio (VisualStudio based), which has excellent Intellisense based autocomplete/navigation etc.. The thing is, I keep finding myself using emacs. Apart from the obvious 'force of habit' reasons for this, I think there are two factors:
1) Even with the autocomplete I still code faster in emacs. The various features like being able to load up multiple files at once on split windows, better facilities for swapping code around (I could go on) mean that it just goes faster. I still use the IDE for bits and pieces - it's particularly convenient for when I'm using unfamiliar parts ofthe hardware libraries - but I keep going back to emacs.
2) Developing for the Atmel is only ONE of the devices I'm targeting at the moment. I've got another ARM device (using Keil), a whole host of Python bits and pieces, a Windows GUI app. Being able to write the code for all of these in one place is unmatchable. Particularly as they interrelate and share code. It even helps the style look the same (where appropriate). A well configured emacs gives you a great development environment for anything.
> indexes everything
So should your text editor (and/or it's companion programs)
> and provides superior auto-completion.
See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project[1])
Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)).
But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing.
I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing:
"7 Habits For Effective Text Editing 2.0": https://www.youtube.com/watch?v=p6K4iIMlouI
"Seven habits of effective text editing": http://www.moolenaar.net/habits.html
I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like 70% of the benefit of a true IDE, like a Smalltalk System coupled with a Object Database, or something simpler like a complete Forth system.
For better or worse, all current popular programming systems (that I'm aware of) has the hopeless abstraction of program text organized in file system files in folders (often coupled with half-integrated resource files, be they xml-layout, binary images, fonts or other stuff).
So no IDE can be effective, because the central abstraction remains only half-structured text, and you can only get that far with strapping semantic analysis on top. So as long as you're (forced to) working with text, programs that enable text editing and transformation will have an edge.
I don't think there's a wall between the two: you might want to use something like [1], or vim-mode in IDEA or something -- but if you want one effective tool to work with: Documentation, a handful of mark-up languages, a data language (like SQL), and a handful of programming languages (eg: assembler, C/C++, python), patch-files and perhaps writing email -- then I think text editors are going to be a good investment.
I do think that text editors (for writing code) is a kind of local maxima - but if we want to stick with traditional files and file systems (probably a terrible idea), they do help facilitate tools that have somewhat loose coupling (between editing, debugging, high-lighting, re-factoring, formatting) and I think that helps keep systems portable (you can take a similar set of C++ files and preform a similar set of transformation (with completely different tools) on Linux and Windows and end up with (different) binaries that preform a similar function.
Another great video that I think demonstrates text editing as different from "just" an IDE, is Russ Cox' short intro on ACME:
"A Tour of the Acme Editor": https://www.youtube.com/watch?v=dP1xVpMPn8M
In short, I suppose text editors are a superior user interface for interacting with text-like structures in general. The relative benefit for programmers depends a bit on what kind of system you work with: I'd prefer a simple, less verbose language, like Kotlin coupled with a plain editor, to an IDE coupled with more traditional Java (esp: Java 5) -- I firmly believe auto-generated code is a dark pattern: if it can be automated, it should be moved to a run-time or a library so that it can be maintained in one place, rather than leaving dead and possible buggy code in dark corners of a large code-base.
[1] http://eclim.org/
So should your text editor (and/or it's companion programs)
> and provides superior auto-completion.
See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project[1])
Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)).
But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing.
I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing:
"7 Habits For Effective Text Editing 2.0": https://www.youtube.com/watch?v=p6K4iIMlouI
"Seven habits of effective text editing": http://www.moolenaar.net/habits.html
I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like 70% of the benefit of a true IDE, like a Smalltalk System coupled with a Object Database, or something simpler like a complete Forth system.
For better or worse, all current popular programming systems (that I'm aware of) has the hopeless abstraction of program text organized in file system files in folders (often coupled with half-integrated resource files, be they xml-layout, binary images, fonts or other stuff).
So no IDE can be effective, because the central abstraction remains only half-structured text, and you can only get that far with strapping semantic analysis on top. So as long as you're (forced to) working with text, programs that enable text editing and transformation will have an edge.
I don't think there's a wall between the two: you might want to use something like [1], or vim-mode in IDEA or something -- but if you want one effective tool to work with: Documentation, a handful of mark-up languages, a data language (like SQL), and a handful of programming languages (eg: assembler, C/C++, python), patch-files and perhaps writing email -- then I think text editors are going to be a good investment.
I do think that text editors (for writing code) is a kind of local maxima - but if we want to stick with traditional files and file systems (probably a terrible idea), they do help facilitate tools that have somewhat loose coupling (between editing, debugging, high-lighting, re-factoring, formatting) and I think that helps keep systems portable (you can take a similar set of C++ files and preform a similar set of transformation (with completely different tools) on Linux and Windows and end up with (different) binaries that preform a similar function.
Another great video that I think demonstrates text editing as different from "just" an IDE, is Russ Cox' short intro on ACME:
"A Tour of the Acme Editor": https://www.youtube.com/watch?v=dP1xVpMPn8M
In short, I suppose text editors are a superior user interface for interacting with text-like structures in general. The relative benefit for programmers depends a bit on what kind of system you work with: I'd prefer a simple, less verbose language, like Kotlin coupled with a plain editor, to an IDE coupled with more traditional Java (esp: Java 5) -- I firmly believe auto-generated code is a dark pattern: if it can be automated, it should be moved to a run-time or a library so that it can be maintained in one place, rather than leaving dead and possible buggy code in dark corners of a large code-base.
[1] http://eclim.org/
The benefit is customization to your needs to make your unique workflow faster. There is a reason people spend tweaking their ".emacs.d" configurations - it just makes them so much faster. For example, I use a light theme in office because I have a glossy monitor and I prefer a dark theme otherwise, so I wrote a few lines of elisp to choose the light/dark theme based on the time of day and day of week. Try doing that in other editors / IDEs / etc. :) Of course, I'm quoting a trivial example here, but this is a glimpse to what is possible.
I'm an emacs evangelist and I'll use Eclipse or IntelliJ for Java. I have half a mind to just use a windows VM for visual studio because I think it's a great Python IDE.
But then there's everything else.
I've looked a great deal for a decent javascript IDE and I have yet to find one outside of Emacs. For a lot of languages I end up using in short spurts, I appreciate having a text editor that can do what I need it to do, and can do it consistently regardless of what I throw at it.
If I have boilerplate that I need to set up, building a yasnippet template is a piece of cake. If I need syntax highlighting, it's almost guaranteed that someone has gone down that road and has a mode already set up. If I need to migrate to a new machine, I pull in my .emacs from my git repo.
Little things that might be a challenge - like opening a file over SSH or needing kerberos authentication in order to edit a file - are challenges that have long since been dealt with.
There were two videos that brought me back to Emacs after years of using other editors - one was about python development in Emacs when I was looking for a python IDE, the other was a video about org-mode.
It took me two weeks of forcing myself to use Emacs before the muscle memory came back and I started preferring Emacs over vi again.
I wouldn't be too concerned about whether or not you should migrate to it. Use what you know. When you have a need for the power of emacs, you can safely ignore it the first five or ten times it pops up.
Eventually, you'll wander into a video how-to like I did and turn to the dark side. Or not.
But then there's everything else.
I've looked a great deal for a decent javascript IDE and I have yet to find one outside of Emacs. For a lot of languages I end up using in short spurts, I appreciate having a text editor that can do what I need it to do, and can do it consistently regardless of what I throw at it.
If I have boilerplate that I need to set up, building a yasnippet template is a piece of cake. If I need syntax highlighting, it's almost guaranteed that someone has gone down that road and has a mode already set up. If I need to migrate to a new machine, I pull in my .emacs from my git repo.
Little things that might be a challenge - like opening a file over SSH or needing kerberos authentication in order to edit a file - are challenges that have long since been dealt with.
There were two videos that brought me back to Emacs after years of using other editors - one was about python development in Emacs when I was looking for a python IDE, the other was a video about org-mode.
It took me two weeks of forcing myself to use Emacs before the muscle memory came back and I started preferring Emacs over vi again.
I wouldn't be too concerned about whether or not you should migrate to it. Use what you know. When you have a need for the power of emacs, you can safely ignore it the first five or ten times it pops up.
Eventually, you'll wander into a video how-to like I did and turn to the dark side. Or not.
The biggest benefit of using Emacs is easily fixing and altering its behavior to meet your wants ... crafting your editor.
For me, when I use an IDE I feel like I'm learning/using the IDE, not the language it self. I found that I was somewhat dependent on the IDE. Then I switched to vim and started learning how to actually build projects from the ground up.
I've noticed that a lot of people who use IDEs can't use anything else. Want to build an Android app? There are people who can not build an Android app without eclipse.
After learning Vim I was able to use it just like an IDE and I felt like I had a better understanding of how the projects I was building actually work.
I've noticed that a lot of people who use IDEs can't use anything else. Want to build an Android app? There are people who can not build an Android app without eclipse.
After learning Vim I was able to use it just like an IDE and I felt like I had a better understanding of how the projects I was building actually work.
No genuine ones. There are some extremely few ones, but they're all related to "some people use emacs and it's good for you to fit in with them" (for instance, I recall a proof assistant some years ago which was painful to use without the associated emacs mode).
Any advantage gained from the interface are small enough that they're not worth introducing another mental mode for. Any time you sit down at a keyboard and have to mentally remap ("copy works differently here", "shortcuts are different here", "that thing you do all the time must be done in a very different way here"), it's mental capacity out the window. When you do a task, you want your interface to be as similar as possible to the interfaces you're used to when doing related tasks.
Emacs could have become the common, core interface for working on a computer (unlike vi, I'd say) - but it didn't. The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.
Any advantage gained from the interface are small enough that they're not worth introducing another mental mode for. Any time you sit down at a keyboard and have to mentally remap ("copy works differently here", "shortcuts are different here", "that thing you do all the time must be done in a very different way here"), it's mental capacity out the window. When you do a task, you want your interface to be as similar as possible to the interfaces you're used to when doing related tasks.
Emacs could have become the common, core interface for working on a computer (unlike vi, I'd say) - but it didn't. The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.
> Any time you sit down at a keyboard and have to mentally remap ("copy works differently here", "shortcuts are different here", "that thing you do all the time must be done in a very different way here"), it's mental capacity out the window.
That's true, which is why I use only Linux, only StumpWM, only emacs. Using anything else slows me down and gets in my way.
> The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.
There's nothing to master, because the languages those tools offer aren't expressive enough to require any mastering. They're two steps above pointing and grunting, while emacs is poetry.
That's true, which is why I use only Linux, only StumpWM, only emacs. Using anything else slows me down and gets in my way.
> The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.
There's nothing to master, because the languages those tools offer aren't expressive enough to require any mastering. They're two steps above pointing and grunting, while emacs is poetry.
As a middle aged computer scientist and emacs evangelist, I had to laugh pretty hard at this one. I hadn't actually heard that one before.
:-)
This was already true back when I started using Emacs in my teens. Now that I'm middle-aged myself...
This was already true back when I started using Emacs in my teens. Now that I'm middle-aged myself...
Generally Not Used Except by Middle Aged Computer Scientists.
Haven't seen that one before, but well, congratulations for making me feel old. ;).
Today I had to use non emacs windows editors for an hour. All of them a subset of what I'd like. I grabbed a copy of emacs for windows build. My blood pressure lowered as I saw the splash screen. Freedom and extensibility. It's impossible to fully appreciate right away. But having an appealing website is always good.
>the learning curve of emacs that isn't exactly beginner-friendly
I started to learn emacs in 2006 after a friend show it to me in it's no-window version in a OS X Teminal. We were at the time art students and most of us didn't have programing education. Some people were playing a bit of advanced flash or Max (proprietary Pure Data sound processing), but most of us were doing performing art, sculpture, sound or painting.
Honestly, I have been so motivated by what I discovered, that, the learning curve hasn't been so bad. The folkloric keyboard shortcuts were easy to memorize and the software never failed me. I stopped using Text Edit and the horrible .rtf format and I learned that plaintext was surely more appropriate to write poetry. And wait what is it? Markdown?
I started to open mp3s in text mode and grep into videos. It was really exciting. It was possible to open incredibly huge files in text mode, and the computer was still usable. Wait... Why common browsers slow the machine down when you try to open Gmail then?
I discovered a land of wonder full of funny animals, meaningful laws texts (I mean GNU license) and documentation to read until the end of your life.
In 2008 I ordered GNU Emacs Manual 16th edition with a tee shirt, the reference card is still on my desk.
This piece of software is usable, accessible, documented, and it is still possible to use it 30 years after it's creation. Let's be honest: what is the aim of having a fast-learning-curve if you learn tools that you won't use in 2 years. If the tool is a bit hard to learn but we'll designed, it maybe worth the effort.
I started to learn emacs in 2006 after a friend show it to me in it's no-window version in a OS X Teminal. We were at the time art students and most of us didn't have programing education. Some people were playing a bit of advanced flash or Max (proprietary Pure Data sound processing), but most of us were doing performing art, sculpture, sound or painting.
Honestly, I have been so motivated by what I discovered, that, the learning curve hasn't been so bad. The folkloric keyboard shortcuts were easy to memorize and the software never failed me. I stopped using Text Edit and the horrible .rtf format and I learned that plaintext was surely more appropriate to write poetry. And wait what is it? Markdown?
I started to open mp3s in text mode and grep into videos. It was really exciting. It was possible to open incredibly huge files in text mode, and the computer was still usable. Wait... Why common browsers slow the machine down when you try to open Gmail then?
I discovered a land of wonder full of funny animals, meaningful laws texts (I mean GNU license) and documentation to read until the end of your life.
In 2008 I ordered GNU Emacs Manual 16th edition with a tee shirt, the reference card is still on my desk.
This piece of software is usable, accessible, documented, and it is still possible to use it 30 years after it's creation. Let's be honest: what is the aim of having a fast-learning-curve if you learn tools that you won't use in 2 years. If the tool is a bit hard to learn but we'll designed, it maybe worth the effort.
Talk about judging a book by its cover. Did he say anything specific about the source of his discomfort? If I'm looking for a text editor, I'm not sure how it matters whether or not its web site is full of images, fonts and colorful reactive javascript modern HTML. All I need is a download link.
> All I need is a download link.
A download link is less useful if you want to find out about an editor vs just trying it (especially with Emacs when you first open the program, the killer features are not immediately apparent).
The old site showed a change log, which seems much for like a site for current users than a site for new users.
A download link is less useful if you want to find out about an editor vs just trying it (especially with Emacs when you first open the program, the killer features are not immediately apparent).
The old site showed a change log, which seems much for like a site for current users than a site for new users.
At least for me the change log is one of the first items I read when looking to try new software.
It often tells quite a lot about how involved the developers are, what direction the project is heading to, or how mature it is overall.
It often tells quite a lot about how involved the developers are, what direction the project is heading to, or how mature it is overall.
Prettiness signals professionalism and competence.
[deleted]
I'm not sure the new design is a good thing because using Emacs is like entering another world. If newbies have the impression that it's just another editor like all the others with fancy websites they will be quickly disappointed. On the other hand, if they are looking for something that challenges their understanding of what an editor, or software for that matter, should be then they may be motivated to overcome more hurdles such as an archaic homepage.
>He went to the website which looked incredibly outdated to the expectations of new programmers, and just felt uncomfortable giving it a try. He opted for an editor with a more modern website.
Sounds like a personal problem to me, I love most of the GNU projects' pages. Simple, readable, low-bandwidth, to the point.
https://web.archive.org/web/20160101125451/https://www.gnu.o... for ex
Sounds like a personal problem to me, I love most of the GNU projects' pages. Simple, readable, low-bandwidth, to the point.
https://web.archive.org/web/20160101125451/https://www.gnu.o... for ex
That's fairly shallow to base a decision to use an OS on.
All kidding aside though, it seriously is. It's not a bad piece of software.
All kidding aside though, it seriously is. It's not a bad piece of software.
As someone semi-new to using emacs, (I knew basic keybindings but never bothered to set up init files, etc.) coming from the IDE world, my biggest complaint was the amount of things I had to do to get vanilla emacs to behave in a civilized way, even using the GUI version. I spent hours scouring peoples emacs files on GitHub to try and find all the things that looked "obvious in retrospect" and settings that looked silly to have turned off by default (e.g. commands that act on regions should act on lines when no region is selected). Then my second biggest complaint was the analysis paralysis of all the plugins. I'm starting to get a stable emacs file, after a few months, but there's still several pieces of functionality I miss from my IDEs that I chunk out time every now and then to research and add. I think having a "if you're coming from IDEs you may want to install X Y Z" page would be helpful, as well as package download rankings so that people can find the popular projects (e.g. helm, use-package). It should also be prominently encouraged to use something like guru-mode where it disables the arrow keys to force you to use ctrl and meta as your movement keys.
Also you can pry Magit from my cold, dead hands.
Also you can pry Magit from my cold, dead hands.
There are historical reasons for pretty much all default settings. For example, you said:
The way Emacs was (and is) designed to work is that all region-based commands simply apply their function on the characters between point and mark. Since there isn't any "selection" as such, talking about what commands do without the selection simply does not make sense.
Now, in (what I consider to be) a misguided appeal to users of "windows style" editors, Emacs introduced the concept of "active regions". The underlying concept of having a point and mark is still there, but there is now also a flag indicating whether a region is "active" or not. Commands can look at this flag to perform different operations whether or not this is the case. Since several years, active regions has been enabled by default in Emacs.
The problem when having active regions enabled is that in many cases the user has to reactivate the region before performing some operations, making many region-based operations much more complicated[1] to use.
I seem to have become to the go-to person for Emacs support at my workplace, and I have seen a lot of new users being confused about regions in Emacs. Instead of adding even more Elisp code to try to coerce the application into behaving more like Notepad, I typically recommend them to turn off active regions and learn Emacs the way it was meant to be used. It's certainly different from most other editors, but the behaviour makes a lot more sense once you pick it up.
Footnotes: [1] I used the word "complicated" to mean "needs more keypresses".
"e.g. commands that act on regions should act on lines when no region is selected"
The way Emacs was (and is) designed to work is that all region-based commands simply apply their function on the characters between point and mark. Since there isn't any "selection" as such, talking about what commands do without the selection simply does not make sense.
Now, in (what I consider to be) a misguided appeal to users of "windows style" editors, Emacs introduced the concept of "active regions". The underlying concept of having a point and mark is still there, but there is now also a flag indicating whether a region is "active" or not. Commands can look at this flag to perform different operations whether or not this is the case. Since several years, active regions has been enabled by default in Emacs.
The problem when having active regions enabled is that in many cases the user has to reactivate the region before performing some operations, making many region-based operations much more complicated[1] to use.
I seem to have become to the go-to person for Emacs support at my workplace, and I have seen a lot of new users being confused about regions in Emacs. Instead of adding even more Elisp code to try to coerce the application into behaving more like Notepad, I typically recommend them to turn off active regions and learn Emacs the way it was meant to be used. It's certainly different from most other editors, but the behaviour makes a lot more sense once you pick it up.
Footnotes: [1] I used the word "complicated" to mean "needs more keypresses".
> There are historical reasons for pretty much all default settings
Don't you see it as a problem? Anyone new coming has to go through all the history to get an understanding of why things work the way they work. Other software evolve over time and follow practices that result in better UX.
Don't you see it as a problem? Anyone new coming has to go through all the history to get an understanding of why things work the way they work. Other software evolve over time and follow practices that result in better UX.
The obvious point is that everyone disagrees about "settings that look silly to have turned off by default".
A lot of modern software uses the 'opinionated' approach. The designers come up with their preferred way of using the software product, and build the user experience around that. This gives great results a lot of the time - you get a consistent and unsurprising experience and you can build a very intuitive experience. To pick a silly example of this, Google Chrome tries very hard to prevent the expansion of extra 'settings'. That way everyone is using the browser in the same way (this has security benefits too).
Emacs goes completely the other way. It gives you the tools to tweak absolutely every aspect of your usage, and while it may have some defaults it isn't really opinionated about which is right. It's been said many times - emacs isn't a text editor, it's a platform on which developers can build their own ideal text editor.
That isn't to say that there aren't some silly things in the defaults, but the emacs developers appear to continue to actively tweak the defaults in the direction of being ever more sensible.
A lot of modern software uses the 'opinionated' approach. The designers come up with their preferred way of using the software product, and build the user experience around that. This gives great results a lot of the time - you get a consistent and unsurprising experience and you can build a very intuitive experience. To pick a silly example of this, Google Chrome tries very hard to prevent the expansion of extra 'settings'. That way everyone is using the browser in the same way (this has security benefits too).
Emacs goes completely the other way. It gives you the tools to tweak absolutely every aspect of your usage, and while it may have some defaults it isn't really opinionated about which is right. It's been said many times - emacs isn't a text editor, it's a platform on which developers can build their own ideal text editor.
That isn't to say that there aren't some silly things in the defaults, but the emacs developers appear to continue to actively tweak the defaults in the direction of being ever more sensible.
Many times I find that sensible human beings can make sensible defaults. It tends to align with software I love to use. Being opinionated is not a sin if done right. Config hell is not a solution to this problem.
The "problem" is that there are so many different use cases. There are people using emacs on strange systems for decades and their opinions vastly differ from a new user looking for a javascript environment. There are lots of opinions in emacs, and usually when you want to do something to core you find out that there's a wide swath of users who have the opposite opinion to what you were thinking. It's not a bad thing, its just tough to do anything because there are so many packages, users, expectations, ranging from 1-25 years of behavior.
I very carefully didn't say being opinionated it was a sin, in fact I said completely the opposite. That design approach has produced some brilliant stuff (e.g. anything produced by Apple).
My point was that it wasn't the ONLY approach. It appears to be the best one for mass market consumer products, but developers do so many different things in so many different ways that a different approach might be more appropriate. Based on emacs' enduring popularity with a large chunk of users, it would appear that a lot of people agree.
My point was that it wasn't the ONLY approach. It appears to be the best one for mass market consumer products, but developers do so many different things in so many different ways that a different approach might be more appropriate. Based on emacs' enduring popularity with a large chunk of users, it would appear that a lot of people agree.
Nothing wrong with using the arrow keys. I can't even remember how long I've been using Emacs and still use the arrow keys.
Three weeks on my work machine I disabled the arrow keys and am now forced to use C-, M-, for navigation, the first week was a bit slow I had to keep stopping and thinking, But now just three weeks later my screen movements are much more efficient and faster.
I recommend you give it a try.
That's precisely where I'm at currently -- 2 days into having the arrows disabled. It tells me what key I should have pressed relative to the arrow I pressed, but you take a second to stop and think "is that REALLY what I wanted? could I do this more efficiently?"
I've never found most of the emacs navigation keys to be particularly useful. I do not want to be hitting C-n or C-f more than one time.
I use ace-jump-mode for almost all of my movement. I can go straight to where I want to with a fraction of the effort.
I use ace-jump-mode for almost all of my movement. I can go straight to where I want to with a fraction of the effort.
Perhaps it's different for me since I use a keyboard, the Kinesis Advantage, where I don't have to move my hand to find the arrow keys.
I recommend using https://github.com/technomancy/better-defaults as it's just about the only customization I do to Emacs.
I'd suggest Spacemacs offers a better set of defaults than vanilla Emacs. Spacemacs would be a better choice for many newbies IMO.
http://spacemacs.org/
http://spacemacs.org/
See it's a tough balance. To me, the fun of emacs is getting it exactly as you like and continually optimizing little things. By not having to do SOME painful stuff, you miss out on appreciating the minutia that goes into it. At the same time, many of emacs default settings are very strange so starting with some sanity would be better for newcomers. Maybe some sort of "these are common tweaks that people make right off the bat" page would be the way to go. That way people have to do it themselves (outside of using e.g. spacemacs or prelude) but they have a common place to go to find out about those things. Or at least link to some well known emacs files for developers that code in major languages (a C guy, a Java guy, ...) to give people a place to go to read some elisp and get a feel for what people to do to their editors.
that's actually another nice thing about spacemacs. Install the Java layer and read its documentation, and you'll have a decently curated experience with several plugins set up for you. At least, assuming the maintainer of the Java layer is any good. That definitely addressed choice paralysis for me
The site seems to be having some trouble, so from the Wayback machine:
The previous site https://web.archive.org/web/20150522051725/http://www.gnu.or...
The new site on the 20th of April https://web.archive.org/web/20160420170002/http://www.gnu.or...
The previous site https://web.archive.org/web/20150522051725/http://www.gnu.or...
The new site on the 20th of April https://web.archive.org/web/20160420170002/http://www.gnu.or...
https:// site is down, http://www.gnu.org/software/emacs/ is live.
URL changed to http: version, thanks.
Heh, and now the http is down. I think HN might be the cause. :)
Works for me, but it's slow
[deleted]
Looks nice, but having a 1.1MB webpage with 7 different fonts seems somewhat wrong to me... We should start thinking about mobile clients who have to pay these MB.
If there's one product whose website can probably get away with not caring about mobile, it's a power-user text editor from the 1970s.
I run Emacs under termux on my Nexus 6P. Works great with exactly the same config I use on the desktop.
What keyboard do you use? Key combos are soooo slow on a touchscreen keyboard.
Yeah, if you can't handle a meg of downloads, are you sure you can handle the hundreds of megs of memory? :)
1980s :)
EMACS is from the 1970s, GNU Emacs 1980s...
EMACS is from the 1970s, GNU Emacs 1980s...
I think they should start to consider mobile clients once those have a hyper key...
I'm all for lean sites but emacs' site is one of those where I just don't care. Emacs users are sitting in front of a workstation and if they don't have a proper internet connection, they just install it from their unix distribution's CD/DVD.
And it is also kind of adequate to have a bloated website... anyone remembers the joke to name a kernel "emacs" so that it says "LILO booting emacs..." at startup? ;)
I'm all for lean sites but emacs' site is one of those where I just don't care. Emacs users are sitting in front of a workstation and if they don't have a proper internet connection, they just install it from their unix distribution's CD/DVD.
And it is also kind of adequate to have a bloated website... anyone remembers the joke to name a kernel "emacs" so that it says "LILO booting emacs..." at startup? ;)
Eight Megabytes And Constantly Swapping (back when 8 MB was a lot)
Or, more appropriate when explaining why it's not a good fit for touchscreens:
Esc Meta Alt Control Shift
Or, more appropriate when explaining why it's not a good fit for touchscreens:
Esc Meta Alt Control Shift
They use Fira Sans and Fira Mono in a bunch of different weights.
Looking at the source for <http://www.gnu.org/software/emacs/fira.css>, I can't help but wonder if mobile^W OS vendors could make the Web faster for their users if they'd just bundle every single popular free (beer and/or speech) font with their OSs and keep the fonts up-to-date.
Of course, you should be sending along far-future Expires and Cache-Control headers, but this'll still be slower than local() accessing fonts that're bundled with the OS when someone visits a new site.
Looking at the source for <http://www.gnu.org/software/emacs/fira.css>, I can't help but wonder if mobile^W OS vendors could make the Web faster for their users if they'd just bundle every single popular free (beer and/or speech) font with their OSs and keep the fonts up-to-date.
Of course, you should be sending along far-future Expires and Cache-Control headers, but this'll still be slower than local() accessing fonts that're bundled with the OS when someone visits a new site.
Then the question: which fonts should they bundle!? etc...
they're working toward making it Eight Megabytes And Constantly Swapping
Yea, it's a bit heavy of a load.
I clicked the link, came back, and read this commend. Doesn't mean much, but it would have helped if the site was a tad smaller.
I clicked the link, came back, and read this commend. Doesn't mean much, but it would have helped if the site was a tad smaller.
Given what people have observed about mean WWW page size ...
* https://news.ycombinator.com/item?id=9980228
* https://news.ycombinator.com/item?id=11548816
... what can be said now about the relative sizes of GNU emacs and its own WWW page? (-:
* https://news.ycombinator.com/item?id=9980228
* https://news.ycombinator.com/item?id=11548816
... what can be said now about the relative sizes of GNU emacs and its own WWW page? (-:
For those who might not realise it, the distribution is 600kb(!) in fonts, 400k in images, 100k in other stuff
Do most plans not have unlimited data in America?
It would be nice, if they will merge patches [1] for truecolor (16M colors) support in their console incarnation of emacs. Both Vim [2] and Neovim [3] already did this. Since most terminal emulators now support this mode [4], that will improve syntax highlighting and theme customizing to a new level.
[1] http://emacs.1067599.n5.nabble.com/RFC-Add-tty-True-Color-su...
[2] https://github.com/vim/vim/commit/8a633e3427b47286869aa4b96f...
[3] https://github.com/neovim/neovim/commit/8dd415e887923f99ab5d...
[4] https://gist.github.com/XVilka/8346728
[1] http://emacs.1067599.n5.nabble.com/RFC-Add-tty-True-Color-su...
[2] https://github.com/vim/vim/commit/8a633e3427b47286869aa4b96f...
[3] https://github.com/neovim/neovim/commit/8dd415e887923f99ab5d...
[4] https://gist.github.com/XVilka/8346728
By framing this is a matter of patches getting merged, you imply that there is nothing else in the way. In fact, there is no proper terminfo support for true color[1], nor even a standard, canonical way to detect true color support. All that exists now is an encoding convention which has promising adoption but which is by no means uncontroversial[2]. When you couple the portability issue with the increased memory footprint and the lack of a clear and compelling use-case, it is not surprising that this is not a priority for emacs developers.
[1] https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg00...
[2] http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001834...
[1] https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg00...
[2] http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001834...
I wish it could be suppported by terminfo, but as long as its developer reject to do any work to extent terminfo to support truecolor, I'll promote this standard without dependency from terminfo. Also, speaking about 'modern' mechanism he means to use 'ncurses', but as you can see, a lot of console programs prefer not to use this library.
You can add console-terminal-emulator in the nosh toolset to the list. It's had this since its first version.
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Its manual page (herewith a slightly outdated version) calls out the ISO/IEC 8613-6 parameter separator problem in its section on differences from real terminals and documented standards.
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Its manual page (herewith a slightly outdated version) calls out the ISO/IEC 8613-6 parameter separator problem in its section on differences from real terminals and documented standards.
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Even worse is running a terminal inside of emacs. ansi-term can only display 8 colors, even though the editor it's running in can support (at least) 256. As someone who runs a large percentage of their shells inside of emacs, this is a particular annoyance, especially because presumably adding in the remaining colors would be a trivial task for someone familiar with the code.
I used to be bothered by this, and then I realized for every thing I wanted to do in the terminal, 5 minutes of searching would usually find a superior UI to do the same task in an Emacs-native way that I could effortlessly customize, rebind keys, add hooks for, and rewrite functionality live. About the only exception I can think for this is htop; M-x proced does most of the same things but doesn't look as nice doing it.
+1 for this. It's basically impossible to get emacs colors to work correctly in the terminal.
And as soon as you complain you are confronted with "emacs is supposed to be run with the graphical interface, just install it with the gui and don't use -nw (no window) option"... yeah, right... no thanks.
Nobody says that.
But don't complain, better submit a patch. Or help ironing out the one linked above, it's unfinished.
But don't complain, better submit a patch. Or help ironing out the one linked above, it's unfinished.
I am not saying it's an official stance or such, not saying you are someone who would say that, but don't tell me "nobody says that" when that was what I got multiple times from emacs users.
If I hadn't then why would I say so?
If I hadn't then why would I say so?
All right. It's not an official stance, and a lot of users are know prefer using Emacs in a terminal (not myself, though). But some others might say that.
But what use is there to complain to them? None of them sound to be anywhere close to the Emacs development.
But what use is there to complain to them? None of them sound to be anywhere close to the Emacs development.
I actually say that :)
I just think the graphical Emacs provides the most comfortable environment. It displays images (and thus also PDF files or a graphical browser widget), doesn't swallow the Alt key by default, has prettier colours, and you still get to edit remote files with TRAMP.
This doesn't mean that Emacs in a terminal should not be improved. I sometimes use it when I ssh into my workstation from a machine that doesn't have Emacs installed.
I just think the graphical Emacs provides the most comfortable environment. It displays images (and thus also PDF files or a graphical browser widget), doesn't swallow the Alt key by default, has prettier colours, and you still get to edit remote files with TRAMP.
This doesn't mean that Emacs in a terminal should not be improved. I sometimes use it when I ssh into my workstation from a machine that doesn't have Emacs installed.
Exactly. This is one of the main reasons why I encourage admins and developers to try Vi(m): There will always be a vi or vim installed wherever you SSH to, and you will be able to work comfortably on the terminal.
Weird; I've never needed to do anything more than "export TERM=xterm-256colors" provided I was using a high-color terminal emulator to begin with.
Surprised to see the demo videos were captured on OS X and not GNU/Linux.
The emacsrocks videos existed before the website refresh and weren't created for gnu.org, but I can imagine Richard asking for new videos to advertise the GNU platform instead.
> I can imagine Richard asking for new videos to advertise the GNU platform instead.
Me too. He often asks for corrections in light of these types of oversights (at least, it looks like an oversight to me).
Me too. He often asks for corrections in light of these types of oversights (at least, it looks like an oversight to me).
Yeah this is what I figured, still kind of surprised to see the new site go live with them. It isn't all that difficult to make a simple screencast on Linux to show off some of the basics.
I just wanted to be annoying: https://www.gnu.org/gnu/gnu-linux-faq.html
Call it GNU or call it Linux. GNU/Linux is just stupid
Call it by the distribution name. Calling debian and android by the same name is silly if the only common software is the kernel and a bunch of universal tools and libraries.
I don't know about Android but it's not silly at all to call Debian, Fedora and Ubuntu by a common name. I do it all the time.
Ubuntu is a Debian-based operative system. Using the name "Debian" for both makes perfect good sense.
Fedora, i.e. Red Hat, is very distinct from Debian. A Debian software package is not guaranteed to work on Fedora, nor is a Red Hat package guaranteed to work in Debian. Both try to be semi-compatible with each other, but that does not make them identical.
A common name used in the past is "Unix" or "Unix compatible", but then what is not Unix compatible today? We could be talking about Linux compatible, but then, the vast majority of programs will work on BSD kernel as well as Linux kernels, while having stronger compatibility demands on distribution-specific technology. Maybe "systemd" or "systemd compatible" should be the new OS name?
If you tell me the distribution of your OS, it will tell me enough information to make or identify compatible software. What property is more important than that in a name?
Fedora, i.e. Red Hat, is very distinct from Debian. A Debian software package is not guaranteed to work on Fedora, nor is a Red Hat package guaranteed to work in Debian. Both try to be semi-compatible with each other, but that does not make them identical.
A common name used in the past is "Unix" or "Unix compatible", but then what is not Unix compatible today? We could be talking about Linux compatible, but then, the vast majority of programs will work on BSD kernel as well as Linux kernels, while having stronger compatibility demands on distribution-specific technology. Maybe "systemd" or "systemd compatible" should be the new OS name?
If you tell me the distribution of your OS, it will tell me enough information to make or identify compatible software. What property is more important than that in a name?
ok I'll remember it for the next time I chat with you. But come on dude, most people don't care about the distribution I use, knowing that I use Linux (the OS, not the kernel) and not Windows or OSX is what they want to know. All the rest is literature. Really.
Okay. Debian GNU/Linux. Fedora GNU/Linux. openSUSE GNU/Linux.
I'm surprised they weren't captured from within Emacs using some janky elisp video encoder.
Someone went for quality and not purity, actually picking interesting videos instead of clips of someone describing the basics in a monotone.
Yup, but the main screenshot looks like Gnome, so I think it actually works quite well to show how cross platform Emacs is.
Hmm, I'm not so sure that's what the intention is. The FSF is adamant that non-free software should not be promoted if there is a free equivalent that can do the same thing. So I'm also surprised that OS X features prominently, like this, on the front page.
This is nothing, what about attending FOSDEM and seeing the majority carrying iDevices?
Your comment made me look again at the list of FSF endorsed OSs:
http://www.gnu.org/distros/free-distros.en.html
I'm still surprised at how few there are.
http://www.gnu.org/distros/free-distros.en.html
I'm still surprised at how few there are.
http://www.gnu.org/distros/common-distros.en.html
This explains why many are not considered free, though the summary could simply be "the Linux kernel contains non-free blobs" and "they haven't promised not to allow non-free in their package repo's"
This explains why many are not considered free, though the summary could simply be "the Linux kernel contains non-free blobs" and "they haven't promised not to allow non-free in their package repo's"
I've seen that a lot in Emacs videos and screenshots, the last few years.
Even in videos and screenshots that are endorsed by the FSF? I find that hard to believe.
Believing in things nobody actually said is of variable difficulty.
But of course screenshots and videos made in OS X are available, especially considering Emacs has been running on that OS since forever. The point of interest here is that it's on an FSF website. Otherwise I don't see why you would even bother to point it out.
1) I'm an Emacs user and enthusiast.
2) I look into a lot of videos about Emacs.
3) I've noticed that, recently, many of these videos and screenshots are by people using OS X.
4) Someone wondered about an OS X video on the Emacs site.
5) I pointed out #3.
2) I look into a lot of videos about Emacs.
3) I've noticed that, recently, many of these videos and screenshots are by people using OS X.
4) Someone wondered about an OS X video on the Emacs site.
5) I pointed out #3.
I hope that with the change of maintainer we, emacs users, can have some sanity regarding that concern and avoid the "emacs as a trojan horse so everyone switches to gnu" mentality.
The videos are from emacsrocks.com, not from the GNU website itself.
Not too surprising, OSX is a common platform for devs who are linux/unix-oriented but want a high-level OS with all the sleek GUIs and mainstream features. OSX is a certified Unix OS, after all, so it tends to speak to emacs users in a way that you won't typically find among the Windows base.
Yes Unix is not Linux, but I see OSX widely used at hackathons and conferences because of its underpinnings.
Yes Unix is not Linux, but I see OSX widely used at hackathons and conferences because of its underpinnings.
I think the OP's point was more targeted toward the fact that OSX is a non-free operating system, and Emacs is part of the GNU project.
Yes. I doubt that somebody who was so close to the GNU project as to have authorization to change the main Emacs website wouldn't know about this. Clearly it's just a simple mistake, easily fixed.
The issue is not that the OS is not Linux, it's that the OS is not free
One of the points of FSF is to never use closed software. OSX is not GPL.
"Free" does not mean "GPL" only. If OSX were released under any of the many free licenses it would be fine, but sadly it is just proprietary software with some free components.
Well, to get picky about it, I believe the exception is that it's ok to use it while a non-closed alternative is in the works. I think the example Stallman uses in his talks is that of software controlling a life saving medical device.
Obviously the use case in point doesn't come under that though. :)
Obviously the use case in point doesn't come under that though. :)
Makes me wonder why they have compatibility shims to allow their website show in browers like IE6...
Yes, it's pedantic, but this GNU we are speaking about.
Yes, it's pedantic, but this GNU we are speaking about.
That would actually make sense. It might help more people see the light.
Really? You think if I recommend emacs to someone using IE6 and they go view the site and it fails to display, that will somehow make them 'see the light'? I suspect the complete opposite is true and, hence, why gnu support browsers that aren't 100% GPLed.
Nobody is saying that it is practical, but GNU aren't known to make their stance on practicalities alone. GNU are known for their ideological purity, and a lot of people (some even quite grudgingly) admire them for their consistent stance.
I'm sure they've addressed this very issue. They almost certainly just write to the standards and don't bother putting in any browser-specific hacks, which is pretty much the best way to do things anyway, IMHO.
I saw at least one IE6 specific hack in their pages.
You seem to be in agreement with the person you're replying to. They're saying that there's a compatibility shim so that more IE6 users can 'see the light'.
What kind of video capture options does a hurd user have available.
Most likely they were created by the one who made the website, which most likely used OS X like most designers :p
With explanations like this, guinea pigs could fly.
Designers rarely make a website - they just design it.
It looks real snazzy and nice. But I always liked that the GNU project did not try to look like the latest fad out of SV. Their low-fi HTML4 approach meant they could be browsed in anything and still be perfectly readable.
The markup is very clean, and the page still works fine with css disabled.
The new site is responsive
Another piece of "marketing" collateral that can help popularize Emacs is a "tour of Emacs" video. Awhile back, I watched Russ Cox's "Tour of Acme" video and became an Acme convert as a result.
In the end, an editor is a productivity tool, and the best way to evaluate it is seeing it in action as part of a workflow: video is an excellent format to capture and share this with newcomers.
In the end, an editor is a productivity tool, and the best way to evaluate it is seeing it in action as part of a workflow: video is an excellent format to capture and share this with newcomers.
My thoughts exactly. Personally, that's why I can't justify spending all that time trying to figure out a text editor when I could be, I don't know, working.
Seems like GNU is going through a brand/design update. First Guile[1] then this!
[1] https://www.gnu.org/software/guile/
[1] https://www.gnu.org/software/guile/
They also have a good project [1] of migrating Emacs codebase and plugins support on Guile - partly by adding Elisp support in Guile, partly by rewriting Emacs itself.
[1] https://www.emacswiki.org/emacs/GuileEmacs
[1] https://www.emacswiki.org/emacs/GuileEmacs
I followed this a bit during the GSOCs. Seems to have stalled unfortunately?
I think Vims website could do with a facelift too:
http://www.vim.org/
https://news.ycombinator.com/item?id=5458874
The vim website needs an update !
Thats the first thing I think every time I go there.
Not just the website but the icon as well.
There is lots of IDE vs emacs discussion in this subject.
I have been using primarily (IntelliJ+IdeaVim) and sometimes (Emacs+evil) for the last few years.
If I want to write big, complex change in a codebase in Java/Scala/Python/Javascript I would use IntelliJ. Yet IntelliJ doesn't work well in many corner cases, like very big codebases, projects in C/C++ or languages not officially supported by Jetbrains, cross language projects (even with IJ Ultimate), remote editing or just quickly opening some github repo without spending time on any project setup. And extra emacs packages like magit and org-mode are irreplaceable.
Given the emacs flexibility I was able to configure Emacs to implement majority of IntelliJ keybindings. There usually is an equivalent emacs function of package for IntelliJ behavior, e.g. M-x and IntelliJ "Find Action". Emacs helm works a lot like fuzzy matching in IntelliJ. Sometimes I only implement the "similar" behaviour, e.g. "Show usages" vs "Grep for text at point in current project" in IJ. I will be writing a blog post about it at kozikow.wordpress.com, but if you are interested now now I can send you my .emacs.d.
In this setup I can just setup "fast, always works and easy to set up, but not too powerful" code navigation using ctags/ggtags, grep/ag and projectile in emacs and avoid packages like EDT, eclim-emacs or Jedi that are more powerful, but sometimes require custom per repository setup, or are slow. I usually have both emacs and IJ opened and switch between the two. I have a keybinding in both editors for "open current file in the other editor" (emacsclient + external tool in IJ).
So in the spirit of motto of Spacemacs - "The best editor is neither Emacs nor Vim nor IntelliJ, it's Emacs and Vim and IntelliJ!"
If I want to write big, complex change in a codebase in Java/Scala/Python/Javascript I would use IntelliJ. Yet IntelliJ doesn't work well in many corner cases, like very big codebases, projects in C/C++ or languages not officially supported by Jetbrains, cross language projects (even with IJ Ultimate), remote editing or just quickly opening some github repo without spending time on any project setup. And extra emacs packages like magit and org-mode are irreplaceable.
Given the emacs flexibility I was able to configure Emacs to implement majority of IntelliJ keybindings. There usually is an equivalent emacs function of package for IntelliJ behavior, e.g. M-x and IntelliJ "Find Action". Emacs helm works a lot like fuzzy matching in IntelliJ. Sometimes I only implement the "similar" behaviour, e.g. "Show usages" vs "Grep for text at point in current project" in IJ. I will be writing a blog post about it at kozikow.wordpress.com, but if you are interested now now I can send you my .emacs.d.
In this setup I can just setup "fast, always works and easy to set up, but not too powerful" code navigation using ctags/ggtags, grep/ag and projectile in emacs and avoid packages like EDT, eclim-emacs or Jedi that are more powerful, but sometimes require custom per repository setup, or are slow. I usually have both emacs and IJ opened and switch between the two. I have a keybinding in both editors for "open current file in the other editor" (emacsclient + external tool in IJ).
So in the spirit of motto of Spacemacs - "The best editor is neither Emacs nor Vim nor IntelliJ, it's Emacs and Vim and IntelliJ!"
I haven't had to java in a long time, but for C++ I find ymcd (based off vim's YouCompleteMe) well worth a little effort to set up. Get the daemon at https://github.com/Valloric/ycmd and emacs package at https://github.com/abingham/emacs-ycmd It gives "intelligent" completion and code navigation, just like you'd expect from IDE's. For the per-project setup, I typically just copy-paste the config file from another project and perhaps tweak some include paths in it.
Apparantly ycmd can do C#, Rust, Go, JS etc. as well now. I like this way of putting such "IDE features" (meaning the programming language-specific features) into editor-agnostic deamons; that way good completion/navigation is available to all editors. The same idea is behind eclim (as you mentioned) for Java and merlin for OCaml.
Apparantly ycmd can do C#, Rust, Go, JS etc. as well now. I like this way of putting such "IDE features" (meaning the programming language-specific features) into editor-agnostic deamons; that way good completion/navigation is available to all editors. The same idea is behind eclim (as you mentioned) for Java and merlin for OCaml.
And ensime for Scala.
The idea is at least as old as SLIME, which has been the defacto common lisp mode for Emacs for ages. When I was using it nearly fifteen years back it was easily the most comfortable development environment I had used in any language.
The idea is at least as old as SLIME, which has been the defacto common lisp mode for Emacs for ages. When I was using it nearly fifteen years back it was easily the most comfortable development environment I had used in any language.
Looks good in eww!
http://i.imgur.com/5mLJdXb.jpg
http://i.imgur.com/5mLJdXb.jpg
A lot of text editors have a 1% of emacs power but a great web site and a great interface. This help them to shine in the IDE/Editors jungle. So, this new interface, will help emacs (from a "marketing" point of view).
Personally, I think that Emacs is one of the best editors. Not so simple to use (you may think if you are going to start without a tutorial), but, definely... very strong and personalizable.
I prefer to not compare with IDEs. The advantages of IDEs is that they have a particular UI and a set of tools focused for a particular language/development tool. This will allow you to have an initial set of features. Ready to use. Without spending your time to work on personalization. You may think to IDEs as editors with a restricted set of features (compared with emacs).
Personally, I think that Emacs is one of the best editors. Not so simple to use (you may think if you are going to start without a tutorial), but, definely... very strong and personalizable.
I prefer to not compare with IDEs. The advantages of IDEs is that they have a particular UI and a set of tools focused for a particular language/development tool. This will allow you to have an initial set of features. Ready to use. Without spending your time to work on personalization. You may think to IDEs as editors with a restricted set of features (compared with emacs).
Does anyone know of a fun and engaging way to learn emacs, like VIM Adventures? I sit and stare at a list of emacs hotkeys any time I want to give it a shot and my eyes glaze over.
I'm not sure it's worth learning the emacs key bindings for text editing if you already know vim. Just turn on evil mode and use that. I could be totally wrong here but I haven't seen any real defenders of emacs key bindings. seems to me that people are used to them and they do the trick, but vim is considered more powerful for pure text editing. Using emacs is still great for a host of other reasons though.
I did just come across this though: C-h t
That'll bring up a tutorial file that's like vimtutor. Not quite vim-adventures but it's pretty helpful
Hmmmm, the website seems to be taking _forever_ to load
resists urge to make emacs joke about this
resists urge to make emacs joke about this
You think Apache is running mod_emacs perhaps?
Hmmm... the instant I wrote that I realised there's no way that would ever be likely. I mean, it's ridiculous. It's an Emacs powered Apache instance.
Duh. Don't know how I could have missed that.
Duh. Don't know how I could have missed that.
I'm sure you could run elisp scripts with mod_cgi.
But who needs Apache? Just M-x package-install elnode, and you've got yourself a web server.
But who needs Apache? Just M-x package-install elnode, and you've got yourself a web server.
I guess they could be forging the Server header...
https://www.emacswiki.org/emacs/Elnode more like :)
Very good ;)
Since when did FOSS have good design?
Joking aside, looks really nice!
Joking aside, looks really nice!
Guile[1], Octave[2], Guix[3] and GRUB[4] have nice designs too.
[1]: https://gnu.org/software/guile/
[2]: https://gnu.org/software/octave/
[3]: https://gnu.org/software/guix/
[4]: https://gnu.org/software/grub/
[1]: https://gnu.org/software/guile/
[2]: https://gnu.org/software/octave/
[3]: https://gnu.org/software/guix/
[4]: https://gnu.org/software/grub/
It's interesting that they used jquery (MIT licensed) for the web page, and also interesting given RMS's dislike of the use of Javascript. http://www.gnu.org/philosophy/javascript-trap.en.html. MIT is GPL compatible, admittedly, so his main concerns about Javascript probably don't really apply here.
There is no problem with using free software like jquery. Free software does not mean and has never meant "GPL only".
This is the most beautiful thing I've seen from the GNU world. Usually all their websites and materials look like 1980s internet.
Guile is another exception.
http://www.gnu.org/software/guile/
http://www.gnu.org/software/guile/
Anyone have an opinion about emacs on Windows ? I am forced to work on Windows and have no idea about the setup here.
It's really easy. You download a zip file and extract it somewhere. Then you launch "runemacs.exe".
I use it as my primary editor. Works pretty much out of the box, unless you need image support, in which case you have to download dozens of different dlls for each image type.
While the web site is nice, and the links to Emacs Rocks are great, perhaps it should also include a more comprehensive video introduction to Emacs, like https://www.youtube.com/watch?v=B6jfrrwR10k
I'm in deep love with sublime. Can someone convince me that I should use emacs instead?
Keep using sublime, if it works for you. I tried to do the soft sell of vim with tmux to my office, because watching them Alt-Tab between everything, losing or accidentally closing windows, missing little errors because they can't have the editor and terminal up at the same time... It was hard to watch, and made for ugly cluttered demos.
However, watching people try to use vim without wanting to, or taking the time to learn it, just made everyone less efficient, and even more painful to watch.
If you want to learn emacs, then do it. But do it because you want to, or have a need to.
However, watching people try to use vim without wanting to, or taking the time to learn it, just made everyone less efficient, and even more painful to watch.
If you want to learn emacs, then do it. But do it because you want to, or have a need to.
Learn once, use for a lifetime. Sublime or any other small team project that is closed source have a tendency to get neglected past a certain point.
Other than that, emacs has first class plugins for pretty much anything, is easy to extend, and your config and extensions are easy to back up or move to another machine, and can be expected to still work.
Other than that, emacs has first class plugins for pretty much anything, is easy to extend, and your config and extensions are easy to back up or move to another machine, and can be expected to still work.
The biggest reason is super simple. Emacs works in terminal mode (really well) and can be <insert pkg manager here> installed pretty much everywhere.
If you are ever in a situation where you are working on a remote system over SSH (possibly with low bandwidth) you will appreciate it. Also your terminal is in emacs mode by default, so all your shortcuts work there as well. Finally if you are an OSX user all of your _text fields_ understand emacs shortcuts as well :).
If you are ever in a situation where you are working on a remote system over SSH (possibly with low bandwidth) you will appreciate it. Also your terminal is in emacs mode by default, so all your shortcuts work there as well. Finally if you are an OSX user all of your _text fields_ understand emacs shortcuts as well :).
Read this https://news.ycombinator.com/item?id=11659718
Note: I tried Sublime for approximately one year and don't use it anymore.
Note: I tried Sublime for approximately one year and don't use it anymore.
Cool! Congrats guys!
What is the keyboard shortcut to exit the website?
shit now we need a better one for vim
"The best editor is not Emacs nor Vi, it's Vi + Emacs"
I've discovered [evil](https://www.emacswiki.org/emacs/Evil) a few days ago and I'm in love.
I've discovered [evil](https://www.emacswiki.org/emacs/Evil) a few days ago and I'm in love.
There is also Spacemacs which is emacs + Evil with some sweets.
http://spacemacs.org/
http://spacemacs.org/
doener(1)
Semiapies(2)
tt44(1)
Slick
VI !!!
^_^
^_^
Omg now can someone please fix the apex domain?
I don't want to live in a world where I can't like formal verification and modern website design
I don't want to live in a world where I can't like formal verification and modern website design
Very slow to load on a mobile device, looking at the page size it seems quite heavy, especially for a site aimed at promoting or representing a text editor (and a lot more I know, I know).
So with the new website, which looks good, maybe emacs will seem more accessible and worth giving a try to new programmers who cross paths with it. At the same time, maybe that sense of accessibility is misleading given the learning curve of emacs that isn't exactly beginner-friendly. Nonetheless, I like the site!